There’s been lots of commentary about Apple’s unveiling of iCloud at the WWDC. I haven’t had any time to contribute my own views, but I have read a number of posts about iCloud (they’ve been difficult to avoid). One thing that has really jumped out at me is the apparent confusion that permeates the discussion of native applications as contrasted to web applications.
For the purpose of this post, I define a web application to be an application composed of HTML pages running in a browser and define a native application as any application implemented otherwise. The “native/web” distinction seems to be poorly understood, here’s my take.
A web application that does not use local storage/caching will probably be rendered inaccessible by a total network failure. A native application that doesn’t use web storage will probably be rendered unusable by a disk failure that corrupts the user’s data partition. The first is more likely, the second is more catastrophic.
Advancing this scenario to reflect more modern implementations, the web application can use local storage to mitigate network failure, and the native application can use web storage to mitigate disk failure. For modern web applications running in modern browsers, the differentiator has little to do with network availability.
Whether it’s true or not, the perception that native applications are inherently more tolerant of network problems than web applications may come to be seen as mostly irrelevant; it may not always be the case that computing devices frequently lose Internet connectivity. And even if reliable connectivity remains elusive, the list of characteristics that are uniquely associated with native applications, including the ability to run offline, can be expected to shorten significantly: Offline availability, Local storage, Geolocation, Media capture Multitouch, Background processes, 3D are all coming (or have come) to HTML, and the list could go on.
I think the issue that will remain least adequately addressed by web applications is that of performance, particularly performance on mobile devices. Putting aside the use of Canvas for producing graphics, animations and games, application UIs that are both responsive and complex remain beyond the comfortable reach of the processors in mobile devices. And unless a revolution in battery technology occurs this is likely to remain the case.
Even accounting for the recent performance improvements in browsers on all platforms (JS in particular has seen spectacular gains), performance lags native applications. This can be masked by more powerful computers, and often by clever application design, but the gap is real and readily detected by users.
In my opinion, there are two essential benefits to web applications over native applications.
Linking
The URL/URI is an incredibly powerful tool. It allows any web resource(*) to reference any other web resource. This is an advantage that native applications lack, almost entirely. Android does expose Intents but these lack a persistent serialized form (and in any case serve a different purpose), nothing else comes close, except perhaps sharing a URL at which the native application’s executable can be downloaded, but this is a weak simulacrum(†).
Anyone can discover a web application, share it’s URL, and in principle invite everyone else in the world with a browser and a connection to the Internet to use it too. No native application is shared in the same way.
Graceful degradation
Though the Web is cross platform, it’s well appreciated that supporting the huge number of browsers that users can throw at a website comes at a marked price in its development; the time spent adapting perfectly good HTML and JS to accommodate bugs in browsers can be colossal. This may precede attempts to progressively refine the web application to take advantage of new browser technologies which could be available.
For extremely complex web applications which are also required to serve very large numbers of users, I don’t think it’s at all certain that the cost of developing a good web-based UI is necessarily less than that of writing a multitude of native applications that could span the same number of users. But where Web development wins incontestably is that the user experience is elastic and though it may be that only a small proportion of users have the best experience, every user can have some experience assuming their device has a browser. Native applications on the other hand lead to a situation where some people simply can’t access the application and never will unless a suitable native application is developed.
And that’s it — there’s no answer to be drawn from all this, certainly no simple answer. The choice one faces between developing a native application and a web application is deeply nuanced. Personally, I love developing both.
(*) More specifically any resource that is complex enough to embed an ASCII character sequence.
(†) Though I do have ideas about how some classes of native application could be seamless linked in this way.
I’m pretty sure that I’ve seen a few questions asked about stuttering framerates within Android games that were be traced to the garbage collection of String objects generated by Integer.toString().
Avoiding GC cycles is important in animations and games. The Android Canvas class helpfully gives you a drawText method that takes a char[] rather than a String for just this reason.
All you need is some code that will write your integer into a character array. Here’s a small class just for that:
