Most companies that want to create an iPhone app think in terms of hiring an iPhone developer, specifying the application, and having it lovingly hand-coded from scratch in the purest Objective-C with dazzling graphics and a lively, professionally designed user interface. That all sounds great.
Then reality hits. What did the first app cost to develop? What will it take to adapt to other devices in the iOS family? An additional 20 percent of the original cost for each variation? Well, maybe that's not so bad. So, what would it take to build a Google Android version? What do you mean, you have to start coding from scratch, and all you can reuse are the master graphics? And what about BlackBerry, WebOS, Windows Mobile, Nokia -- the same again? Ouch. Furthermore, that first iPhone developer may or may not have the chops to develop for all those other platforms. What are you going to do -- hire a developer per platform?
WebKit to the rescue?
The mobile browser may provide an answer. Browser support for extended features of mobile devices, such as the iPhone, iPad, and Android smartphones, is starting to be good -- very good, indeed. Two recent projects illustrate what can be done beyond what's already built into WebKit for mobile devices.
The jQTouch project, an extension of jQuery, presents native-looking UIs with animations, callback events, swipe detection, and support for location and other extensions. jQTouch was created by David Kaneda and is now being maintained by Jonathan Stark; it's offered under the MIT open source license.
Sencha is the merger of Ext JS, jQTouch, and Raphaël. Kaneda is now working on Sencha Touch, billed as "first HTML5 framework for mobile devices," and just released to public beta. Sencha Touch looks even more impressive than jQTouch at this point. It is offered under GNU GPL license v3; there is no commercial license option for the beta, but presumably there will be one for the released version.
Let someone else create the app platform
Another approach for delivering apps on multiple platforms is to let someone else create the base app for each device and the framework for its functionality. That's old news for content application services like Handmark and Zinio. For years now, they've had native base content display applications for each mobile platform, all talking to a common back end. Above the base application level, they abstracted as much of the feature set as possible to be platform-independent, supporting standard formats for content feeds to the server and defined feature sets and graphic resources on a brand-by-brand basis.
It's a similar to the approach used by cloud providers and RSS reader developers. That means that when Handmark or Zinio develops a new feature or supports a new device, that improvement to the platform becomes available to all the brand partners. That's both good and bad: If having a truly differentiating content app is important to you, the Handmark approach may not be for you. And if you want to develop yourself using Handmark's or Zinio's platform, you're out of luck: They're strictly in-house tools.
But this approach could also work for other application types than content apps. Perhaps the emergence of cloud-based processes, for example data analysis via Hadoop or validation and formatting of XBRL financial data, could pave the way to such managed app platforms.
Will these or other frameworks pave the way for mobile apps that don't have to be written from scratch for each platform? I certainly hope so.
Meanwhile, don't throw out your Android or iPhone SDKs.
This article, "Possible escapes from the mobile SDKs' clutches," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog.