Further Thoughts on Web Apps

In the ongoing saga over (iPhone) native apps versus (iPhone and cross-platform) Web apps—read parts one, two, three, four, five and six—there are a few more things I want to point out. First, however, let’s detour quickly to Martin Pilkington’s rebuttal to Peter-Paul Koch’s original rant:

It also supports JavaScript geolocation, which is (I hope) only the first step towards true device APIs that will give JavaScript developers access to phone functionality such as the camera, text messaging, the address book, and more. I’m assuming Apple is working on all that because it’s the next logical step.

That is a very poor assumption for one very important reason. Most people don’t want to have their address book read in and text messages sent (at their expense) to all their contacts asking them to visit a website, after they [themselves] visited that website. There’s a very good reason websites don’t get access to system APIs and this is it.

Ironically, this is a poor assumption on Martin’s part. Privacy and security apply just as much to a desktop or native iPhone app as they do to websites and web apps. Most people don’t want to have their address book read in and text messages sent to all their contacts no matter what platform the cause is on. There were a couple of iPhone apps that took advantage of the Address Book API and those were revoked as soon as that was found out. Yes, it would be harder for a company like Apple to suddenly block a single website than it is for them to pull an app from the AppStore, but this isn’t why such APIs don’t exist in the browser. They don’t exist because it’s all just too new.

The web as a platform for building apps on has only really been around for a half dozen years, and most of that time was spent focused on AJAX and preventing page loads between each action. Compare that to the desktop, where system APIs have been around for decades, and it makes perfect sense that browser vendors are only now just starting to explore opening system APIs to their browser. The security aspect makes it more difficult and more challenging to implement, and that undoubtedly plays a part in there not being an Address Book API just yet, but to claim there never will be one is shortsighted.

Another thing to keep in mind is that web technologies tend to be open standards that a lot of competitors need to agree on before they become Technical Recommendations. This makes progress happen very, very slowly. On the other hand, the Geolocation system API has gone from initial Working Draft to its current Last Call WD status in less than a year.

Safari’s support of appcache makes it possible to store the Web app’s core files on the iPhone itself, so that it only has to download the data. Thus mobile connection problems can be avoided.

But then you need a cache of the data stored locally and the ability to modify the data locally, meaning your web app needs to be run locally. What we have there is a mobile app built with web technology.

Which is kind of what PPK is calling out for, so I’m not sure what Martin’s point is, here.

A web app that runs entirely locally, even a web app game like Neven Mrgan’s Pie Guy, is a perfectly fine app on its own right. There’s nothing inherently wrong with doing that, and native developers should definitely not frown upon it. In fact, Neven’s Pie Guy is a great example of an app that alleviates the big hosting cost argument (which was Martin’s next argument): once installed, all of Pie Guy’s game code is on the device, and it only checks the source website to see if there is newer code to update itself with. That’s hardly a hosting concern, so again: native developers should not frown upon this.

For the rest, though, Martin’s post has a lot of good points, but my favorite is this:

Most X developers (for any non-Web value of X) live in mortal fear of the browser as a development platform.

That depends. Can I offer the best user experience while supporting these multiple platforms? Building a general web app that will run well in any browser is much like building a desktop app using Java, it often leads to an inferior user experience as you can’t provide a consistent feature set and use advanced features of each OS it runs on. Personally I’d rather develop for one platform and build a kick ass application than develop for a wide audience on multiple platforms and build a mediocre application.

In my experience simply as a user of many applications, desktop, web and iPhone, this holds true for every great developer out there. They aren’t the kind of people to blindly shun one platform in favor of another, they simply choose the platform(s) that they can offer the best user experience on that will also generate them money. For mobile apps, the iPhone and its native apps platform is currently the best at offering developers that.

Some further thoughts

Returning briefly to Neven’s Pie Guy, one argument that PPK makes is that web apps can provide the same quality as native apps. Pie Guy, whilst only a first release, doesn’t exactly perform well on a non-3GS phone. In fact, on my 3G it is so slow that it’s pretty much unplayable. I downloaded Pac-Man Lite, the closest equivalent of a game with no heavy graphics, and that performs perfectly fine on my 3G phone and has sound.

But then, that’s kind of the same for also all the visually stellar, audio-rich—and native—games I’ve played on my 3G. My point is, performance plays a big part in quality and user experience, and the performance of web apps is simply nowhere near close enough yet to compare them casually to native apps.

One reader wrote in to say that the JavaScript performance article I linked to in my first response to PPK was two years old, and that “JavaScript perf has come a long way since then.” Yes, it has—but not so much that it compares to native, compiled Objective-C code. Not even close.

Then there’s the tools argument. PPK’s latest post finally mentions the Cocoa Touch framework, but:

John Gruber wants me to mention the Cocoa Touch framework. He feels that its excellence is an important factor in the success of native iPhone apps.

Point is, although Gruber’s probably right, he ought to be wrong.

My take-away from PPK’s three posts on this subject is that he has never spent as little as five minutes looking into the iPhone SDK and Cocoa Touch. It seems that PPK suspects that iPhone developers have never bothered looking into HTML, CSS and JavaScript—and since he himself has never explored Cocoa and/or Cocoa Touch, that would explain why. Case in point:

If all you have is a hammer, every problem becomes a nail. If all you know is the Cocoa Touch framework, every app you make will become a native iPhone one, whether that’s a good idea or not.

The reality is, I don’t know of a single iPhone developer who doesn’t know the core web technologies at the very least. They may not be Web Standards experts like PPK or yours truly, but they certainly aren’t oblivious to them. They’ve explored them, certainly rudimentary, and clearly have not seen much of interest there so far. This makes sense, as there isn’t much of interest in the Web’s three main technologies compared to Cocoa / Cocoa Touch.

My personal experience with the iPhone SDK has only been very superficial, but already I can tell what a great gap exists between it and the Web as a platform. My plan for the remainder of this calendar year is to explore the SDK and start building some apps to get more first-hand experience in that area. My progress will be documented here, of course.

Getting back to the tools argument: Martin Pilkington claimed that “web idealists deplore [technologies like] Silverlight and Flash”, which offer the tools that compare to desktop apps frameworks and are far superior, tool-wise, to the basic HTML, CSS and JavaScript of web apps. The problem is that Silverlight and Flash aren’t exactly hallmarks of great User Experience; their performance is quite horrendous, they are historically rife with security problems, and—a big issue for web idealists who care about an interoperable and open web—they are entirely proprietary. “Web idealists” don’t like undermining some of the best aspect about the Web by throwing their lot in with proprietary technologies like Silverlight and Flash; there’s a time and place for proprietary platforms, but the open Web isn’t one of ‘em.

(I’m sure Aral will have some comments about that last paragraph, but I’m moving on for now)

ITunes matters too

In addition to all this, web apps have another distinctive disadvantage: no integration with iTunes. My apps from the AppStore get backed up automatically once I connect my phone, there’s a nice interface in iTunes that allows me to organize my home screens with the mouse, and when I beta test an app that the phone I just connected isn’t provisioned for, iTunes knows not to remove the installed (public) version. The latter may not be applicable for most every iPhone owner out there, but it is one more example of how seamless the experience is, in part thanks to iTunes.

Web apps, until or unless they get a different, better treatment from Apple, won’t have those kind of benefits. Especially when it comes to paying for an app, the web loses out tremendously in offering a quick, simple and seamless experience.

Where web apps would win out, in an ideal world, is device independence and interoperability, but again: that’s not the real situation we have right now. Devices differ too much, even those that all run a Webkit browser, for any web app of great significance to be immediately interoperable across all platforms. In fact, the past eight years of my life have been spent trying to make the browser situation more consistent; I can assure you that we are far from a world where that is the case.

Lastly, there is this:

What do your users want you to pick, superior user experience or vastly bigger reach? Do you need device APIs, and is there a way to get paid? Those are the questions that matter right now.

I don’t know what numbers PPK has in his head, but if the iPhone platform outsells games up to 400 to 1 against the Android platform, that “vastly bigger reach” argument falls flat on its face.

I’d like to propose something to PPK here: before saying anything else about this entire issue, either man up and try porting a native app as a web app to back up your claims, or try building a native app with the free iPhone SDK (you don’t have to join the paid program to download the SDK, just a registered free Developer account will do).

Without doing either, you’re just increasingly embarrassing web developers here.

If you liked this, you should follow me on Twitter!