Hacker News Reader

Comment by stillmotion | Hacker News Reader

I don't think this guy understands how simply amazing Cocoa is. Yes, maybe a designer couldn't learn Objective-C, but my goodness is it a beautifully designed framework.

Everything he lists is simple and stupid when you understand how to build iPhone applications.

"want slightly different buttons in a snap? Just photoshop it and you’re off"

HTML and CSS? It's pretty easy to develop a beautiful UI in Photoshop and simple slice it up for Cocoa. When going back into CSS development, I'm frustrated because of the need to move things around by a whole bunch of divs and styling all that type.

He then continues on about server side administration? Hell no. Personally, I'm glad I can just make an app, deploy it, and not have to worry about the e-commerce, server maintenance, and running costs.

If making iPhone applications were like this, I'd die.

View on HN

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?

Reply on news.ycombinator.com