The obvious flaw in his piece is that he only looked at free iPhone applications and from that subset concluded that almost everything the native apps do could be done with web applications (he explicitly ignored Apple’s Remote app; implicitly he must have also ignored Evernote, Pandora, PhoneSaber, Midomi, NetNewsWire–in that it works off-line, Graffitio–which interfaces with the GPS hardware, etc.).

If you’ve spent some time with some of the amazing free and for-pay iPhone apps as I have, just ignore the bit about those apps not being impressive compared to iPhone web apps and skip to the core of his piece where he makes an interesting assertion: the math of trying to profit from selling small apps in the iPhone store doesn’t make sense when compared with (a) the costs of learning the devtools, (b) porting to different phone architectures (vs. one web app code base), and (c) the revenue stream from 37signals-style subscriptions.

Let’s say you sell your App for $1.95. You’ll need to sell 25,000 copies to make $50KUSD. Hang on, Apple takes about 30% so you’ll need to sell 30% more. That’s 36,500 copies. If you look at a typical conversion rate of say 3% of downloads to sales (in my experience, good Mac apps can get that kind of conversion), if this were a desktop shareware app, you’d need to have 1.2 million downloads. That’s more than 10% of the entire projected iPhone user base for the end of 2008 interested in your app.

OK, let’s think about higher price points – at $5, you need to sell 14,000 copies to make $50KUSD, with a theoretical download of 476,000 demo copies. Up this to $10, and we are looking at 7,000 sales, and 233,000 demo downloads. And that’s for a single developer. Double this for 2 developers, triple it for a team of three, and so on.

Now, let’s compare the â€œsell the appâ€ business model with the increasingly common â€œsubscribing to a serviceâ€ model. Let’s say we only have customers paying $5 a month. They are already paying $60 a year! So to make our $50KUSD, we’ll need around 1000 customers (about 14% of the number of sales of a $10 app). And I’ve factored in about 12% costs here (transaction and hosting costs, based on personal experience).

I think the idea of saying one is “better” than another is just, well, stupid. They both have their streangths. In the case of one of our apps (Heap CRM) we have both a iPhone optimized version that is full featured and an iPhone native version that is very focused and works offline. So basicly, if you need the power you can use the web app, but if you just need the data that you need 70% of the time it may be faster to use the native app.

Not to act like I have all of the answers, but I do think this is a good approch for a lot of people. The UIKit elements lend themselves to creating very simple interfaces, while on the web, the sky is the limit.

I must admit I was having similar thoughts. For example Hahlo is significantly better in many ways than twitterific and twittelator. I even prefer the web version of Facebook’s app. Where I think the installed apps are better (Loopt is a good example) is where there is very tight integration + expanded functionality with elements like the camera and location based services which do not seem accessible from the SDK of the web app API. (from what I’ve seen anyway). Google Reader for example did an amazing job in their latest re-design of web apps.

Offline ability is also key, which is why gaming is HUGE offline and thus much better for installed version. I mean the caching behavior of the web browser is so annoying that gaming is almost impossible w/o driving yourself mad.

The types of apps that seem to do better on web app side are where they are very data intensive and they ignore or have no use for camera or location awareness and don’t do offline modes.

To me installed apps follow the same rules as plug-ins and add-ons in the desktop world. If I gotta access something the sandbox of the browser doesn’t allow then it is much better to have an installed component: camera, LBS, contacts, email, calendar, video settings, change the SIP/Keyboard, etc. And most of all have an offline experience that is reliable and permanent.

I don’t understand why a subscription model would be incompatible with native apps. Use subscriptions to enable additional functionality that must be used online to benefit from it. There’s a reason apple is charging money for mobileme.

Add to those arguments the flexibility of web apps being able to move between platform and live independently of the success of the iPhone.

For example – when the Android-phones are going for sale a web app can easily be adjusted for those platforms while a native app will need to be ported from the iPhones Objective-C-based(?) code into the Androids Java-based.

So the question that should be asked is: Do you need to go native – do you have any benefits from it? If not – don’t do it…

I’m not sure you quite characterised my argument about native apps right. I explicitly did say that in order to tap into certain aspects of the hardware, then native apps are a must – but my point was it doesn’t have to be that way – Apple could give a Javascript API for the accelerometer, the GPS, the camera and so on. Afterall, there’s a JavaScript API for the Wiimote.

The other aspect a lot of folks focus on quite a bit is being offline. In a very short time this will be close to irrelevant – we’ll be always on everywhere easily within the lifetime of the iPhone platform, but how about right now? Again, Apple could easily provide client side storage for webapps (webkit nighties, and other browsers already have support for this), and client side caching of webapps for offline application use. This would have the benefit of addressing some of the performance issues folks are also focussing on.

I think you have to look at the usecase your trying to code for, and your target audience and decide. The argument is a little different than rich web/vs client server because the cooca api and the iphone env is much more a restricted environment. You don’t run into the deployment issues you worry about with client server for instance.

Not taking simple webclipping apps into account which guarentee rejection in the app store, Online apps are probably better if you just pulling data from a server and doing normal crud type stuff. They also are have more security options.

If you need any phone features you have to go native. The native controllers are a bit more robust two, also if your app can connect to multiple sites or opens multiple sessions and maybe pushes data from one session to another. http://www.mooncatventures.com/blogs then native makes sense.

It would be cool if apple just created a simple xcode template that you could easily wrap web apps around, something more advanced than just using a uiwebview or uiwebviewDelegate (phonegap, qcconnect). but unless you add a lot of phone side functionality your almost guarantted rejection.