I have been a long time advocate of analysis of the mobile acquisition funnel. I wrote about this as long ago as 2012 and my first encounter was in 2009. Things haven’t changed in some ways this area of retention has become more important.
Salesforce have a new useful article and infographics on Mobile Analytics Tools: Your Guide to What and How to Measure.
Now that we are at ‘peak smartphone’, developers such as myself are starting to question what comes next. The answer is probably ‘more apps’.
As Gartner recently said…
Much of the innovation in the mobile space isn’t taking place inside the smartphones themselves, but in the things that communicate with them. Gartner predicts that by 2018, 25 percent of new mobile apps will talk to Internet of Things (IoT) devices.
Most IoT devices talk to smartphones via an app or the browser. The app is usually the preferred mechanism because it provides a richer experience that also provides analysis and usage stats to backend services.
In the future the app will increasinly move from being centre stage and the central purpose to being an enabler for some other, probably more useful, purpose.
About 2 years ago I wrote about the MyAppConverter Objective c to Java and vice versa code converter. At the time I observed that the project was ambitious and questioned whether it was viable:
iOS Android Native App Conversion
The team have gone through what they are calling a ‘product market fit’ phase, and have decided to focus their effort on the native iOS UI to native Android UI porting.
The free alpha version is an online tool that quickly turns common UI components into native Android Java. A beta version will support 100% of all iOS UI components. You upload your Storyboard and xib file and download the native Android UI project that provides a skeleton app to kick-start porting your iOS app to Android.
More details can be found on the MyAppConverter blog.
There was a thought provoking tweet by Alex Fehners today:
The resulting comments suggest about 1 year is a good update period to avoid the affect of reviews being reset. Obviously, this isn’t practical for most projects that need to release often.
It’s another good reason to avoid creating paid apps and look for a different business model.
MobiForge is reporting that 68% of digital media time is now spent on mobile devices. 50% of digital media time is dedicated to using mobile apps.
As the article says, this is leading to the situation where the smartphone experience might be considered the first and primary platform. However, conversion rates are lower on mobile (3.89% desktop vs 1.43% mobile) which means we have to think harder how to retain mobile users.
I believe the poorer conversion rate is partly due to the smaller screens and shorter attention spans on mobile. While there’s little that can be done about this, we can add and promote features that allow users to save or share things for later when they are viewing on larger screens or have more time.
Counterpoint has a recent post on how camera and smartphone screen resolutions have been improving. Mid-price phones now have cameras and screens with resolutions closer to flagship devices. While this might have implications for OEM flagship device sales, it also affects developers.
We can now develop more sophisticated apps that make practical use of the camera. For example, for many years I have been working on medical diagnosis apps that use image processing. This kind of processing has previously only been possible on the few devices providing high resolution images.
Now that the majority of users have higher-end cameras, lots of self-diagnosis scenarios become possible. Couple this with server-side big data and it opens up a new world of possibilities.
IDC has new research on smartphone sales that, similar to Gartner, shows Android share at 85.3% and iOS at 13.9%. More significantly, IDC don’t expect the market share to change much up to 2020.
I personally don’t think the market shares will change much over that period. However, there could be outside influences such as mobile operating system security scares, Brexit fallout (at least in the UK) or corporate tax politics that could change peoples’ perception or affect pricing and hence purchasing significantly.
There’s a thought-provoking post on GeekTillItHurts on how Android 7.0 Nougat can be run on the Raspberry Pi 3. This offers new opportunities for entrepreneurs and developers to implement more single board computer (SBC) embedded type applications.
Using Android on SBCs isn’t new. I have worked on a few such projects that have re-purposed media Android TV devices to do more specialised things. It’s very easy to program Android rather than c++ or c and you get much better productivity. It also allows more complex applications to be implemented quicker. In two cases I ended up doing image processing on SBCs that would have been much more difficult, if not impossible, had I not had Android’s hardware accelerated drawing APIs.
These boards often run ‘headless’ without a UI or with a minimal admin UI. In these cases, you need some central event processing for communication between the various modules. I have found using Green Robot’s EventBus simplifies communication between threads, services and the minimal UI if you have one.