iPhone apps: Webapps or native?

I am planning to create an iPhone apps version for our online webapps. I am still new to iPhone apps development so I don't know whether to choose i开发者_开发百科Phone native or a webapps that runs on iPhone browser.

The requirement is actually pretty basic. The iPhone apps need to submit data and get data from the database that is also used by the webapps. User would have the same access to the webapps, only I want this specific to iPhone, as the user experience would be different using a webapps and iPhone apps. I am also interested to sell the application on Apple store.

Based on your experience, what would be better for this kind of requirement, iPhone native or webapps? What are the drawbacks building a native iPhone apps and webapps that runs on iPhone browser? Also, am I only limited to Objective-C to build a native iPhone apps? Or is there any other framework for that?

Please be gentle on me, I am not starting a flamewar.

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.

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.

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?