Altough I agree on one point, that the sliced up photoshop UI also can account for Cocoa. I don't think you read the whole article. The part about server side administration is that it's easy to edit and add functionality to your app in a snap without all resubmitting to the app store and apple hassle. I also point out that not all iPhone applications should be written like this, just for some apps the advantages of this method outweighs the advantages on using Cocoa (first-last sentence in the article).

Or how about we stop trying to develop our own beautiful UIs? One of the main attractions of the platform is that the UI is really good and consistent. The verbiage used between all apps is consistent, informative, and the imagery for icons and whatnot are also equally carried through.

So why are we mucking with it? I see more and more iPhone apps trying to completely overhaul Apple's own UI elements, to appear "unique", when all they're doing is adding to user confusion and inconsistency.

There are legitimate places where the UI must be extended - I say extend, not replace - because Apple's existing toolkit items are simply not up to the task, but IMHO one of the major failings in the iPhone dev community is failure to uphold the basics of UI standards.

The article misses one key point in favor of web-based applications -- you don't need Apple's permission to write one. Writing an iPhone app consists of agreeing to an EULA to get the SDK, then writing the app with proprietary APIs and arbitrary restrictions (you can't call this function; you can't use a language that allows code modification at runtime[1]), and then finally gambling on whether or not Apple will approve it. If they don't like it, all your work is wasted.

If you write a web app, you have none of these problems, and you don't have to share your revenue with Apple.

[1] As anyone knows, this is not technically possible. Are config files or preference settings "code"? Why not? And what about languages that allow putting shellcode on the heap and overwriting the saved instruction pointer with its address... like, say, Objective-C?