The latest 9th version of VisionMobile’s Developer Economics report is now available, based on a survey of 13,000 developers, that covers desktop, IoT and cloud services as well as mobile.
There’s a very interesting chart showing what mobile developers are currently working on…
VisionMobile conclude that “iOS-only, or even iOS-first, may no longer make sense”. 37% of all mobile developers target both iOS and Android, increasing to 44% when hobbyists and explorers are excluded. The report also says… “Android remains by far the most popular platform overall; targeted by 71% of all mobile developers”.
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.
Criteo has a great free report and slides on the State of Mobile Commerce Q2 2015. The slides include some very useful country specific data towards the end of the presentation.
- Mobile is very significant in all retail categories with 1 in 3 transactions being in fashion and luxury.
- The majority of transactions come from smartphones as opposed to tablets.
- In the US, iPhone makes up 66% of transactions compared to 5.6% for Android.
- Quality apps can currently generate up to 42% of mobile transactions for sellers.
- Cross device shopping is important and makes up 40% of purchases in the US.
- Android produces more transactions in many countries…
MobiForge has a great post on ‘25 mobile market statistics that you should know in 2015‘ subdivided into Mobile Hardware Statistics, M-Commerce & Banking, User Behaviour, Mobile Software and Mobile Networks.
The most useful statistic for mobile developers is iOS vs Android across countries…
However, the data comes from DeviceAtlas. This means the data is based on web usage which might (or might not) skew the data. However, it’s probably a more useful way of measuring the user base than shipments because it gives the installed base which takes account of the cumulative affect of shipments/replacements.
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.
There has been lots of press about the recent Samsung keyboard vulnerability. The vulnerability comes about because a new language can be downloaded under a privileged context which can be network hijacked to run arbitrary code.
Many articles mentioning this vulnerability are over sensational because it’s very unlikely that the user/app would download a new language pack AND be on a hijacked network taking advantage of the vulnerability. However, I think it’s more useful to pull apart the vulnerability and look for simple learnings to apply to other existing and new apps.
There are three main problems…
It’s very easy to reverse engineer most Android apps using dex2jar, JEB or Dare and there are even online tools that can reverse engineer an app without having to install any tools.
Each tool has its own limitations and those limitations are often used by other obfuscation tools to make reverse engineering more difficult. However, to make things even easier, a new tool enjarify has been ‘unofficially’ released (presumably means there’s no support) by Google that claims to resolve many of the limitations of dex2jar such as support for unicode class names, constants used as multiple types, implicit casts, exception handlers jumping into normal control flow, classes that reference too many constants, very long methods, exception handlers after a catchall handler, and static initial values of the wrong type.
I can’t see why Google would want to release such a tool other than it’s the result of a Googler’s 20% ‘free’ time. It will probably encourage more copied apps, ip theft and thwarting of in-app purchasing.
However, it does serve to emphasise how much more sophisticated and easier decompilation has become over time. You shouldn’t rely on the fact it’s difficult to do nor assume what might have protected your app in the past will protect it now or into the future.
Of all the changes coming out of Google I/O 15, the new permissions model will have the greatest longer term impact on developers. I say ‘longer term’ because for existing apps on existing phones, users will see no difference. Existing apps on phones running ‘M’ can have their permissions taken away by the user which will, no doubt, cause them to malfunction and possibly cause confusion for the user (and people supporting the app).
The real power and possibilities come when an app is built for ‘M’ (or in the future ‘M or later’). Developers and designers now really have to think hard about their messages to users. There’s an article on Medium about the Cluster app, on iOS, that covers similar issues and the complications.
The good thing is that (‘M’ built) apps will no longer sit around, as now, waiting for the user to upgrade when they need more permissions. The down side is that the user disallowing a permission can seriously bazooka your app and you need to really try your hardest to explain to the user why a permission is needed.
Obviously, more transparent permissions is good for everyone – in theory. In practice, I find many clients and some designers already have trouble agreeing/deciding how screens and messages should look and feel. Adding permissions screens/dialogs into the mix is bound to lead to protracted mobile development, more testing of permissions-based scenarios and more support needed when apps don’t work due to revoked permissions.