This piece is a critical response to Matt Gemmell’s July 22 post, “Apps vs the Web”. In that post Matt outlines the differences between native mobile apps, which we should read as iPhone apps, and web-based apps, describing the advantages and disadvantages of each environment and judging in favor of native applications. The conclusion isn’t surprising, as it reflects Matt’s own interest, abilities and real expertise with respect to Objective-C development and Mac and iOS usability.

Introduction

Matt develops three arguments to support his conclusion. The first concerns Frames of Interaction, the second Separation of Concern and the third System Integration, or native UI. In reality there is a single underlying premise here which Matt seems at times to recognize but does not genuinely pursue, namely, the premise that web apps must run in privilege restricted web browsers. I’d like to show that this premise is a false one and that once we recognize that web apps can run in dedicated environments, the distinction collapses and there is no real reason to favor a native platform over a web-based one.

I would like to emphasize, however, that my own conclusion speaks to a possibility. There will be no real reason. Dedicated environments for web applications with access to native hardware such as video cameras and audio inputs are to my knowledge not yet available for the iOS mobile platform. The point is they could be — the technology already exists on other platforms, including the Mac OS — and that we can instead read Matt’s conclusion not as a judgment against web based apps but as a call to action for that community of developers.

The Argument

Before Matt begins his critique he distinguishes between four different kind of apps. It is here that he first recognizes that a web app can in fact run within a web view inside a native shell. But Matt then ignores this possibility in the rest of his critique, which, as a number of his commenters have already pointed out, leads him to argue against a fictitious, exaggerated opponent. Matt’s own choice of imagery is a prime example of what’s called the straw man fallacy.

An Actual Straw Man

Straw Man on iPhone

Straw Man in UIWebView -- Looks awfully similar, doesn't it?

In his first Frames of Interaction argument Matt describes the increasing distance between a user’s actions and the interface supporting them as device layers are interposed between the user and the activity. We go from a calculator to a sleek calculator on a phone to a very ugly calculator in a distracting web browser on a phone. At each step the user’s focus is disrupted by the additional capabilities of the device. Web browsers confuse the app at hand by adding their own, unrelated “chrome”.

Of course this is based on the assumption that a web app must run inside a web browser, which is not at all the case. The iOS already provides the excellent UIWebView to host web based content in any manner the iOS developer wishes. All we need is a wrapper that displays the view in full screen and points it to a url. Doing so completely dissolves the browser layer and provides an environment similar to the native app. As I’ve mentioned Matt made note of this possibility but then he immediately ignores it.

The Separation of Concerns argument is an extension of the Frames theme. We generally have separate tools for different tasks: web browsing, emailing, document creation, etc. Not so with web apps, argues Matt. Web apps run in a single are of concern — the browser — and badly fracture the user’s focus by requiring her to switch back and forth between tabs and windows in a single application. This adds yet another level of interaction.  “We’re all guilty,” writes Matt, “of ignoring the fact that the browser is not the same as the device itself. It’s another level in the hierarchy, and you can’t pretend otherwise.”

Again, however, Matt is himself guilty of ignoring his own remark that web apps do not require browsers. As soon as the web application is hosted in its own environment, all of these issues disappear. There are no tabs, no windows, no additional hierarchy and no fractured attention. There is just the web app, as there is just the native app.

Matt’s final argument is the strongest of the three. Web applications, he says, must give up the native capabilities of the platform such as access to hardware including GPS and audio/video input. They must also give up integration with the rest of the platform. Web view wrappers can only go so far here, although Matt does finally recognizes the possibility of web-platform integration. He concludes that developers will choose to go all native because, basically, it’s harder to do hybrid.

Of course, it’s also harder to go the other direction and do web-integration with a native app. The iOS system frameworks don’t support Google docs or Google calendar or Facebook, Flickr, Twitter, Netflix, Hulu, etc. As users shift more and more of their digital existence to the web perhaps these will take priority over Apple’s own products, much, and already, no doubt, to Apple’s chagrin. But the present point stands. What about a web app’s access to Apple’s own platform?

Finally, Matt ties in UI considerations as well. Users have an emotional attachment to their products — particularly it seems, Mac users — and they expect their applications to be well designed. Web apps just don’t have the look and feel of native apps. Cross-platform is a pariah in the Mac community.

There is, however, no intrinsic failure here. If a web app does not feel like it belongs on the iPhone, the fault lies with the designers, not with the platform. If web-based frameworks, be they css/javascript, php, ruby or even perl, are not yet available to replicate the look and feel of a native iPhone app, this is only because the work hasn’t yet been done.

A Call To Action

Which leads me to the matter at hand. Now I may have been too hard on Mr. Gemmell here. Matt is critiquing the normal state of affairs. Many web applications don’t have dedicated wrappers, and even when they do their access to hardware and platform features is difficult and restricted. So instead let’s read Matt’s critique as a call to action. What can be changed to make web apps the equal of their native counterparts?

Assuming that most web apps are in fact accessed through browsers, the first step would be to support a protocol that allows a web app to run in its own dedicated process. The web app would request this privilege from the user and the browser would then launch a separate process, a fully separate application, to host the web app. This process would be nothing more than a minimal browser, dropping the excess chrome, nav, address bar, bookmarks, etc and without escalated privileges. The Chrome web browser on the Mac already spawns separate “Google Chrome Renderer” processes for every open tab. Why not include the option to run a dedicated app? The user could then save this quasi-bookmark to his desktop.

We have now removed the middling fame of interaction, but what about access to the native features of the platform? Apple has already established a precedent for us on the Mac OS. The WebKit framework supports two-way JavaScript and Objective-C communication using WebViews and WebScriptObjects. Objective-C can execute JavaScript code on a WebView’s currently loaded page and the JavaScript in that page can with an awesome ease call Objective-C code. There are also 3rd party frameworks that accomplish similar goals, such as JSCocoa, PhoneGap and QuickConnect.

With fully supported two-way communication between the web hosted environment and the native environment it should be possible to access the platform specific features of the iOS device. Web apps that target the iPhone environment can gather GPS data, activate the camera and record audio. If a comprehensive framework is lacking, only the effort is required.

Naturally, security concerns arise when such capabilities are introduced to web based applications which are not vetted by Apple’s own procedures. But again Apple has introduced a layer of security which could be adapted to these web applications: sandboxing. What is needed is a way for either web app developers themselves to securely sign their content for privilege escalation or for users to grant varying degrees of permissiveness to the sites they visit. At the least, a layer of security could be built into the platform’s web frameworks themselves.

Conclusion

If web-based applications are not yet the equal of their native counterparts this is only due to limitations which are not essential to the platform. When Mr. Gemmell focuses his criticism on applications hosted inside the web browser itself he ignores the greater possibility that web applications can, and eventually will, operate in their own frames of interaction with full access to the underlying hardware and the coveted look and feel of the iOS platform.

In fact, I believe this development is not far off. It is worth considering why Matt originally wrote his post. The motivation was the Financial Times’ move to a web platform, thus replacing its native iPad app. Might a talented individual who has dedicated so much of his time to the Macintosh platform find this threatening, the possibility that in the not too distant future, his — our — beloved NS, UI and Cocoa frameworks may be replaced by equally capable, more widely accessible web based frameworks?

I recently experienced a shock similar to this one attending a local Cocoaheads meeting. I’ve been developing desktop Macintosh applications professionally for over seven years now and have used and loved Apple products since my first Apple IIe computer. I was astonished, you can imagine, to discover that I was the only desktop developer at the meeting. Every other individual developed exclusively for iOS.

I realized then that the desktop developer is a dying breed. The tween and teen years of the 21st century mark the rise and eventually dominance of the mobile platform. Changes in the Mac OS already reflect this. But if such an evolution can come about in only seven short years, how long can we expect propriety mobile platforms to survive with the rise of web-based content, platforms and social circles?

And so I end this post with an unsettling if hyperbolic conclusion: that in another seven years Objective-C and the Mac and iOS frameworks which are so wonderfully wedded to it will all be dead, replaced by powerful, equally capable, just as beautiful and universally accessible web-based frameworks, perhaps unlike any of the frameworks we are familiar with now. And when that day arrives it will not be a question of preferring native apps over web-based counterparts.

Leave a Reply