MWC2013: Is Mobile App Development at a Crossroads? Dilemmas for 2013

The number of  app development ‘solutions’ on show at Mobile World Congress 2013 amounted to over 20, and might have been over 40 once you counted in development tools provided by major offerings that were not explicitly on show (for example, Eclipse or the .NET Framework). Yet such a plethora only served to emphasize just how dissipated has become the mobile app development decision scenario — for individuals as much as enterprises.  Hard, as well as expensive, choices are inevitable for those wishing to deliver rich results in 2013.

A little over a year ago the shape of mobile app development seemed to fall into 3 main categories:

• the Web-like
• the Native
• the Hybrid.

The Web-like app aims to provide an app experience which adjusts to whatever smart device size/type is being used.  This approximates to what you would find with a browser and pretty much requires an online connection (i.e., you usually cannot use such an app offline).   The advantage is swift delivery, the ability to minimize consideration of device characteristics and use of existing enterprise web infrastructure; the disadvantage lies with the need to connect to a server, plus the limits on the degree of app elegance that are possible within such an approach — although this is balanced by good security, in effect, enforced through the connection.

At the opposite extreme lies the Native app.  This is full-blooded app development using the likes of Xcode (with Objective C, for iOS), Eclipse (for Android) , Visual Studio (for Microsoft’s WindowsPhone 8, Windows 8 RT and Windows 8) or the Blackberry NDK (with C/C++ for BB10).  All these in different are familiar tools to IT developers.   The primary advantage is that full programmatic capabilities are available and that the app can be self-standing (an increasingly common requirement) but with this comes the disadvantages of complexity, the need for advanced skill sets plus longer development and delivery times.  (Security enforcement can occur at whatever level is appropriate.)

The Hybrid comes somewhere in-between.  Most commonly it is associated with some form of native container which exposes a limited set of APIs in order to obtain increased capabilities.  Almost always some level of library involvement occurs (to provide common functions).  App creation comes via ‘products’ like PhoneGap or Appcelerator Titanium  or Globos with some form of  ’compilation’ at the end to create the app.  As you might expect the advantages and disadvantages are a hybrid of those for the Web-based and the Native — with app security being better than the first though not as good as that coming from the second (the Native).

This categorization, however, hide a larger part of the puzzle — which involves deciding which platform(s) you wish to use.  This can be summarized in a table like that below:

At its ‘worst’, if you wish to provide a native app for all four mobile platforms, you will need to have development skills in four different development environments — Xcode, Eclipse, Visual Studio and NDK as well as the relevant development languages.  This will be expensive if you are responsible for creating an app which can run on all major device variants.

The natural management preference is, therefore, to simplify.  But selecting the Web-based app approach, while vastly less expensive, is likely to produce apps that disappoint on one or both of its two challenges — the quality of the user experience and/or the desirability of being able to use the app offline.  The appeal of, say, HTML5 as a cross platform delivery mechanism sounds great but simply does not produce the quality of result that most now expect to have to deliver.

The Hybrid approach, while enabling a richer delivery than the Web-based, does not see to offer a great deal more.  (The downsides of the Web app and the Hybrid were demonstrated, rather ironically, by the official MWC2013 app which needed a connection in order to find what you were looking for within the exposition.  It remains an ongoing irony that the MWC organizers and/or their sponsors seem unable, or unwilling, to provide comprehensive mobile communication for attendees — though, to be fair, to do this for four days  in an internal space of c 100,000m2 occupied by c 50,000 people a day and probably with in excess of 150,000-200,000 devices is a technical challenge for anyone.)

Unfortunately, the conclusion to emerge seems to be that — if you want to contain cost and complexity when building mobile apps — you must:

• either choose one (possibly two) platforms (from iOS, Android, Windows or BB1)
• or decide that the Web-based and/or Hybrid are adequate.

Yet this is, in effect, a technical decision.  It may not be what the business wants, which is sophistication suited for purpose. Fit for purpose transcends complexity and cost issues, which is why the mobile app world is becoming so expensive.

An example: the Economist has an (offline) app for the iPhone, iPad, Android and the Blackberry Playbook (though not for Windows 8 or BB10).  Thus those who are on Windows 8 and BB10 cannot read offline.  These existing apps, in effect, replace the experience of reading the physical magazine (though it calls itself a newspaper) by placing the content on-screen.  If, however, the reading experience is not good, then any publisher risks losing subscriber  enchantment.  As it so happens, the Economist’s Android app has problems: it crashes inconsistently.  This is, for the publisher, a nightmare.  It is as if the ink on the printed version suddenly disappears, but might reappear later — or might not.  While nobody likes a bad experience what is possibly worse is an inconsistent one: if you do not know what you will receive, even though you may most often receive what you want, you will likely despair.  In the Economist example the fear must be that a subscriber will give up and cancel his or her subscription — because he or she cannot read when he or she wishes to read.

Where does this lead? MWC2013 proved unable to deliver evidence of impending simplification of mobile app development.  In fact it was rather the reverse.

In an ideal world one would like to design and create in one ‘master environment’ and then use this as the basis to generate optimized apps for each of the selected target platforms.  When IBM bought Worklight in early 2012 it obtained an approach very similar to this, for this was Worklight’s specialty.  Yet today’s IBM solution, incorporating a mix of Worklight and Rationale (and Tivoli) technologies and experience, represents — as you might expect — traditional IT application  development applied to mobile platforms.  It works.  It is also heavyweight (and necessarily expensive).  But is may also only have limited relevance (mainly to IBMs traditional customers — large organizations) and be top-heavy for those who wish to be nimble and flexible.

This raises a question, implicit in what was shown at MWC2013: is mobile apps development at a crossroads:

• either you accept the IBM approach, app development becomes more and more like traditional IT development — which may be fine for enterprises but does imply a certain association with cumbersome and painful delivery schedules
• or you hope the platform owners (Apple, Google, Microsoft and Blackberry/RIM) will combine to make native app development simpler and with much reduced inconsistencies — perhaps creating a unified app development environment (candidly, hell will freeze over long before this happens — and why should they be interested?)
• or some innovation appears which enables a single design and build approach (much like that originally delivered by Worklight) which can then be pointed at the selected target platforms.

For those looking for mobile apps development to be in swift, responsive, fresh and quick to market, the first option provides an increasingly negative association with traditional IT practices (slow, expensive, unresponsive, etc.).   In contrast mobile apps at present possesses positive associations and aspirations.

Now consider what might happen if (say) an innovator delivered multi-platform/device app creation in (say) a SaaS-type fee-based  model wherein:

• the design and build (and initial testing by simulation) occurs off-line (but could be on-line)
• optimized platform-specific app versions arrive after submission online to a ‘creation service’.

With such an approach mobile app developers could concentrate on form and function, and less on platform specifics (indeed the better any device/platform simulators, the better the ultimate outcome).  The qualities of “swift, responsive, fresh and quick to market ” would combine with those of high quality native implementations optimized for the relevant platforms.

Is this a total pipedream?  On the raw evidence of MWC2013, yes.  But interesting innovators are constantly appearing, if not going far enough.  For example, take Apmato (Berlin, Germany) — which is ready to offer a SaaS-like, friendly mobile app development service for all sizes of business.  It has decided to implement an approach like that of Content Management Systems — any Apmato app consumes content from Apmato content servers with Apmato providing a whole mobile app service (even down to managing the submission process to Apple or Google).  While this does not go anywhere near as far as providing a full native mobile app development service, it does provide much of what a mobile native app development service back end needs.

If MWC2013 provided no obvious answers it did provide indicators.  The most important is that mobile native app development for any one platform will continue to be expensive in 2013 and even more so for more than one platform.  As customers (enterprise or consumer) buy their own devices, trying to limit choice to ‘just’ iOS or Android will be infeasible.  The result will be multiple mobile app dilemmas in 2013 — but there are some indicators of what might happen by MWC2014.