Appindex, the app development marketplace and organisers of the app promotion summit have an interview with me where I talk about my involvement in mobile development, the types of apps I have worked on, tools I use, what app I have been most proud of, trends in mobile development and my current views on mobile development.
Appindex also previously kindly listed me in their Top UK App Developer Agencies.
Last week I highlighted how, with in-app purchases, 1.14% of paying customers generate 30% of the sales. This links in well with a recent report by Flurry on Mobile Addicts. These are super users that use apps between 16 and 60 times daily. Flurry has worked out that this class of user has grown by 34% over the last year…
This group of users isn’t necessarily that small. Flurry says…
“If the number of Mobile Addicts there were in 2014 had been the population of a country, such country would have been the 8th largest in the world last year, slightly below Nigeria. In 2015, the growth of the Mobile Addicts population would have propelled that country to the 4th spot, just below the United States”
Here’s what these people are actually doing…
What does this mean for 3rd party developers? First, I think it vindicates the use of ‘Messaging & Social’ if it works within your kind of app. It also shows that there’s plenty of opportunity in ‘Utilities & Productivity’.
As well as thinking about short term retention, think about longer term users. Try to design your app to also help your best and longest users. How? For example, let them save things, let them see what they have done in the past, allow searching when data gets larger, allow old or unwanted data to be purged to save space. Reward your longer term users with things like larger quotas or extra features. Over time, migrate their existing data as the app gets updated. Allow them to backup data so they can use the app when they upgrade their smartphone. Think longer term.
In the past I have mentioned the need to be careful about using WebViews in apps, particularly apps that are security sensitive. The number and complexity of WebView vulnerabilities are such that a pragmatic approach might be to not use WebViews in security sensitive apps. Recent news has shown that the same vulnerabilities can be a security problem for the Chrome web browser app itself.
If you have been following the IT news, particularly the security news, you will know that the Italian spyware company Hacking Team recently got hacked themselves and their source code was posted on the Internet.
It turns out they developed an Android ‘remote2local‘ exploit that cleverly combines three known Chrome vulnerabilities and the root-enabling put_user or TowelRoot vulnerabilities to allow pre-defined code to be executed as root from the user simply clicking on a link in the browser. The details are on the Tancent blog (Google translated).
How bad is this? The Hacking Team have a compatibility file that says it covers Android 4.0 to 4.3 and lists some tested devices…
One of the vulnerabilities, CVE-2012-2825 Arbitrary memory read, was fixed in June 2012 and another, CVE-2012-2871 Heap-buffer-overflow was fixed in August 2012 so end users allowing Chrome and WebView to update via the Play Store will have had these vulnerabilities fixed a long time ago.
However, this demonstrates how vulnerabilities can be combined to run code as root without the user even knowing. The Hacking Team compatibility file and subsequent vulnerability fixes show that in some ways, Android’s fragmentation aids security. It’s difficult for exploits to cover all types of Android OS and device and they usually only work on smaller subset of devices. As I previously mentioned, this won’t be much consolation to large companies with thousands of employees or customers which greatly factor up the chances of encountering exploits that might end up accessing sensitive company information.
Localytics have new research that shows that in-app messages drive 3.5X higher user retention. But, as Localytics say…
“Many app owners wonder how to create content that isn’t viewed as spam and doesn’t detract from the user experience.”
The problem is that unless the message is event/content triggered and is useful to the user then the notification is likely to be seen as an annoyance. For example, as some developers do, reminding the user about some feature of the app that isn’t pertinent to specific new content in the app is likely to be viewed unfavourably. If your app isn’t event/content driven then in most cases I’d avoid notifications as it’s harder to justify their use.
Localytics also have some recommendations for you to consider to help drive use of notifications…
- Get the user to opt in (rather than have to opt out)
- Provide personalised recommendations (rather than serving them with everything)
- Provide notifications for upgrade or achievement notifications
- Get users to share app content (I am less sure this is a good idea)
- Provide app quick tips (I personally think this will annoy all but the most ardent fans of your app who will probably already know about the feature anyway)
You might also consider filtering notifications based on what content the user has previously viewed or what they have favorited/saved. Whatever you do, provide the option in the app for the user to turn off notifications otherwise some people might uninstall the app instead.
This site was born 10 years ago in the era when Nokia was the top smartphone vendor and the iPhone and Android didn’t exist. February 2011 was turning point for me when I said that Nokia were heading off in the wrong direction and shortly after that I went ‘Android only’ from working on all mobile platforms at that time. Microsoft ended up taking over the Nokia handset division and more recently, according to Wired, Microsoft finally gets that it won’t win the smartphone war and Stephen Elop is leaving the company.
However, there’s a twist to the story. Tomi Ahonen is quoting Nokia CEO Rajeev Suri telling German periodical, Manager Magazin that Nokia will return as a brand to smartphones in 2016 as the exclusivity period out of the Microsoft deal ends. Tomi says “Obviously these will be Android based”. I’d like to think so. However, as the past has shown, companies don’t always follow what might seem like the obvious path.
Gartner has a new press release on how the demand for enterprise mobile apps will outstrip available development capacity five to one. Their survey on mobile app development conducted in 2014 found that the majority of organisations have released fewer than 10 apps. A significant number of respondents haven’t released any apps. Gartner says…
“This is an indication of the nascent state of mobility in most organizations, with many organizations questioning how to start app development in terms of tools, vendors, architectures or platforms, let alone being able to scale up to releasing 100 apps or more,”
There’s an increasing pressure on IT departments to develop a larger variety of mobile apps in shorter time frames. Gartner suggests some best practices in their press release that includes prioritisation, process, use of RAD tools and mixed-sourcing.
My thoughts on this are that while RAD (cross-platform) tools might be ok for internal use where users are more forgiving, their use on customer/consumer facing applications usually results in too many lowest common denominator tradeoffs in terms of functionality, performance and look and feel. I think that lack of productivity in the enterprise has a lot to do with how app development is being done and using RAD tools is trying to fix the symptoms rather than the cause – which then causes new undesirable side-affects.
The companies I come across tend to be of two types. The first, as Gartner identifies, have been internally arguing over who and how mobile development should be performed within the organisation and such cases usually result in separate parts of the company going it alone with separate outsourced work. This causes many internal and external problems, one external manifestation being multiple app publishers from one company.
The second type of company I have seen is those trying to do it all in house and running up against productivity barriers. There is often a common theme of building things from scratch rather than re-using open source libraries due to not knowing what libraries are worth using. There are also other common problems such as using non-iterative processes, no tracking tools, not creating domain specific libraries for re-use and lack of knowing what to test. Experience how to best go about things and productivity are related.
In many cases enterprises just need a little extra help via consultancy or a single, experienced ‘head of mobile’ who has seen and experienced most of the problems.
IDC has some new research that roughly correlates with GfK in that smartphone shipments are expected to grow 11.3% in 2015.
IDC has predictions up to 2019 when it expects both iOS and Android to grow less, with iOS having the lesser year on year growth. They also predict, without substantiation, that Windows Phone will see a 24.3% compound annual growth.
I have finally got round to reading Google’s ‘Android Security 2014 Year in Review’ (pdf). I believe it’s mainly a public relations exercise to assure everyone that Android is safe and that Google is being proactive in improving security. However, having read the report it’s easy to come away with the impression that everything’s ok. There are few places in the report I thought “Yes, but…”.
First an obvious one. Google say they “provided device manufacturers with ongoing support for fixing security vulnerabilities in devices, including development of 79 security patches”. However, what they don’t say is that very few of them made their way onto consumers devices.
Google say “Fewer than 0.15% of devices that download only from Google Play had a Potentially Harmful Application (PHA) installed”. This doesn’t sound many. As an end user you will probably be comforted by such a statistic. However, what if you are a company with say 1000 employees? Statistically, at least one of them might be leaking company information. What if you are a bank with millions of customers using a banking app? If your app doesn’t adequately secure data then a very large number of people could be affected. I think what this means for developers is that just because there’s a low chance of infection, apps should still take exceptional steps to protect their own sensitive data and not solely rely on the fact the platform is secure most of the time. The fact that Android is “secure most of the time” is only of significance for end users.
There’s lots of emphasis on Google’s Verify Apps that checks apps at time of install. This won’t catch everything. Attackers are getting good at installing skeleton apps and later downloading extra functionality after Verify Apps has stopped looking.
Also remember, security isn’t only about PHAs being installed. It’s also about the ability to easily obtain information from stolen devices, reverse engineer apps and other such activities that can cause nefarious deeds without even installing an app under Google’s Verify Apps.