Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


So You Want to Write A Mobile App? Place Your Bets!

The world of mobile apps is moving so quickly that it's a challenge even to take a moment-in-time snapshot that leads to useful insights. Days and weeks from now, the world might look rather different. To show how profound and rapid the changes are, consider that if you decided to write a mobile app five years ago, the two must-target platforms would have been BlackBerry and Palm. The first iPhone shipped barely a year earlier and was still playing catch up. And as yet, no Android phone had shipped.

More Insights

White Papers

More >>


More >>


More >>

If you were writing apps three years ago, you'd have only just become aware of tablets as a mobile platform and you certainly wouldn't be targeting them. And if you could spiral back just two years ago, you'd be surprised to know that worldwide sales of smartphones would today heavily favor Android. And that the leader in Android devices was Samsung, rather than HTC.

Things change fast in mobile and likely will continue to do so. This quality puts a curious and difficult pressure on organizations developing mobile apps: They need to make strategic decisions very early in the development process. The pressure plays out differently for the two major types of mobile app-creating organizations. The first group, which faces the biggest quandaries, comprises ISVs who are writing specialized apps primarily or exclusively for the mobile market. The second includes most businesses that want to provide a mobile app to give customers or employees access to existing resources.

The ISVs must decide the order in which they will target the major platforms and then how they will do it. This is no easy task. Last year, the established order was iOS, Android, Windows Phone, Blackberry. By some accounts, BlackBerry has nudged into third place, ahead of Windows Phone. It makes very little difference, though, because the reality of the market is that whoever falls behind Android sees very little development attention. The reason is that Android is such a fractured market that delivering and testing an app for Android platforms tends to exhaust developer bandwidth. The organization is essentially spavined by having to work out form factor and OS release issues for numerous Android sub-segments. So, rewriting the app for a third platform with small market share has little appeal.

Because of the fragmentation of Android's installed base, iOS is frequently the first targeted platform. Apple's walled garden approach and limited number of devices favors the development effort, especially for ISVs, who generally produce products written as native apps. However, as Android expands its market share (especially on a global basis), choosing the correct sequence becomes increasingly complex.

Which brings us to the second major decision point: How to write the app? Todd Anglin, who heads up cross-platform tool development for Telerik, the makers of the Kendo UI toolkit for mobile apps, elegantly sums up the range of choices:

  • Native: Write a completely new app using the native APIs for each platform. This gives the best-looking, most functional apps, but is not portable.
  • Hybrid: Some parts native, some parts portable across platforms. Frequently consists of an HTML and JavaScript core, wrapped in a native layer. PhoneGap is the canonical example.
  • Cross-compilation: A variant of hybrid, it uses non-native languages, which are then compiled to the native platform. Xamarin is the primary vendor of this approach. (We recently reviewed two of their product releases.)
  • HTML5: The most portable solution; but criticized for a non-native look and apps that lack access to many of a devices' capabilities.

Choosing the development approach is, in many ways, the more important of the two decisions and, in many situations, it might obviate the choice of platform. Businesses, for example, which simply need to provide a mobile version of an existing feature to their employees overwhelmingly choose HTML5, which runs with little modification on all the major platforms, including BlackBerry and Windows.

However, things get a lot dicier if the requirements for an app exceed the capabilities of the Web and HTML5, and budget precludes native versions for all platforms. (Let's remove the cross-compilation option from the discussion, as it is a solution that applies only to organizations with unique needs and qualifications.) For the last few years, the hybrid approach has been a workable solution, which explains in part the popularity of PhoneGap. However, Anglin confirms that recently another trend has emerged, in which developers write a native application for the one platform they view as most vital. They then use HTML5 or a hybrid approach to port the app to all other platforms.

I am not sure that this is a trend that will stick. It essentially doubles down on a single platform — a terrible proposition in a fast-changing market presently dominated by two players, and it doubles the cost of development, albeit with the benefit of comprehensive platform coverage. What it does convincingly do, however, is demonstrate the very difficult choices organizations face when committing to a mobile strategy.

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

Related Reading

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.