IPhone apps: Webapps or native?

If you want to have an app on the iTunes App Store you must write the app in Objective-C. Here is a quote from the iPhone OS 4.0 developer agreement as pulled from Daring Fireball I have highlighted the most relevant section 3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.

G Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited) This of course does not apply to OS 3.1 or 3.2 and it is currently unknown if once OS 4.0 comes out Apple will retroactively remove any existing applications that have made use of such tools. In theory if you manage to get the app out the door before 4.0 comes out and you get lucky then perhaps you could make use of something like PhoneGap, but it seems like a really big gamble to spend time using those kinds of tools at this point That said, Objective-C really isn't that hard to learn, it's primary syntax is someObject doSomething or someObject doSomethingWith:thisObject I have very little knowledge of web development so I can't speak to it's merits or disadvantages, but it you have everything set in a web app you may want to lean toward either the hybrid option mentioned above or going purely web based.

If you want to have an app on the iTunes App Store you must write the app in Objective-C. Here is a quote from the iPhone OS 4.0 developer agreement as pulled from Daring Fireball. I have highlighted the most relevant section.3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g. , Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited). This of course does not apply to OS 3.1 or 3.2 and it is currently unknown if once OS 4.0 comes out Apple will retroactively remove any existing applications that have made use of such tools.In theory if you manage to get the app out the door before 4.0 comes out and you get lucky then perhaps you could make use of something like PhoneGap, but it seems like a really big gamble to spend time using those kinds of tools at this point. That said, Objective-C really isn't that hard to learn, it's primary syntax is someObject doSomething; or someObject doSomethingWith:thisObject; I have very little knowledge of web development so I can't speak to it's merits or disadvantages, but it you have everything set in a web app you may want to lean toward either the hybrid option mentioned above or going purely web based.

You can have the cake and eat it too. You can easily mix web and native app by using UIWebView instances, e.g. Implement performance-sensitive parts in Cocoa/Objective-C code, and insert WebKit views in parts which would be too time-consuming to rewrite as native. You can even wrap whole web app in native package, if you want App Store distribution — see PhoneGap.

You can also develop pure web app that won't look like it's launched via Safari, if user adds your page to his home screen — see jQTouch. Drawbacks: Web apps may not be as fast as native application, although with HTML5 offline support and WebKit-specific extensions like transitions and animations, you can get pretty far. Make sure you use touch events — Safari delays onclick.

It's hard to make pure web app feel like proper native application. For example mobile WebKit doesn't support position:fixed needed to replicate top navigation bar, and web views have different scrolling speed than table views.It's fixable, but requires ton of JavaScript. Advantages: Rapid development.

I really appreciated how useful CSS/HTML is for complex layouts when I had to replicate apps in UIViews (InterfaceBuilder is OK only for semi-fixed layout). You're insured against Apple suddenly hating and banning yet-another-thing. If they remove your app from AppStore, you can let users access it via web (Google did this with Voice and Latitude apps).

It's easier to port web apps to Android and others (WinMo, HP Pre, latest BlackBerries, etc.) Apple is number #1, but its mind-share isn't proportional to market share. Others are catching up. If you choose native You have to do it Apple's way: Objective-C and Cocoa (you can do parts of application in plain C or C++).

There's plenty of tutorials and books on the subject, so I won't repeat them here. Just some random bits of advice: plists, despite being "native" iPhone format, aren't the best for client-server communication. XML plists have high overhead even by XML standards, and binary plists might be pain to generate and debug.

JSON is actually faster and usually easier to work with. If you fetch only small bits of information, NSConnection only complicates things. You can simply use NSData dataWithContentsOfURL: in method launched via performSelectorInBackground:.

Notifications are not delivered while UITableView is scrolling. If you want lazily-loaded pictures in your table, load and set them using callbacks.

UIWebView, not UIWebKitView, but otherwise good answer. – chpwn May 16 '10 at 1:33 One significant drawback of a pure webapp - you can't sell it in the app store (unless you wrap it in Phonegap or the like). – ceejayoz May 16 '10 at 1:33 @chpwn fixed.

@ceejayoz: Wrapping pure web app in native one is easy, and such apps are sold in App Store. – porneL May 16 '10 at 1:38.

PhoneGap, which Noah mentions, is definitely a route you can take to do the HTML+javascript development and still package it for distribution, as well as taking advantage of a number of the great native features of the iPhone. The rest is all dependent on some elements that you haven't shared. How fast and smooth do you want the response from the UI/Search to be?

That's a place where the latency of a web application, even over 3G, might encourage you to look for an alternative to present it faster locally (using all local, or even Objective-C). The other places, which don't sound like they're in your path, to look for where you might want to do Objective-C directly are heavier graphics and manipulations around animation (although javascript + Canvas and HTML5 are about making me a liar there), using the camera and/or microphone to record multimedia, or something that requires a reasonably large amount of intensive processing. And the last is really a question of where can you and do you want to have that work done?

On the servers (typical Google style choice) or on the device?

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.