In Search of the Holy Grail

(I originally wrote and published this article for ReadWrite Web.)

Finally, it feels like the holy grail of mobile development is at hand. This problem has persisted since Microsoft released Palm-sized PC operating system to compete with the Palm OS a decade ago: as a mobile developer, the cost of supporting multiple mobile platforms, each with a relatively small user base and massive development learning curve, is huge. That finally seems to be changing.

In the Beginning

When handheld computers went mainstream, developers really had only one choice: Palm Pilot. Within five years, they had Symbian and Pocket PC (later Windows Mobile) to consider also. By 2009, there were no less than eight major operating systems for smartphones: two versions of Windows Mobile, two versions for Blackberry, iPhone, Android, Symbian, and webOS, not to mention traditional feature phones running various flavors of Java.

The Impact

Developers were forced to make the tough choice of which operating system to develop for. Making it harder, customers were scattered and were requesting versions of a variety of platforms, with no one platform controlling the market as was the case in the desktop world. Until a few months ago, they had only one choice: develop for each platform independently, picking and choosing which to support, each with huge costs and unknown payback.

That, however, is changing. Developers now have three ways to develop cross-platform. And while these technologies are still in their early days, they will evolve rapidly.

HTML 5 and the Mobile Web

One option is to forgo installed applications altogether and develop mobile Web applications. HTML 5, with its access to local databases, makes this possible. There are two major obstacles to this strategy right now: first, ubiquity of HTML 5-enabled browsers and, second, the willingness of customers to accept it as a standard.

While the first will be solved with time and pressure from other OS platforms, the second is a bigger problem. The customer’s willingness to accept Web-based applications is a psychological change that takes years to evolve. Device owners have been trained that cell phone connections are inherently unstable. In many places the connection disappears, and until that is resolved this mental adjustment cannot even begin to take hold.


Adobe recently announced its push into the mobile space, with Flash-enabled browsers for most platforms and a Flash-to-iPhone-app compiler for Apple’s smartphones and handhelds. This would allow developers to write all of their apps in Flash and then deploy on multiple mobile browsers and the iPhone via a compiled application.

This still suffers from many of the same disadvantages as HTML 5, because it requires a psychological change in customers to accept running apps in the browser. In addition, Apple’s hard-nosed stance against Flash in the browser will impede this movement because it will require two completely separate creation processes.

Finally, for Flash to take hold, operating system manufacturers will have to start treating Web-enabled applications the same as non-Web-enabled ones. For example, launching Web apps from the home page must become standard.

JavaScript Native Apps
A new class of applications has arisen. These are native applications that are compiled for a specific platform but that use Web technologies for the user interface. This has the most potential. The most prominent one currently is PhoneGap. Other solutions include Appcelerator, which uses PhoneGap technology under the hood, and Rhomobile, which uses the Ruby on Rails Web development language.

These technologies, all open sourced, enable developers to write back-end processes in the native code and all of the user interfaces in HTML, CSS and JavaScript. This application is then compiled into a native application. It can be uploaded to app stores, distributed via downloading and installed directly to the device.

The fundamental problem with mobile development isn’t the back end, though. The backbone of all of these platforms is C or Java, which is generally portable if written with that intention. The problem is user interface development, which requires deep knowledge and understanding of each mobile device. Making the UI cross-platform solves the vast majority of problems associated with this kind of development. If you had to point to where the approach falls short, it would be that cross-platform applications don’t feel “native,” a shortcoming that would be solved by good design and better CSS work!

As the smartphone market evolves, we are unlikely to see a clear winner as we did in the PC business; and because of that, developers will be forced to write for multiple platforms. But for the first time in a decade, developers have options for multiple-device development. The cost and learning curve associated with writing native apps for every platform can finally be mitigated.

While all of these technologies are early to market, the writing is clearly on the wall. After more than a decade of discussion, the combination of Flash, HTML 5 and JavaScript will make “write once, use everywhere” a reality.