That’s 5 million in one quarter. Certainly over 20 million over the next year. Suddenly, wearables seem to have more traction than I had envisaged. Wearables are bigger than I thought - in more ways than one.
This is good news for developers as, in time, it will reduce the number of devices that don’t have Google Play Services. Google Play Services is becoming more and more important to developers as components get unbundled from the OS into Play Services and the Play Store.
It seems Android One will be more successful than I expected. I was sceptical. Getting ‘low cost’ OEMs to use Android One is being driven by the availability of low cost reference designs from Qualcomm and MediaTek. In the distant past we saw similar efforts by Symbian and Microsoft meet with only partial success. This time it seems Google has the momentum to see this strategy through.
Arxan has a free State of Mobile App Security research report (pdf) that claims a very large proportion of the top paid/popular Android and iOS apps have been hacked. Hacked apps either have IP stolen that’s used in other apps, have clones created or the apps are modified to remove payment mechanisms.
- WebView Unbundling
- Android Growing
- Android Binder Subversion
- Another Android WebView Vulnerability
- Same Origin Bypass and Android Apps
- The Web vs Apps Outcome
- Listening in on Android Apps
- Severe Security Flaws Found In Security Apps
- Android Security Perfect Storm Pending?
- Has Your Android App Been Repackaged as Malware?
- What You Ought To Know About Android WebViews
- Mobile Payments and Banking Market Map
- Android Malware War of Words
- How To Write Secure Android Apps
- Android vs iOS Security
29.9% of Android’s 72% market share is "white box" manufacturers. A white box tablet is produced by a company (the manufacturer or ODM) that other companies (the vendors or OEMs) re-brand to make it appear as if they made them. These are a big threat to the well-known brands and are increasing being sold by retailers under their own made-up brand names. Many work very well and I have even used some as a basis for client, vertical single-use ‘kiosk’ style products. The down side is that the OS rarely, if ever, gets updated and for developers there’s usually a lack of Android adb drivers.
There’s a diagram doing the rounds that demonstrates what a Minimum Viable Product (MVP) is (and isn’t). It shows that a MVP shouldn’t be just about functionality but also about reliability, usability and user experience. Building a MVP is one of the first steps after which you have to measure, learn and iterate. However, just getting to an MVP can be difficult and how you do it can affect ongoing development.
The diagram is a clever way of showing what’s sometimes hidden when first thinking about a new product. It digs deeper into the what side of a MVP. i.e. What the product should be. I have found that, in practice, creating a MVP is a delicate balance because it not only concerns what but also how these things are implemented.
I have seen my clients’ MVPs (server-side and apps) scrapped and started again and I have also seen them used as the basis for further iterations. I have seen large amounts of effort on over-thought through, over-generalised and over-tested MVPs be dropped. Conversely I have seen under-thought through, under-designed, under-tested MVPs with lots of technical debt become the basis of future development. Perversely, the flexibility of the latter approach seems to foster more success and these are the projects that then end up having to build on sand. So, also think how (well) as well as what.
One of the problems of mobile development is that it’s a human resource driven activity that’s expensive. Multiply that by iOS and Android and the costs double (or more). Wouldn’t it be good if you could develop on Android or iOS and a tool could automatically generate for the other platform? Well, MyAppConvertor has that ambition. Really. This isn’t some limited, poor html-based or intermediate language-based ambition. It’s the real thing - Objective c to Java and vice versa.
MyAppConverter is currently in beta and is limited to online conversions via their web site. It only works for games, only converts from iOS 7.1 to Android 4.4.2 and only on Samsung Galaxy S5. However, the aim is to eventually support IDE-based conversions, for all types of app, to and from all major mobile platforms and versions of those platforms.
The presentation outlines their approach based on models and meta models to not only directly map code but to also do it in such a way that creates the right algorithmic and UI idioms/patterns on the respective devices. While the converter can create source code for completion by a developer, they are aiming for 100% conversion so that anyone can use the tool. Anything less is much less useful as it then needs a developer and the ‘extra stuff’ the developer adds needs to be somehow added every time there’s a new version of the app which would get difficult to manage.
This isn’t just about mapping APIs which is complex in itself. It’s also about knowing all the nuances of the APIs that are documented in places like stackoverflow. It’s also about mapping idioms and patterns of doing things, somehow mapping 3rd party libraries, knowing fragmented differences between (target) devices and knowing differences in APIs across OS versions. Even then, it won’t cover apps that use ‘real native’ c/c++ NDK code - previously estimated by Intel to be of the order of 25%. Once all this is solved, consideration has to be given to keeping all this up to date into the future. APIs can become deprecated over time and new API’s are created. For example, in Android Lollipop there are over 5000 new API’s. New devices will also become available with new nuances.
I don’t think what they are trying to achieve is possible in a reasonable time and/or with a reasonable team size. The World really needs tools like MyAppConverter. I sincerely hope they prove me wrong.
If I am wrong and the tool comes to fruition then there are some interesting possibilities MyAppConverter might not have considered. It might be possible to create a new tool to create apps by visually (or otherwise) building up the pre-existing meta models. These meta models, together with some kind of configuration data (the static, unchanging data in an app), would then be able to auto generate to multiple platforms with no actual developer coding thus putting developers such as myself out of business. Lay people, capable of wiring things together, could create complex apps.
There’s a thought-provoking article and discussion at Intercom on "The End of Apps As We Know Them". The premise is that we will use apps directly less and less and instead interact with rich notifications or cards.
While I can see some notification-rich apps might work this way, I am less convinced that the majority of apps will end up working that way. Most apps do too much to be shoehorned into a notification style app. Also, people are more used to invoking apps via icons and I can’t see that going away. I think cards/notifications are great for end user consumption but not end user content creation. If the majority of apps were to use this paradigm then the user would become overwhelmed with notification overload.
IDC have a new press release showing smartphone vendor shipments for Q3 2014. Samsung lost market share at the expense of Xiaomi, Lenovo and LG. Apple’s market share dropped slightly by 0.9% to 12% meaning shipments of units grew by 16.1% vs 25.2% for all smartphones.
What does this mean for developers? For Android developers it’s going to be increasingly the case that testing mainly on Samsung devices won’t get you the majority of the devices being used. With iOS now having only 12% market share, there’s going to be continuing intolerance by end users of some companies that still only provide an app for iOS.