Does OS Market Share Matter?

October 15th, 2014

gartner136.gifGartner has new research that compares sales of PCs, tablets and smartphones across the respective operating systems. The headline is that tablet sales are slowing. However, does it matter?

The ever insightful Benedict Evans also has a new post where he explains that we are in the uncharted territory where a minority market share is still very large. He talks of the potential fallacy of "winner (platform) takes all" and suggests that we should look at other things such as the geographic region we are targeting.

Benedict talks a lot about developer revenues and geographic region when choosing a ‘mobile first’ platform and concludes…

"It isn’t so much that ‘maket share doesn’t matter’ (the mantra of Apple fans for decades’) as that you need to think about what kind of market share, where, and whether that matters."

I’d advise you to think and analyse even deeper. I find the emphasis on app revenues and market share slightly concerning. People should be think more about the benefit to their company. This benefit can take many forms. Whether an app is financially viable depends on the kind of app/company as much as it does the platform.

Taking Benedict’s examples of Citibank, Tesco and Carrefour they don’t even sell their apps nor use store in-app purchasing. The fact that iOS users are more affluent probably doesn’t matter for Tesco and Carrefour as iOS customers might be shopping at, at least in the UK, John Lewis and Waitrose anyway. Conversely, I very much doubt many Citibank customers use Android and they would prefer iOS. The key thing here is that these are hunches and guesses.

You need to assess what platform to use on a case-by-case basis and do some market research beforehand as to what devices your users are using and whether they would access your product/service via an app, smartphone, tablet or indeed anything else.

Back to the Gartner headline that tablet sales are slowing. Does it matter? Sales are still of a similar order to PCs and it’s still a large market. What’s probably just as important is whether your end users would access via a tablet and if so, what kind of tablet are they using?

Related Articles:

App Purchase/Subscription Insights

October 14th, 2014

branchfire.pngBranchfire have a new US mobile app study of 2,042 adults, conducted by by Harris Poll on app-buying habits. 76% of people download apps while 57% have never paid for an app. 70% of people have downloaded more than 10 apps. The study also gives useful information on highest amounts paid for apps, monthly app subscription by category and subscription pricing thresholds.


It’s interesting that people are open to subscriptions as this gives longer term revenue for developers. The study says that streaming and movies are the top types of app people are willing to pay for via a subscription. These are the kind of things that can exist and be consumed outside of the phone and be accessible via other means, for example the desktop. The app is just a gateway to consumption (and payment). The value is seen as the content rather than the app. This is probably a good indicator of whether it’s viable to use app subscription in a particular app.

Related Articles:

Scaling Android Development

October 13th, 2014


Most Android apps are created by a single developer or a team of a few developers. However, what happens in a large company where potentially hundreds of developers each want to add their small feature? There’s a new video, from DroidCon Paris, on how Twitter went from a few developers up to of the order of 100.

The video shows how Twitter developers, who were more used to working on the Twitter Web site, had to adapt to working on Android. For example, their ‘web brain’ that previously allowed bugs in the web site to exist, because they could be reverted, had to be modified for Android where a crash usually means the user will install and might not re-engage with the app for another month. Also apps have a longer lifetime until upgrade and Twitter has up to 60 versions of the Android app running at any one time due to people delaying upgrading.

The session shows 50% of Android Twitter users will upgrade within 3 days if no extra permissions are required. 75% will upgrade within 14 days. When new permissions are required manual upgrade can typically take a month.

There’s also useful information on large scale training, test devices, code style wars, testing tools, emulator vs device, remote feature on/off and toolchains.

Apple Pay Limitations

October 10th, 2014
apple.gifThere’s an interesting article on USA Today Money quoting a UBS report explaining problems with Apple Pay that will limit its dominance…
  • Onerous fees charged by Apple
  • Inferior technology
  • Little incentive for merchants to adopt Apple Pay-compatible devices

More reasons then, why Apple should open up NFC before interested parties develop alternative solutions.

Looking wider, this provides learnings for any new venture. Are the fees you expect to charge reasonable in the current (and future market), can people easily circumvent your solution using other technologies and are you expecting too much of third parties to change/update their systems in order to be part of your solution? I suppose it’s really about having an old fashioned business model which is one of the stages of my primer.

Android Device Churn

October 7th, 2014

bidouulle.pngBidouille has some great charts showing how Android version distribution has changed over time. They are based on values taken, over time, from Google’s own Android dashboard. However, remember there’s possibility that these charts might not represent the actual distribution of devices as not all devices (or users) access the Play Store.


What with few manufacturers updating older devices to newer versions of the OS and those that do taking a long time to do so, it’s surprising to me that so many devices now run 4.0.3 or better. So what has been causing people to change their devices so soon? It might have something to do with tariff contract lengths. It might even have something to do with the use of contract-free SIMs where people can upgrade their phone any time. It’s almost certainly to do with the enticement of improved devices over the last few years. Looking forward, there might be another driver.

Yetserday, Lookout wrote about the Android browser bug and how it affects about 45% of users. They said…

"If you have a phone that does not have the option to update to a newer Android OS version (4.3), unfortunately you may need to upgrade your device to a newer, more readily patched version"

In some ways it’s odd that one of Android’s failings, that of slow or non-existent OEM OS upgrades, might cause more people to buy a new device to be on a more secure Android version, which, in turn, will reduce OS fragmentation to the benefit of the platform.

Related Articles:

CERT Vulnerable Android App Naming and Shaming

October 3rd, 2014

cert.pngI have previously written (here, here, here, and here) about Android apps that fail to validate SSL certificates. CERT has started to name and shame libraries and apps that their Tapioca tool has detected to be vulnerable to Man In The Middle (MITM) SSL attacks. There’s a blog post on how they have automated the analysis, a vulnerability note explaining the problem and a large spreadsheet of vulnerable libraries and apps.

Libraries that have been found to be vulnerable are Flurry, Chartboost, Adcolony, MoMinis, Inmobi, Tapjoy, Appsflyer, Gameloft, Zopim, Fiksu and Batch of which only the first two, Flurry and Chartboost are noted as fixed.

CERT are testing one app at a time so progress is slow. Nevertheless, over 1000 apps are listed as having failed. However, some of these failed because of the included vulnerable libraries.

If you think this is just an Android specific problem then you might like to consider that Veracode previously found 7% of Android apps and 33% of iOS apps had cryptographic problems. Developers can be inexperienced or lazy on both platforms.

Related Articles:

Another Android WebView Vulnerability

October 2nd, 2014

android.gifAnother day, another Android WebView vulnerability. This time it’s related to users that have enabled accessibility on their phones. This exposes two Javascript objects allowing remote code execution.

You might think this problem has low risk as not many people would enable accessibility features that are intended to assist users with disabilities. However, even I have had this enabled as it’s used by a password store app I use that auto-fills login forms for me.

There’s some new useful advice for developers to invoke removeJavascriptInterface("accessibility") and removeJavascriptInterface("accessibilityTraversal") that I have added to my WebView security guidelines.

Related Articles:

Smartphones and Beyond

October 1st, 2014

symbian.gifOver the last few weeks I have been reading the 800 page book by David Wood on Smartphones and beyond: Lessons from the remarkable rise and fall of Symbian.

It’s fascinating reading especially if, like me, you developed Symbian apps and worked at Symbian. It’s useful reading even if you aren’t in any way linked to Symbian as many of the learnings are just as applicable today. Don’t let the 800 pages put you off. There are lots of press releases, blog and news articles that you don’t really have to read entirely and the latter portion of the book hasn’t much to do with Symbian or necessarily mobile at all and delves into David’s other passion of predicting what might lie ahead. In fact, if you are interested in this kind of stuff you are better skipping this part and instead reading ‘Anticipating 2025′ which is part authored by David and includes similar material.

Back to the Symbian book, it describes how Symbian’s loss of control of the UI, to Nokia, affected the OS. It describes the difficult situation when your customers (licensees in Symbian’s case) aren’t the end user (network operators, consumers). It also shows how there can be conflicts of interest when your shareholders are your customers and how they can prevent the company from exploring what could be more profitable or successful areas. It also demonstrates how it’s easy to under-estimate competitors who have taken up recent easy-to-deploy commoditised solutions for which you have historically had to use a customised solution to which you are now tied. It describes how large software is difficult and differentiates between team agile and enterprise agile. The book also shows it’s possible to consider creating custom solutions for customers but to make them pay through consultancy.

There’s a useful observation that recruiting the best is important. If your don’t then when your recruits recruit further people there can be downward spiral as people recruit weaker and weaker people so as to protect themselves. The book shows how technical debt and strategic debt can cripple a large company (Nokia) thus advantaging faster-moving newcomers such as Google and Apple. There’s also a possible explanation of why Stephen Elop killed Symbian so quickly rather than slowly, a strategy that lead Nokia to financial ruin. You can also learn how David’s openness, while representing the ‘open’ Symbian Foundation, caused him to be asked to leave his job.

Many of the insights can be used to provide advice to today’s startups. For example, if you are thinking you can’t compete with an incumbent, there’s a possibility you can. They will be much much slower, especially if you can use commoditised solutions while they use custom solutions.

Related Articles: