Openxcell has a useful roundup comparing Android and iOS for those developers trying to decide between iOS and Android. The summary is…
“Developers, who are primarily interested in ‘making big revenues’, target iOS and those who prioritise ‘wider audience’ over revenue, target Android. But as much as it is about your ‘primary’ interest, it is also about the audience you want to cater to and the investment you need to put in to make an app for Android or iOS.”
I think the comment about ‘the audience you want to cater to’ is the most important part. If you can, survey your prospective users and determine what devices they own. It’s not about what phone you, your marketing manager, your sales manager, your app UI designer owns – think about your end users and put in the appropriate effort into supporting the particular phones models, not just the OS platform, that are actually being used by end users in your industry.
There’s some research by CA and Oxford Economics that shows companies now consider software-driven business models to be the key to competitive advantage. More specifically, organisations are looking to API-enabled software and mobile apps.
The report says there’s an emphasis on bringing more development back in-house or using mergers/acquisition to improve development capabilities. I believe this shows a maturing of the mobile development ecosystem. As mobile development becomes more mainstream, more companies will seek to control it better and more directly. Having outsourced or offshore development can add a level of hidden indirection to communications and I have often, but not always, seen that indirection slow things and cause misunderstandings.
In 2011, in Rise of the Mobile Development Intermediary I explained how I was seeing an increase in intermediaries and the associated problems. For the reasons explained in my previous post, I have always preferred working for companies developing their own software or at least controlling the features of a product used by their clients. Maybe we will start to see a decline in the number of mobile development intermediaries.
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.
Amazon has a new informative slideshare presentation ‘What the Top 50 Apps Do with IAP that the Rest of Us Don’t’ with insights into in-app purchasing. While the insights have been obtained from the Amazon app store, they are just as applicable to all stores and all OS platforms.
Here are some of the learnings and consequent recommendations…
- Start cheaper and increase price(s) over time to about 60% of the original price.
- 48% of purchases happen within 1hr of previous purchase. Hence, make sure you offer an IAP within this time.
- 37% of users who will purchase, purchase on the first day. Again, engage the customer early.
- Offer between 1-5 price points for the best conversion. More prices points can confuse the user.
- Apps with tutorials have a 2.5X higher conversion rate,
- 1.14% of paying customers generate 30% of the sales. Cater for your best and longest customers by differenting your IAP offering.
- As with non-IAP apps, retention is the only important metric. Give them a reason to come back, for example use social, leaderboards and achievements.
Argus Insights has a new free report (PDF) on how ‘Consumer Smartphone Demand is Plummeting
Despite the Introduction of Flagship Phones’. The report says…
“New phones are typically a vague improvement on old ones, with better cameras, memory, etc., but these small improvements are failing to create urgency for consumers to upgrade right away. “
This might be seen as good news for developers. It’s unlikely the installed base is falling. We might get a period of relative stability where we won’t have to keep testing on newer devices. However, there is also a counter-argument that people mainly try new apps when they get a new phone.
Two days ago I repeated my advice on having to be careful when using WebViews in security sensitive applications. Yesterday, I happened to come across a research paper (pdf) (and presentation) “Insecurity of Mobile Banking… and of other apps” by Eric Filiol and Paul Irolla of ESIEA Operational Cryptology and Virology Lab that recently became available at blackhat Asia 2015. In the research paper it says…
The authors are French so we can excuse them that the above doesn’t read that well but I think what they are saying is that because banks already have a secure web site accessible via the browser most are re-using it for use within their mobile apps.
I guess the assumption banks are making is that any checking such as login, intrusion detection etc is already there and proven it’s best to re-use these mechanisms as they are considered to be secure. Unfortunately, that assumption is very wrong. In using WebViews to render server side screens they have opened themselves up to the area of the phone software that has the most (and most complex) vulnerabilities. For example, the login might be on a web page on some server but by rendering a remote page there’s the possibility of extra unwanted things being loaded that might do literally anything such as log keys and read data in files or memory. I have also yet to see a reliable implementation of certificate pinning that works with webviews.
The authors also claim…
“Furthermore, there is at least one vulnerability affecting webview. This vulnerability has not been disclosed by Google and consequently Google will not publish any security patch to correct it for version 4.3 and prior versions. It is therefore a major vulnerability which allows a third party to take control over the phone.”
You can read the paper (pdf), slides (pdf) and a similar presentation (video) from December that analyses some well-known banking apps to show they aren’t that secure. If you really must use WebViews, you might also read my guidelines on how to be careful with WebViews on Android. If you are concerned using a banking app yourself then you can read my basic advice of consumers.
Google announced their Eddystone open Bluetooth LE beacon protocol today and corresponding APIs to allow Eddystone (and Apple iBeacon) information to be stored in Google’s cloud to which arbitrary information (text, images etc) can be attached. Google have also introduced a Monitor Beacons API so that the health of beacons can be monitored. What does this mean for the cross platform (iOS and Android) developer?
The Beacon Hardware: First of all, existing iBeacon hardware won’t automatically work with (transmit data for) Eddystone. Bluvision, Estimote, Kontakt.io, Radius Networks and Signal360 have already updated their beacons but these companies represent a small part of the beacon hardware market. As a small sample, the Bluetooth LE apps I have created for clients don’t use these beacons. Maybe other manufacturers will upgrade their beacons in time? Without Eddystone, Android (4.3+) can already sense iBeacons and infer distance so it might seem there’s no urgency to use Eddystone. However, from experience, I know the extra features provided by Eddystone, such as monitoring battery life, are really needed and are not gimmick – this itself might encourage demand for Eddystone.
By the way, upgrading beacons will enable them for both iBeacon AND Eddystone, such they alternately transmit in each format, so it’s not a case of supporting one or the other (or having two separate beacons for each protocol).
The Cloud API: This is interesting as it’s free way of associating content with a beacon, irrespective of whether you are using Eddystone or not. Obviously, if you only store iBeacons then you won’t get the extra benefits of the health monitoring. Note that it’s only an API and not a web interface. You will still need to create your own web interface for your customers that, in turn, uses the Google cloud API to register beacons and map your business objects into the ‘arbitrary’ content to attach to a beacon. From there, it’s only a small extra step to also provide a device JSON API yourself. I am not sure yet why people might choose to use Google’s API other than to later participate in the upcoming changes to the Google Places API to make beacons globally visible – something that will probably benefit Google more than the information provider who in many (but not all) cases will usually want to keep the content in their own app(s).
Update: My assumption that upgrading beacons will enable them for both iBeacon AND Eddystone, such they alternately transmit in each format was wrong. The Estimote blog explains that while this is technically possible and “makes a ton of sense”, it isn’t legally possible if hardware vendors wish to remain officially iBeacon compatible as Apple “don’t allow other frames”. I now expect this to seriously limit the takeup of Eddystone as many companies still work on an iOS first basis. Solution providers will have to select iBeacon OR Eddystone. For cross platform solutions, using iBeacons will give better iOS background detection while using Eddystone will give access to beacon health information and future integration into Google Places.
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.