Channels ▼
RSS

Mobile

The Uncompromising Economics of Being #3 in Mobile Platforms


During the days when Blackberry was fighting for its place at the app development table, I met several times with the company's head of developer outreach. An energetic man, he had many views to express, most of which made a lot of sense. There were good reasons to code for the Blackberry platform: It was easier, in some senses, to develop for than other platforms; and users were more willing to pay for BlackBerry apps than for Apple iOS and Android apps, where the notion of "everything should be free" had already taken root.

However, as he clearly articulated one afternoon, none of these benefits meant much if app developers chose to write for the BlackBerry after writing for Android. The dynamic, he explained, went like this: Companies coming out with new apps almost always wrote the iOS app first. This was generally a native app because Apple users are finicky enough that they tend not to be satisfied with apps that don't exactly fit their guidelines.

After writing the iPhone/iPad app, there comes the moment of decision. The worst decision for the #3 player is that the vendor chooses to develop for Android next. Android development is a black hole due to the vast number of form factors and OS versions that must be accommodated. Said the fellow from BlackBerry, organizations don't ever truly exit the Android development process. They keep porting and testing the app on an endless list of devices until they finally decide they've covered enough of them to meet their goals. Only then do they stop porting on Android. In other words, the decision to stop is a purely economic one, rather than the naturally occurring end of project when all desired devices have the app.

After the Android ordeal, the company has already decided that further development of the app to other devices is no longer economically justified. So typically, they do not port to the #3 player. That player was, at the time of these conversations, BlackBerry. Today, it's Microsoft's Windows Phone.

There is, of course, another path vendors or businesses can choose after writing the iOS app. That is to write a multiplatform app, generally using HTML5 and some framework. Such an app can work well enough on Android and the subsidiary platforms that it becomes the overarching multiplatform solution. (In reality, there are often small tweaks made in the product for individual devices, so that minor vendors are still somewhat disfavored.)

The reality is that for vendors outside of the top two spots, this approach is the only path that gives them any hope of ever getting a big enough app ecosystem. For this reason, BlackBerry loudly touted its HTML5 support and Microsoft extols its own support for that strategy.

However, the HTML5 approach underscores the disenchanting but uncompromising reality: If you're not first or second in the mobile race, it really doesn't matter who has the bronze medal, you're in the same boat as all the vendors behind you.

— Andrew Binstock
Editor in Chief
[email protected]
Twitter: platypusguy
Google+


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Comments:

ubm_techweb_disqus_sso_-d7a8986fb28f70b7662aa87f1a1e5957
2015-11-01T11:35:43

I read this interesting research from Good Technology (I dont work for Good or have any association with them), but found their tracking study interesting...

Summarised here.

http://www.kumulos.com/2015...

In short it shows a shift towards Android and Windows at the expense of iOS for recent tablet sales. My guess is that this is being driven (in a large part) by big adoption of tablet devices for business apps (workforce efficiency/mobility), when you have the app running on hundreds of devices and iPad is 4x the cost of a decent android tablet.. and you can control the form factor & OS versions it makes real sense to go Android....

Seems to say that apple will own the consumer market but Android (and increasingly Windows) will dominate the (arguably much more attractive) corporate market for workforce apps.


Permalink
ubm_techweb_disqus_sso_-ab330612a18c3ae58f26f526c4609c7e
2014-12-04T20:38:13

No self-respecting s/w developer would resort to HTML5, PhoneGap, Cordova, or Xamarin and claim to develop apps for mobile devices.


Permalink
Mike_EEE
2014-11-18T23:55:12

Very curious that Xamarin.Forms is not mentioned! It does everything an HTML5 solution does, but done in a native (performant) environment and maintaining native controls/usability, for those finicky users... Plus it's Xaml done right. Even better than MSFT does it (see: custom markup extensions).


Permalink