Smartphone apps are the most exciting trend in computing since the advent of web apps.  How do you as a developer take advantage of this?  More generally, how do you do that and get maximum reach for your app across the diversity of smartphones out there.  If you’re writing a consumer app you can get away with just targeting the iPhone (albeit missing some market opportunity).  If you’re writing a business app you need to be able to reach all the users in the enterprise.   There just are no homogeneous mobile device environments in any place but the smallest mom and pop shops now.

There are in fact several high level alternatives, but probably only one practical one at a high level.  Let’s start with the most seemingly obvious one:

Write natively in each underlying operating system’s SDK

For example, write your app in Objective C for the iPhone. Write it again for the BlackBerry in RIM’s slightly funky Java variant. Write it yet again for Android in their set of Java SDKs. Code it again in C# for Windows Mobile. And maybe get some reuse when you hack out a Symbian version for Nokia’s smartphones, popular in Europe and Asia.

I’ll actually accept that you might be able to write an app once with the native SDKs and languages for this set of smartphones. But I’ve postulated a theory a while back (when running backend and browser engineering at Good) that I’ll call Blum’s Law of smartphone development:

Businesses cannot maintain enterprise apps written individually for more than three smartphone operating systems past a 1.0 release

I’ll welcome comments that mention counterexamples to this rule.  If you’re planning long term life for your app to address all your users, this is probably not a practical option.

Use First Generation “Enterprise Mobility Platforms”

There have of course been earlier approaches to the diversity of mobile operating systems. They emerged around ten years ago from the likes of Sybase, Antenna, Dexterra, Pyxis, Vaultus, Plusmo and others. None of them got much more than a few dozen customers and much more than tens of millions of revenue. Although big corporations got benefit from them, they never came close to becoming ubiquitous enterprise infrastructure.

They all share a remarkably similar approach and set of components. Generally these are:

• an Integrated Development Environment (IDE) - design the screens for the app in a desktop editing environment generally with some kind of WYSIWYG preview.  And (for some) describe the connections to a backend data source.
• a “runner” or “interpreter” on the device.  This runner is built by the vendor for each device operating system. It generally included featurephone operating systems including J2ME and BREW.
• sync server - Sometimes this is general purpose (such as Sybase).   Sometimes this is just common code shared among “backend connection server apps” (such as Antenna)

When these technologies first appeared there was nothing wrong with this approach.   It allowed apps to run in fairly forbiddingly limited environments such as those on most featurephones.  With the advent of modern highly powerful smartphones the interpreter approach to save space wasn’t really necessary anymore. But what sealed these technologies irrelevance was the App Store ban on interpreters. Instead of a “platform” that involved an interpreter to which apps are sent, a radically different approach was called for.

Smartphone App Framework

Last year we released the first version (0.1) of Rhodes calling it a “smartphone app framework”.  The biggest difference is that the framework enables you to build native smartphone apps indistinguishable from what you might do with the underlying SDK.  You can think of the framework as a library of code that you link into your app,  a set of directory conventions for where you put your files and scripts to build the app.   But, more excitingly,  you can write your whole interface in HTML, the most widely known development technology in history.  But you still end up with a NATIVE app that looks native and takes advantage of device capabilities.

Since then this has become a huge category with many entrants.   These include WidgetPad, Appcelerator, QuickConnect, Ansca Corona, and PhoneGap.  These frameworks are all a big step forward in productivity and finally allow the law that I cited above to be violated.   They all also follow the practice of allowing you to write your interface in HTML.   If you don’t need the synchronized data offered by Rhodes, the ability to have a full-on programming language (the first mobile Ruby for every smartphone) or the availability of Rhodes for all smartphones, each of these products is a good option. My personal favorite would be PhoneGap, but they are all a huge step above writing in native SDKs and languages.