Native iPhone apps vs. Web apps

Well, that was an interesting ride. Besides passionate agreements, my previous post also elicited passionate disagreements.

My post could be construed as a rant. Hell, parts of it were a rant. (Nobody said this blogging stuff is easy, especially when you’re passionate about something. But if I can’t speak my mind here, what’s the point of having a blog?)

Several people I respect a lot said that I’d made a stupid mistake and was just plain wrong. After some thought I decided they are right.

I was wrong about Web apps being able to replace native apps right now. I was wrong about the iPhone developers’ mindset. They aren’t stupid.

Special thanks go to Dion Almaer and Faruk Ates, who took the time and trouble to write a factual rebuttal of some points, as well as Andrew Hedges, who provided me with a few examples when I needed them most.

While writing the current article I figured out there’s a whole lot of undigested information in my head that I instinctively used in my previous article but didn’t bother to explain properly. This is especially true for payments and the general state of Web technologies on mobile.

Despite my mistakes the whole thing seems to have kick-started a solid, sensible discussion about the differences between native apps and Web apps, and which one is better under which circumstances. I’d like to continue that discussion.

My original idea was: with a few exceptions, native apps could just as well be written as Web apps. That would bring much better interoperability as well as avoiding Apple’s insane App Store approval process.

It’s all about the money

The strongest argument against my idea is that the App Store offers an easy and convenient way of making money with your apps. I did in fact think about this a lot while writing the original article, but in the end decided not to mention it. That was a mistake.

Mobile payments are a complicated subject that I have my own thoughts about; thoughts I planned to discuss in a later blog entry.

I feel that the mobile operators have the strongest cards when it comes to mobile payments because they are already billing everybody and are already able to identify people through their SIM card. Their system has to be extended in order to accomodate online payments, but that seems doable. In fact, Vodafone is already doing it.

Since Vodafone is my main client now, my plan was to get some more publishable info about how it will work and how it impacts Web development before blogging about it. This crisis has forced my hand, however, so I can’t offer you the level of detail I wanted.

Suffice it to say that a system that might fulfill the same function as the App Store, but works throughout the Web on (presumably) all Vodafone devices (and possibly many more), is probably coming.

This idea was in the front of my mind while I wrote the article, but I did not realise that I had not yet explained it to my readers, nor that a system that’s not yet there has no bearing on a comparison in the present.

In addition, I have some qualms about the whole payment concept. I guess I’m just old-fashioned and long for the days where developers would develop just for the heck of it and worry about money later.

Frankly, I hadn’t factored immediate payments in my mental model of an app developer. And I should have, even though my inner geek is saddened by the thought.

Thus I’m forced to concede this point. Right now, getting paid is a lot easier through the App Store than through any other system.

Getting attention

Then comes the discoverability argument. Apparently, getting attention through the App Store is the superior way of disseminating your app. I’d like some more data on that point.

I have no idea what the answer is. Anyone? I myself started with searching, and have now mostly gone to friends’ referrals, but I have no idea how representative I am.

The discoverability argument only makes sense if the answer is searching. Friends’ referrals and marketing work just as well for Web apps.

Device APIs

As I said in the original article, device APIs that give access to device functionality like the camera, the file system, the address book, and so on, are coming. There are some security considerations, and the user will have to give permission for most forms of access, but those problems will be solved.

Geolocation is accessible from the browser already. That’s a start, but it’s not enough.

An app that requires access to device APIs will have to be native for now. Only simple location-based systems are possible on the Web side of things.

My problem is that I’ve been living with device APIs as a reality for months now, and have seen a few simple examples. I just plain forgot they’re not actually there yet.

Offline Web apps

Let’s debunk one argument. It is perfectly possible to write an offline Web app for Safari iPhone. The browser supports appcache and local storage for storing the application and its data, respectively.

Both Web apps and native apps can work offline. Thus this argument has no value.

Interoperability

Let’s chalk up one inevitable point for Web apps. They beat native apps hands down when it comes to interoperability.

To my way of thinking this is an extremely important point. A large part of my previous post was born out of exasperation that I had to explain interoperability yet again.

Could people please be made to see the value of interoperability instantaneously and naturally? Maybe implant something in their heads or something? It’d save me a lot of energy. Thanks.

Interoperability is trumped by UX in the long run, and also by easy payments and lack of device APIs in the short run.

I still feel that the developers of some iPhone apps, especially those that give quick access to specific online data (tweets or train times, for instance), would have been better off publishing something interoperable. They’re competing against similar apps, and being used by 0.1% of the entire mobile Web has much more potential value than being bought by 1% of the iPhone platform.

Then we come to UX. UX is really the crux of the matter. All other problems can be solved, but UX-wise a native app will likely retain an indefinite advantage over Web apps. Still, the question is whether should give up interoperability for UX’s sake in all cases.

In my original article I already cautioned that graphic- and processor-heavy games were a special case. They cannot be ported to the Web. Whatever else it is, the browser is no immersive game platform.

But I might have overestimated the current state of Safari iPhone as a platform. Two commenters pointed out two immediate problems.

They are just browser compatibility problems, though, and I never consider browser compatibility problems show-stoppers. (No good Web developer does, but my case may be a bit more extreme than most.)

I’m going to work on the flash problem later. I have to do massive event research on mobile and desktop anyway, and the iPhone’s event model, especially where it concerns the touch action, is high on my priority list.

But if it can’t be solved, would that matter? Shouldn’t we treat it as the equivalent of the dotted outline; a sure-fire way of letting the user know he has in fact clicked on something? Should we deliberately decide to leave the effect alone, because it’s a platform usability and/or accessibility feature?

Trade-off

... if your goal is to emulate a native app perfectly. If that goal is so important to you that you’re willing to sacrifice interoperability for UX brilliance, yes, then a native app is the way to go.

But there’s a trade-off involved here. Do you want perfect UX, or do you want decent interoperability? Does it make sense for every single app to choose UX over interoperability? As I said above, I feel there’s a category of apps where the latter might be more important.

After all, a nearly native feeling app, or even an app that feels distinctly non-native, can be a perfect tool for a specific set of actions if it’s easy to use.

Does the pure look-and-feel, the cool extras, matter that much in every situation? Experience on the Web suggests this is not the case. Ugly websites can be very popular. As long as users can do what they want to do in a reasonably convenient way, they’re willing to put up with lack of polish.

Flashback to eleven years ago. The graphic designer tells me to publish the entire body text as a JPG because her choice of fonts is not available on browsers. I, an intern having no say in the matter, do it, but feel dirty.

Are we walking into the same trap with native UX? Are we sacrificing too much interoperability on the altar of eye candy? I would not be surprised if that turns out to be the case for some apps.

Web developer on mobile

Right now is a lousy time to be a Web developer passionate about the mobile space.

I hate you

On the one hand the mobile Web is postponed yet again by the success of a proprietary system. An excellent system, but still proprietary. It sucks up far too much energy that could have gone to an interoperable mobile Web.

Worse, Apple’s success has caused every single mobile player to hurriedly start working on an app store, and the situation is getting ridiculous. There are now two to four new app stores being opened every month. The pace will slacken somewhat in a little while, but the situation has already grown preposterous.

I love you

On the other hand, many of these app stores work with Web technologies. They all support slightly different things, but hey, they resemble each other. And they definitely work with HTML, CSS, and JavaScript.

Web is hip on the mobile space. Most players have declared their love for Web technologies in some way or another.

Vodafone, Opera, and Microsoft go for W3C Widgets, and BlackBerry might add support in the not-too-distant future, as might Nokia. Of course they do not use exactly the same W3C Widgets — yet. But the emergence of a proper standard will help here. The players are eager for it, and chances are it will be implemented fairly decently across all platforms.

Even NetFront has a widget manager that works with Web standards, although you cannot scroll widgets, which makes the whole exercise a bit pointless.

If we count Apple’s original interest in Web standards, only Google hasn’t given a peep. Sure, their mobile browser is good, but otherwise they don’t seem to really care about mobile Web technologies beyond viewing sites. But maybe something is brewing there.

I either love or hate you

The real point here, the one that I wanted to think about a bit more, is that right now Web standards are the weapons of choice of the losers in the mobile game.

Apple and Google are the big winners right now, and they don’t use Web standards beyond providing an excellent browser.

All other players, however, the ones that are threatened by Apple’s and Google’s rapid ascent, go for Web standards big time. Is that a good or a bad sign? I just don’t know yet, that’s why I’d have preferred to discuss this point later on.

I hate you

The outreach of these losing companies that bet on Web standards to Web developers is shockingly bad. Everybody wants Web technologies. Nobody cares about Web developers.

Opera is doing its best, but it’s not getting real support from other companies yet.

I suppose my own hiring by Vodafone comes next, but I’m not there as a developer relations manager, although I definitely should write some serious stuff about widget development. So I’m partly to blame personally for the whole mess.

I was especially baffled by the Palm case. Here’s this (formerly) major phone vendor that’s gambling its entire existence as a company on the Web as a platform — as an OS, even — but other than opening a blog and saying there’s this really cool JavaScript library it did not do anything to connect to those people that were its natural allies: the Web developers.

In fact, I doubted my sanity for a while because I just did not understand what was going on. Did Palm figure it didn’t need us because it already had plenty webOS developers? Or was it being stupid?

I love you

Then Dion Almaer and Ben Galbraith moved to Palm as developer relations managers, and everything fell into place. Palm admitted it had made a mistake and was improving relations with Web developers by hiring people who could do the job.

Are iPhone developers stupid?

So that was the mindset I was in while writing the original article and dissing iPhone developers royally.

Although, as I said earlier, some people I respect a lot disagreed with me, and led me to write this article, another bunch of people I respect a lot agreed with my original post.

We once again have to wage a war for the soul of a platform, and point out time and again that Web standards are the way to go if you’re looking for interoperability, and maybe even if you’re not. We know the whole score by heart now.

I see the possibility of making the same mistakes as on desktop, fighting the same battles, waiting the same amount of time, before the mobile Web really takes of. It saddens me. And it angers me.

That led me to lash out to iPhone developers. From the reactions I got it became clear that some of them did consider Web standards, but decided to go native anyway.

But they might become stupid later on, when the Web has become a totally viable alternative, but they refuse to consider it.

Comments

1 Posted by Mathias Bynens on 24 November 2009 | Permalink

Agreed.

Hopefully the future (aka Apple) will bring fixes for the problems you mentioned (i.e. reasons to develop native apps over web apps).
Reading your posts, I have the feeling you now think this is actually going to happen. I have my doubts; if you ask me, #appleisevil – still. Nothing about that has changed since your #fronteers09 presentation.

2 Posted by Dirk de Kok on 24 November 2009 | Permalink

hi ppk,

yes for the moment the iPhone platform is hot and everybody is flocking to it, lured by the massive money that seems to await you in Apple heaven. So the fact that native iPhone development is difficult (Steve J. is a better CEO than an inventor of programming languages like Objective-C) and laborious is put aside as a minor nuisance. The app store commi policies on what is and is not approved is a big risk, but many are willing to take it.

Wait until the other platforms take off (including payment options please) and suddenly developers have to port their app to Android/Symbian/Maemo platform, then everybody will stop using native solutions, as nobody likes to develop the same app twice!

dirk

3 Posted by Jon Henning on 24 November 2009 | Permalink

I went through the same line of thought in deciding how to proceed with a mobile application. UX - I can say that it is possible to get a UI w/ fixed positioning working (though it was pain). I am not aware of the click flash issue. GETTING ATTENTION - It was important that the app got placed in store for discoverability, so we wrote a simple WebView native app wrapper (which got approved last week). This hopefully is the only submission to the app store we will have to do, as updates occur on our webserver. MONEY - our app is free, my company rents dvds through the app and therefore gets paid. INTEROPERABILITY - we plan on supporting additional mobile devices, targeting webkit browsers first, we are anticipating this to be a simple task. OFFLINE - while webkit supports offline cache, the WebView control within the native app does not. The app currently downloads all js/css and data (json) and stores offline. For v1 of the app we do not allow using the app offline (this was a conscious decision that may change). DEVICE APIS - we only cared about GeoLocation.

If anyone is interested search for redbox in app store. If all you have is Safari, you can go to https://www.redbox.com/m (add icon to desktop for ideal exp.)

4 Posted by kL on 24 November 2009 | Permalink

Get those widgets quicker, because iPhone is dwarfing everything else.

We've launched BlackBerry app first, and nobody touched it with 10-foot pole (setting up WebLoader *ActiveX* in the pre-RIM-app-store times was fun...)

Our BlackBerry-optimized mobile website has 70% of iUsers (even though it's primitive and disgusting for Safari standards).

In that situation I don't care about interoperability, because there isn't (yet) anything worth it. iPhone owns.

BTW: In case of "How do users find their apps?" word-of-mouth isn't different than App Store option on iPhone.

When one says "It's great app called [yadayada], get it!" natural reaction is to enter that name into App Store search box, not Google.

5 Posted by Rimantas on 24 November 2009 | Permalink

@Dirk de Kok: you have no idea what you are talking about. iPhone has the best mobile SDK at the moment (which ppk fails to mention again).

6 Posted by Faruk Ateş on 24 November 2009 | Permalink

I've written up a response again, this time more directly to bits and pieces from your follow-up. Mostly, I'm just adding notes and clarifications:

http://farukat.es/p348

7 Posted by unscriptable on 24 November 2009 | Permalink

It's not hard at all to create a "statically" positioned menu bar at the top of the screen or a tab bar at the bottom -- at least not on the iPhone. Using something like the following works fine:

HTML, BODY { height: 100% };
.myMenuBar: { position: absolute; top: 0; left: 0; width: 100%; height: 2em }
.myTabBar { position: absolute; bottom: 0; left: 0; width: 100%; height: 1em }
.myMainContent { position: absolute; top: 2em; bottom: 1em; left: 0; width: 100% }

The real problem is one-finger scrolling and scroll bars. On the iPhone, AFAIK, the only object that uses one-finger scrolling is the viewport. The myMainContent element above would require two-finger scrolling -- and users don't typically know about two-finger scrolling!

As I write this, I am double-checking an app a colleague created on my iPhone. Yep, this technique works great. Just no one-finger scrolling!!!

So, imho, the real problem is scrolling, not position:fixed. But why not allow position:fixed anyways, Apple?

8 Posted by unscriptable on 24 November 2009 | Permalink

@ppk: on your other points...

I'm mostly glad this is turning into a talk about web standards and not a talk about whether app stores should be closed. I think the more we concentrate on open standards, the less we even need to fight over the other arguments.

-- John

9 Posted by Martin Pilkington on 24 November 2009 | Permalink

The issue is you still seem to think that one should win out of the web and native. The reality is that both have advantages that can both be used. The web provides an ease of deployment and connectivity whereas native provides the UX and raw speed. I wrote a rebuttal to your previous post yesterday where I cover all of this: http://bit.ly/7VwMIh . But in a nutshell the argument over which is better is pointless. The web will never win, neither will native. Each has a major strength in the area the other has a fundamental weakness. So why not use the best of both?

10 Posted by ppk on 24 November 2009 | Permalink

@Faruk: Actually I disagree about your payment point. It's true that devs will have to deal with every operator separately, but that's no different from the App Store. If they want to be present on several platforms they have to deal with several payment systems.

So there's no difference between Web and native apps here.

11 Posted by Mike on 24 November 2009 | Permalink

@Jon Henning: I agree with you that getting attention is an issue. Even if a website is popular, such as GMail, users may not know they can add it to their home screen as a web application.

Here is a proof of concept http://www.mikehemesath.com/installer/ for the iPhone to detect 'browser mode' and notify users they can save the web application to their home screen. I think ideally mobile Safari would provide similar native functionality if it detects <meta name="apple-mobile-web-app-capable" content="yes"> and alert the user they can have a better experience if they save the application to their home screen. This would inform users that applications don't come only from the app store. In the long run hopefully this would encourage developers to make more web applications for the iPhone than native applications.

12 Posted by mlofthouse on 24 November 2009 | Permalink

"When you set a click event handler on anything, it flashes when the user touches it."

ppk,

You can get around this behavior by setting the css property -webkit-tap-highlight-color. It accepts rgba colors so setting the alpha channel to 0 will get rid of the onclick color highlighting:

-webkit-tap-highlight-color: rgba(255,0,0,0) ;

If a user clicks and holds a clickable element it will pop up a callout about the link. You can get rid of this in your mobile web apps by setting the following css property -webkit-touch-callout:

-webkit-touch-callout: none;

13 Posted by Kyle Simpson on 24 November 2009 | Permalink

I still have to disagree with you, @ppk, on the same point as I did with yesterday's article, but with a different focus.

Suggesting that a developer has to choose between interoperability and the UX of native apps completely disregards PhoneGap and Titanium applications.

Those frameworks allow a developer to use web technologies like JavaScript, HTML, and CSS, to build an application that will be compiled to the near equivalent of a base native application.

And essentially the same (web-tech) code base (minus iphone specific api calls, probably) can be targetted to a number of other mobile platforms (yay, interoperability!), including Android, WinMobile, Blackberry, etc.

Theoretically, these technologies should give us the best of both worlds -- native app UX *and* interoperability. Sure, in practice they're not exactly identical or perfect, but they're getting there.

But as I said before, they both still suffer the same fate as regular apps -- they are hindered by the suckiness of the App Store process.

14 Posted by Neil Mix on 24 November 2009 | Permalink

Paul, kudos to you for backing down appropriately while still standing tall for what you believe.

WRT discoverability: there are 2 factors that make the App Store better. 1) The App Store has various "top" lists, and lesser known apps make it onto those lists on a regular basis. 2) The searching experience is much better because the search results only contain apps. Searching for web apps on the web has huge signal-to-noise ratio.

WRT offline: try putting an iPhone in airplane mode and running web-apps in Safari.

15 Posted by Isofarro on 24 November 2009 | Permalink

Firstly, thanks PPK for starting this conversation. It's an important and interesting conversation.

It puzzles me too seeing mobile developers writing for a proprietary and essentially closed single phone system. The only thing that made sense is that they don't see the iPhone as a mobile system, but as something unique in it's own right.

It ain't mobile, I guess.

On the question of how to get paid for a webapp - the answer is the same as the question of: How will you get paid for your application when Apple no longer considers you worthy of being listed in the App Store?

The current situation of iPhone development is in the same position as when the Netscape browser first launched, and that created a flood of Netscape-specific sites. That was a long-term mistake back then, and I have no doubt it's the same mistake here.

I'm grudgingly being educated about the benefits of the mobile web. I'm not totally convinced, but more convinced than a closed iphone application platform.

Mike

16 Posted by Sixbit on 24 November 2009 | Permalink

@unscriptable. You can have one finger scrolling on subsections of the viewport and disable the default viewport behavior. I came up with the technique from reading @ppk treatment of event bubbling and capturing. Basically setting a default handler on document, you can do a preventDefault on the event and reroute it appropriately to the elements of your choosing.

As a side effect of this you can fix a bottom menu bar and not worry about scrolling of the whole viewport. So a robust solution for a menu bar without position:fixed is possible.

Also used @mlofthouse approach to avoid flashing.

So in my eyes the UX issues listed in this article are solvable.

17 Posted by Martin on 24 November 2009 | Permalink

There are 2 reasons why my App isn't WebBased. 1) HTML+CSS 2) JavaScript.

Seriously, I find this way of writing applications with this technology such messy way to develop and maintain.

Okay, so there's loads of Web development going on and libraries I could apply to make it easier. But why, after all this time can we not come up with a better, easier and consistent way to write 'web' applications other than having to embed one language into another markup language?

I believe it is partly because the iPhone provides Objective C/Cocoa Touch API that got the developers excited in developing for the iPhone. Especially since their earlier Web App solution certainly did not take off.

There are developers who think your current view of developing Apps is that unappetising. Come up with a cleaner, simpler (interoperable) technology solution than the HTML+CSS+Javascript way you propose and I'll be the first to try it out.

18 Posted by Jeremy on 24 November 2009 | Permalink

So yesterday I said I lost a lot of respect for you from your post. But I have to admit that it's very impressive to see someone admit they are wrong, under any circumstances, and even more so if they admit it (and then go to great lengths to explain it!) on the web in front of thousands of readers. Kudos (all that respect is back, plus some) :-)

19 Posted by Faruk Ateş on 24 November 2009 | Permalink

@ppk {

It IS different from the AppStore, in that if you only want to deal with an app on the AppStore, you only deal with Apple for payments (even across the countries). If you only want to do Web apps in that hypothetical "WebAppStore", you would _still_ have to deal with each individual operator.

Unless, as I mention in my article, the WAS would take care of the payment system, rather than the operators.

}

P.S. your "Remember me" isn't working for me.

20 Posted by mk on 24 November 2009 | Permalink

I still don't agree that the answer to the question "Why is the AppStore broken?" is "Just move to WebApps." As developers, we shouldn't run away from problems, especially not philosophical ones such as this.

To me (as a developer for mobile, desktop and web platforms), the one thing that always gets me upset is having the technical ability to achieve a goal, but being limited by artificial means. As a developer, just because I *can* do something, exactly means that I should (and will), because that is what drives innovation.

21 Posted by Frank Schmitt on 25 November 2009 | Permalink

Regarding discoverability:

The app store has followed the same trajectory as the web. In 1996, any old site that didn't completely suck could generate a good deal of traffic, because there wasn't really anywhere else to go. These days your web site needs to be either remarkable or well advertised to get visitors.

In late summer 2008 I wrote a free nibware app that stayed in the top 100 for a few weeks just because there weren't that many apps out there. Now with 100k+ apps in the store, you likewise need something remarkable or well advertised to get noticed. In short, the app store's contribution to discoverability is small and shrinking.

22 Posted by Andrew Hedges on 25 November 2009 | Permalink

@ppk, you say "All other players, however, the ones that are threatened by Apple’s and Google’s rapid ascent, go for Web standards big time. Is that a good or a bad sign? I just don’t know yet, that’s why I’d have preferred to discuss this point later on."

I find the situation pretty ironic since it was Apple's focus on web standards (via WebKit) that has fueled their rise against the evil, proprietary, monolithic Microsoft. To answer the question, yes, I think it's definitely a good thing. When market forces dictate, Apple, et al. will be forced to open up to standards such as W3C widgets.

@Sixbit, any chance you could post (or send me) a link to some sample code for that? I'd love to see it! And, if you haven't already, consider blogging the solution. Thanks!

23 Posted by Mark Ferree on 25 November 2009 | Permalink

I am a web developer turned iPhone developer, and I can definitely understand where you're coming from.

I've forcefully argued several times with clients and coworkers that the app I was working on would be cheaper and easier to make as a mobile site, nevermind usable by way more people, and every time the response was basically 'yeah ,but apps are cool right now, and we want to hang out with the cool kids'

Don't underestimate the cool factor in driving peoples decisions.

24 Posted by unscriptable on 25 November 2009 | Permalink

@Sixbit: yes, please post some code! :)

25 Posted by Benjamin on 25 November 2009 | Permalink

Grinding through writing a web-app when I wanted to write a native app, the animation is way from being "there" yet!
Report of how I'm doing up at http://blog.benjaminhill.info/archives/108

26 Posted by mTopSite on 25 November 2009 | Permalink

I think the issue is now and always has been that the features of the iPhone App Store that made it successful where others App Stores are failing also hold it back. Things like Apple doing quality checks prevented poor looking, broken apps; Now it prevents quick iteration. Preventing competing App Stores made it easy for users to find the particular App they wanted, but it puts too much control into Apple's hands. Etc.

27 Posted by Mario on 25 November 2009 | Permalink

You are just worrying too much. Relax, remember the main reason why you started this page...
And now, Google, the biggest player on the Internet just announced a Web based OS... The present and future ARE WEB APPS ! Period!

28 Posted by Jonathan Stark on 25 November 2009 | Permalink

@NeilMix FYI - A web app *can* run completely offline (i.e. in airplane mode), but it has to be set up that way by the developer; it doesn't just automatically work for every site. Details here if you are interested:

http://building-iphone-apps.labs.oreilly.com/ch06.html

29 Posted by Cycomachead on 25 November 2009 | Permalink

Nice Article. Let me just add in how nice I think it would be for Safari to support position: fixed for web pages! I know the screen is small, but I think it would be much more beneficial overall for the iPhone (especially FULL Facebook)

Aside from that tangent, I personally still prefer native apps. As a developer it was easier for me to learn Cocoa than go back and do more scripting (I learned HTML and CSS, and a bit of JS before…) Maybe, I just hate the web. :/ But, I love XCode.

30 Posted by CG tutorial on 25 November 2009 | Permalink

Hopefully those enhancements will be back ported to the desktop where it is desperately needed in anything besides Windows...

31 Posted by Tim Maly on 25 November 2009 | Permalink

Re the notion of carrier-based stores: No! No, no, no, no, no.

In the mobile gaming space (the only mobile app space to speak of for awhile) we've done carrier walled garden stores already. It's TERRIBLE.

Think Apple's process is insane? It is nothing compared to the hoops we had to discover when submitting a game, multiplied by the number of carriers. Outright censorship of content from some.

There was no room for the independent developer, especially not the one person shop in the carrier store. A publisher was necessary to get them to look at your game, let alone approve it. They treated the deck as if it was limited shelf space. You were literally competing for slots with other apps.

In the carrier stores, there could be no Tweetie, Birdfeed, Twitterrific etc. It would have been "we already have a Twitter client".

Compared to that regimen, the App store for all its problems (and there are problems) is a heavenly dream.

32 Posted by Gareth on 25 November 2009 | Permalink

If developing amazing web apps that are as good as Cocoa Touch apps is easy, then why doesn't this website - and especially the comments - display correctly in Mobile Safari?

Long comments are cut off.

Web apps are great for some things, totally agree. But the iPhone SDK is the best mobile SDK in the world. It does so much.

You're right in saying that the iPhone web APIs will get better, but so will the Cocoa Touch APIs. And they will always be more powerful.

The beauty is you can do both. But, I cannot think of a single app I have that would work equally as well as a web app.

33 Posted by Brent Royal-Gordon on 25 November 2009 | Permalink

The thing to realize about the iPhone is that the only real separation between them and their competitors *is* user experience. So yes, native apps are a rational decision—most iPhone users care more about UX than interoperability, especially theoretical interoperability (since web browsers are such a mess on phones right now), and there are enough iPhone users to make it worth catering to their preference for good UX.

I grew up working on the Web and then moved to the iPhone during the SDK's original beta period. I really moved for they payment system, though. Putting food on the table (or, since I'm a student, drinks in my mouth) is not an evil thing—and in fact it's a good thing. I found it much more difficult to finish a project when, even after I'd done the work, I still had to do more work to make it make money. With the iPhone you just build it and put a price on it.

But even though I'm now writing for the iPhone, I'm still using web technologies. Most of my server communications are XML or JSON over HTTP; I usually even use Rails! It's just that last layer that isn't standard—and my customers like it that way.

34 Posted by Tim Down on 25 November 2009 | Permalink

A friend and I wrote and released a SameGame clone for the iPhone called iDrops in summer 2008 that used JavaScript/HTML/CSS in a web browser for the playing area, embedded as a view in a regular Cocoa Touch application. We later rewrote the game as a fully native app, though this version was never released. Some points arising from this:

- Using JavaScript allowed us to develop quickly since we had previously written the game in JavaScript

- We were able to provide a working demo of the iPhone app on the home page of the game's website

- CSS transitions at the time were nowhere near fast enough to do some animation we wanted to do

- It was not possible to play sounds in the JavaScript version

- The JavaScript version seemed to use more phone resources, judging by heat generated and battery life

- The native version was noticeably quicker and more responsive

- Debugging was much less convenient in the JavaScript version

Both approaches had advantages: once we'd learned a bit about Objective-C and the iPhone SDK the application we produced was superior in every way, but without the JavaScript version we would never have been able to release the game in time for the App Store launch.

35 Posted by Belen on 25 November 2009 | Permalink

Regarding the UX issue, I ran a very humble experiment a few months ago. I took a J2ME Twitter client and replicated it as closely as possible as a web app.

Then I ran a comparative usability test with 8 users and a Nokia E66. Test participants completed more tasks with the web than with the Java application; and although they did so slower, they also did it making less mistakes on their way, and with a higher rate of subjective satisfaction.

A J2ME app is not a native app, but I still think the results of this little experiment should make us think twice before boldly stating that native apps provide a better user experience than web apps. That might not be true (it will depend on the users and the app). Before deciding on a platform (native or web), app developers should give careful consideration to the UX issue, and maybe do some testing with users.

Keep spurring discussion: it's sorely needed.

Belen

36 Posted by Daniele on 25 November 2009 | Permalink

To be perfectly honest, the UX argument is moot, the native APIs and Safari's rendering engine are both developed by Apple, there is no reason why one should be seamless and the other clunky.

37 Posted by Daniele on 25 November 2009 | Permalink

Also: getting people to pay for the app, not that hard either, I mean if THESE guys (http://www.youtube.com/watch?v=nR3Ny0tgHfc) can do it why shouldn't everyone else?

Maybe if it's more than 1 euro/whatever is the limit in non euro countries it might become an issue, but in that case what Vodafone and everyone else should do is giving us a paypal-ish system. Not a closed store.

Btw, if Apple keeps giving more love to the Cocoa api than it does to the web api it deserves to lose customes.

Which they eventually will once the Kool-aid will lose some of its freshness.

38 Posted by Dave Addey on 25 November 2009 | Permalink

I'm the friend mentioned by @TimDown, and I've written up the issues we had when creating our hybrid iPhone app:

http://tmik.co.uk/?p=199

The app acted as a wrapper to our existing browser-friendly code, and enabled us to release it on the store. We managed to keep a core codebase of HTML / JS / CSS that worked in the app and also in Safari, IE, Opera etc., which meant we could post a working online demo of the game.

The link above talks about our use of HTML 5 database storage within the app (it worked), animation in UIWebKit (it didn't work very well), debugging the embedded code (it was okay), and passing events to and from the native app to the JS code (a bit hacky).

39 Posted by naderk on 25 November 2009 | Permalink

pp, i haven't read all the comments but, concerning payments, you shouldn't forget the **very numerous** ipod-touch users who are great appstore clients and who, with your solution, could never purchase via a phone operator.
the emphasis should be on *mobile devices* NOT *smart phones* — bookreaders, ipods, itablettes, whatnot all come without phone connections.

40 Posted by John.B on 25 November 2009 | Permalink

The fact is that most people won't pay for a web app that they assume should be free.

http://www.olswang.com/j_convergence09/content/default.asp?id=106 (via Apple Insider).

It's the iPhone/Touch users who are most willing to part with their money for *applications*. Even when there exists a corollary website with similar content. So it's no surprise that's where the developers go...

41 Posted by Andrew Embler on 25 November 2009 | Permalink

Assuming developers are stupid because they choose the app store over web applications, and then neglecting to mention the problems of PAYING for web applications, is like assuming farmers are stupid for planting their crops outdoors, when that's where, you know, it rains. The ease of purchasing these things is one of the fundamental pieces of the puzzle.

42 Posted by Brian Pan on 25 November 2009 | Permalink

Just because something is technically feasible both natively and via a web app doesn't make them equal. Yes, offline web apps are possible, but is implementing and testing them just as easy?

Same goes for UX. Even if a workaround or something is developed to overcome "position: fixed" or other problems, that doesn't put a web app on par with native apps because the web developer still needs to understand a potentially more complicated solution.

43 Posted by jrock on 25 November 2009 | Permalink

ppw - at least have the balls to stand behind your rant.

the iphone user community is fickle and the superior end user experience is delivered by using native development tools not browser hacks. as a "researcher", you should provide some actual proof to your arguments instead of some half-assed op-ed piece. build a moderately complex iphone app with native tools and then build the same app using web dev tools. compare each by showing the code, performance, etc. don't just lob unfounded arguments to an audience which will call you out.

legitimate app store issues do exist, but some of the current headline problems don't hold up to scrutiny. unauthorized use of private api's and trademarks are clearly forbidden in the terms of usage.

sure, i would like to see a more streamlined approval process coupled with the ability to update existing apps quicker. but the fact is that the iphone sells because of the quality of its apps and it is in apple's best interests to ensure the quality of those apps.

44 Posted by Luke Hartman on 25 November 2009 | Permalink

I'm viewing this on an iPhone and all the comments are truncated with no discernable way to expand them. Seemed a little ironic, no?

45 Posted by Jon Henning on 25 November 2009 | Permalink

What I find quite ironic is all the iPhone users posting comments complaining about them being truncated on their iPhone. Its ironic because this "problem" is also the SAME issue as the fixed header. Apple decided that scrollable elements within a web page would be scrolled with 2 fingers?!?! It was a running joke in our dev shop for a couple days as to why such a bizarre gesture that no iPhone user in the office knew about would be chosen. This same problem is why creating fixed header/footer web apps is harder than it should be. You can easily do it if your users are expected to use 2 fingers for a scrollable div, but who would ever want that experience? I understand that browsing framesets on a page that scrolls needs something other than a normal flick, but Apple should have provided a way to disable the need for 2 finger scroll.

For those intersted in a real web app on the App store that demonstrates a reasonable level of complexity (fixed header, animations, offline cache, etc.) see my earlier post.

Reference to 2 finger scroll on Apple
http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#//apple_ref/doc/uid/TP40006511-SW8

46 Posted by Jon on 25 November 2009 | Permalink

I'm not sure how Apple could handle this otherwise. The entire iPhone interface is structured around moving/scrolling with one finger. If the scrollable textarea were a large (or the entire) portion of the screen, how could you move if a single-finger scrolled a text area? (The bigger question to me is why scrollable text fields are used for anything beyond form entry in the first place.)

While Mobile Safari does support the two-fingered scroll, the fact that they are scrollable is not visually evident within the browser.

47 Posted by Roy Tomeij on 26 November 2009 | Permalink

"But they might become stupid later on, when the Web has become a totally viable alternative, but they refuse to consider it."

Yeah, and people with an umbrella might become stupid later on, if it's raining and they don't open their umbrella.

Why would you want to speculate on what anyone might or might not do in the future, so they might or might not become stupid?

48 Posted by V on 26 November 2009 | Permalink

I liked the previous post better!

49 Posted by Kendall Helmstetter Gelner on 26 November 2009 | Permalink

Three points of why web apps cannot replace native:

1) Test Everywhere. This comment section not working on the iPhone illustrates a problem - you are not really writing for every platform, just the two to three you take time to test.

2) No distinction between Eye candy and Mind Candy. Sometimes that which seems superfluous is making an application easier to understand, more discoverable.

3) Platform innovation. The web as a platform rarely innovates, but distills innovation from native platforms. That means web apps are eternally behind native apps. That doesn't mean web apps make no sense, just that you can improve on a web app with a well-crafted native version. Berkshire Hathaway looks for companies that have a "moat", keeping companies from easily competing. Using web technologies is like moving out of the castle to a house nearby and saying "go ahead and write a really superior version of our app". The same argument applies to solutions like "Phone Gap" (optimized for native but not fully supporting any one SDK).

You look at an app and say "that could be a web app". I look at the same app and say "that could be so much better if it took full advantage of the platform it is on" -iPhone or any other platform.

50 Posted by Jason on 2 December 2009 | Permalink

I've worked as a web developer for a number of years as well as a 'real developer' or whatever. Frankly no matter what you say I'll always view web development as greasy kid's stuff. There's no comparing a web application with the application framework it runs on or the OS that powers it all. Unless I misunderstood your article and you are only arguing native mobile app vs. web based mobile app, I'll never view a web developer as a 'real' developer unless they have had experience developing real systems. Or to be fair and say well rounded.

51 Posted by Hugh Isaacs II on 16 December 2009 | Permalink

Actually on the UX end of developing a web app.

Apples WebKit engine supports native theming via CSS using -webkit-appearance.

I'm not sure how flexible it is (as I've never used it), but it certainly is there.

One interesting thing though is that Apple and Google are increasingly updating their mobile browsers to support HTML5 specs.

The W3C has a HTML5 capture API for microphones and cameras in the works, and several people have written up drafts for file system access, along with WebGL being on it's way I'm sure these things will make their way into the iPhone and Android devices once they reach final drafts.

52 Posted by Michael Bolin on 16 December 2009 | Permalink

In response to "Getting Attention," when we announced the web version of Tasks for iPhone, we decided we had to include a video to demonstrate how to bookmark it to the home screen: http://bit.ly/EgkQ I think that when a user hears there is an app available for the iPhone, the first inclination is to go to the store. That's just how it's done.

This situation could be helped if Apple had something like the RSS icon in Firefox. That is, when visiting a page where the tag (or some new meta tag) is present, a UI control could appear to indicate that the web site is actually a webapp that is meant to work offline and be bookmarked on the home screen. Or if it were possible for webapps to appear in app store search results, that would be even better. (That could also help with the payment issue.)

Although Android is focuses on writing apps in Java rather than using web standards, I think Google is indirectly doing its part by pushing ChromeOS. I believe any effort to help make the browser "the" platform will result in better webapp support on mobile in the long run.

Also, I'm surprised how little you mention PhoneGap as they seem to demonstrate the best understanding (and solution to) the problem.