Some iPhone apps should not be written in Cocoa(kudtler.com)
kudtler.com
Some iPhone apps should not be written in Cocoa
http://kudtler.com/2008/12/some-iphone-apps-should-not-be-written-in-cocoa/
14 comments
That's the approach I am looking at. Consider a workout program for one reason for this approach. Many gyms are in basements and places where reception is crummy. The application should be able to run in these places, and offload to the webapp when necessary.
Consider travel applications. An American going to Europe will not want to spend the money to use your web application. (We've already heard about the incredible bills by people who didn't realize what was happening.)
Consider travel applications. An American going to Europe will not want to spend the money to use your web application. (We've already heard about the incredible bills by people who didn't realize what was happening.)
Forgot one thing -- don't forget about the iPod touch market. Webapps are useless for those in many cases.
Also, Titanium, an open source AIR competitor: http://titaniumapp.com/
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.
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.
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.
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?
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?
Apple's been saying that all along. http://developer.apple.com/webapps/ The old "web apps are the SDK" line wasn't greeted with open arms by many, but I think Apple's done much to promote iPhone-tailored web apps as a viable alternative to Cocoa Touch for the very simple reason that there are more web developers than there are Cocoa developers.
They've even tried to make it reasonably transparent to the user, as web applications can reside on the home screen, and when launched, can be set to not display the browser toolbar, making them appear practically indistinguishable.
If you look at the work that's gone into WebKit/Safari, like a tenfold increase in JavaScript performance, HTML5 dbs, and a whole host of CSS work like gradients, canvas backgrounds, masks, reflections, transitions, and implicit animations, it's a more attractive platform than ever.
They've even tried to make it reasonably transparent to the user, as web applications can reside on the home screen, and when launched, can be set to not display the browser toolbar, making them appear practically indistinguishable.
If you look at the work that's gone into WebKit/Safari, like a tenfold increase in JavaScript performance, HTML5 dbs, and a whole host of CSS work like gradients, canvas backgrounds, masks, reflections, transitions, and implicit animations, it's a more attractive platform than ever.
Now if they'd just provide javascript hooks for the location, acceleratometer, sounds, etc. (Yes, I've seen PhoneGap)
Take a look at http://phonegap.com. It will let you develop a web app and also get access to the iPhone’s GPS, accelerometer, etc.
Nice ideas and all, but most developers still benefit from being able to charge on the app store, plus the marketing Apple is doing for you (less and less, but it's still better than a web app no one goes to, and google ignores for 6 months.)
BTW, I'm going to be disappointed if I don't see the $5000/week people keep mentioning once I get up to speed on iPhone programming :-~
BTW, I'm going to be disappointed if I don't see the $5000/week people keep mentioning once I get up to speed on iPhone programming :-~
I would agree with the post if IPhone was on a better network like Verizon, but given that AT&T's network coverage just isn't that great in the US (I'm currently a subscriber), not to mention that we don't have great nationwide wifi yet; I just feel that most IPhone apps still need to written in obj c.
(ironically, this is pointed out in the post)
(ironically, this is pointed out in the post)
You can store the HTML/CSS/JavaScript locally within the app, as well as use the built in SQLite database, which solves this problem. Of course, you lose the ability to update the app whenever you wish.
The reality is that there are lots of native iPhone apps that should be web apps. Right now, the web apps don't quite pay as well.
I believe what we're ultimately seeing is the rise of the native/web hybrid application. These are a class of web-like applications that can run in disconnected mode:
* views use HTML/CSS stored locally on the client
* handling of requests from the views is done within the client itself, or dispatched externally to a web API
* sophisticated data structures can be persisted on the client (in mysql, text files, etc.)
* more sophisticated processing than typically occurs in your standard web app
* better access to native hardware features
The technologies are coming together: Adobe AIR, UIWebView/iPhone SDK, Android's WebView, etc. to support this. I'm looking forward to it.