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 ▼

Nick Plante

Dr. Dobb's Bloggers

Mobile Web Apps: Where Are We Now?

December 18, 2009

Awhile back I wrote an article for CodeTalk called Web Apps As First Class Citizens in which I advocated use of tools like PhoneGap to build web-based multi-use iPhone and Android applications instead of the richer but client-specific native toolkits (where appropriate).

Well, it's been almost a year since I wrote that, and native applications still rule the roost in both the iPhone and Android camps. And it doesn't look like the situation is going to change any time in the near future, either. But that's not to say that we're entirely without hope that mobile web apps will one day stand shoulder to shoulder with their native counterparts! 

As I mentioned in the original article, toolkits like PhoneGap and jQTouch already exist and can help ease some of the pain that mobile web app developers experience when trying to build native-quality web apps for the iPhone. However, numerous problems continue to make this impractical for many. For example, MobileSafari's lack of support for fixed position CSS elements, overall responsiveness, access to certain important hardware features, and mostly, missing native _feeling_ behaviors. In many -- perhaps most -- cases, struggles with these problems ultimately force serious app developers to pursue a native client approach, even though it comes with an expensive learning curve and of course the problem that it's an app-specific interface that needs to be maintained in addition to an existing web presence.

So will mobile web app developers ever be able to overcome these seemingly insurmountable odds? Well, maybe. I'm still holding out hope, anyway. Technically there's no reason that many of these features can't be made available through WebKit, if only the powers that be at Apple (and their Google equivalents in the Android world) saw fit to emphasize this.

And then again, maybe they already are. 

John Gruber of Daring Fireball fame recently wrote about PastryKit, a framework that eases a lot of the pains for iPhone web application developers. You can see a PastryKit-based application in use at the iPhone user guide site (change your user agent to MobileSafari before clicking that link if you're visiting it from a desktop web browser). This resource has actually existed for quite some time. So it's nothing really new per se, but I certainly hadn't heard about it or noticed it before. And the creator of the toolkit? Apple. Interesting, indeed.

Gruber provides more technical analysis of the kit over at Daring Fireball and I'd encourage you to check out the article, as well as its followup, which includes more information and open questions about Apple's possible motivations and strategies. Of chief concern: why has this not been officially released yet? Is it a threat to downloadable pay-for applications in the app store? Or is there some other reason they're holding out? It remains to be seen.

In the meantime, if you're interested in tinkering, an industrious developer from the obligatory Hacker News thread about the topic has yanked the PastryKit source and pushed it up to a GitHub project repository for your hacking / browsing pleasure. And David Calhoun has an even more thorough dissection of the JavaScript itself.

This is all pretty interesting for those of us who've been hoping for native-quality web dev tool support on the iPhone. I mean, if you're a web developer, already familiar with the tools of the trade, and you could build web apps that looked and felt like native mobile applications, why wouldn't you, after all? Perhaps this battle isn't completely lost yet after all.

Related Reading

More Insights

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.