It wasn't immediately clear to me how this actually works. After looking into it, I found what you'll probably be interested in:
...building a native app with Objective-C is a risky proposition.
Fortunately, there is an alternative. You can build a web app using open source, standards based web technologies (jQuery and jQTouch, in particular), release it as a web app, and debug and test it under load with real users. Once you are ready to rock, you can use PhoneGap to convert your web app to a native iPhone app and submit to the App Store. If it is ultimately rejected, you aren’t dead in your tracks because you can still offer the web app. If it is approved, great! You can then start adding features that enhance your web app by taking advantage of the unique hardware features available on the device...
The conversion is done by wrapping your web app inside a native app using WebKit.
This is very misleading. It should really be called 'Building web applications with limited access to the iPhone APIs that somewhat look like native iPhone applications' :-)
There are a bunch of frameworks that take the html/css/javascript approach. You can do a lot this way but what nobody really seems to get is that your app will run in a WebView that is basically sandboxed with very limited access to iPhone APIs.
The APIs that you are allowed to use are those that Apple hyped when they came out with the iPhone OS 1.0. Basic Javascript hooks to access the address book, accelerometer, maps, camera, etc.
There is no way to access more native functionality.
I was at a conference last month (FITC Mobile) where this approach was also demonstrated. The speaker put together a simple app to take a picture with the camera and then upload it to Twitter. It looked like sh*t (because it is a web app and not a native iPhone app) and it was also not able to things that required native API access like scaling the image down. (Two lines of code in ObjC)
WebKit can easily scale an image down using the canvas element. Native UI can also be replicated pretty much perfectly in WebKit (e.g. you might be surprised to learn that iTunes and the app store are displayed with WebKit). Sounds like the speaker just didn't do a very good job.
The only things that aren't suitable for WebKit are things that require heavy CPU usage or access to iPhone features that Apple hasn't made available to WebKit yet, like OpenGL (incidentally, WebGL has recently landed in WebKit, so OpenGL access will no longer be a problem).
Scaling, converting to a PNG, and uploading the resulting image is trivial in WebKit. As for accessing the camera hardware to take a picture, that requires an API from Apple, which I thought you implied existed. :)
I've gone through testing with a handful of these JS to Obj-C conversion systems and haven't found one that does a really good job of emulating a native app. Appcelerator seems to be the best option out there, but you write very Appcelerator specific JS to make things work.
While quite straightforward to work with, my main gripe with PhoneGap and QuickConnect (a similar system to PhoneGap) are:
1) the inability to have a native footer
(a fixed header is possible, just not the footer)
2) no keyboard views other than the standard (eg: no number pad)
Appcelerator gets you access to both of these things because it's actually re-writing your code as native (at least that's my understanding).
Basically, for side-project or pretty simple apps, PhoneGap seems like a godsend. But for a commercial app that needs a certain polish and a truly native feel, not sure they cut it. My 2.5¢.
Also, I did a quick write up on this back in June: http://DesignLitm.us/u/14 If things have changed since then, please ignore this entire response!
Using Webkit severely limits you and makes your app look pretty crappy. Objective-C really isn't that hard, nor is getting up to speed with the SDK. This is a common situation in programming, where a framework is developed that appeals to people's desire not to bother learning yet another language, and yet another set of APIs. But it is almost always a mistake. It requires a little more effort, but in the end, learning how to use the right tools is the only way to make something really good.
I just wish Apple would just post some real guidelines about what think about this general tactic. In the absence of that, I'd love to hear some stories from developers who've done this and gotten their apps approved/ rejected.
Regarding PhoneGap specifically, which the book seems geared toward, for a short period of time Apple believed, erroneously, that the iPhone PhoneGap code was exposing unapproved APIs to developers, and were rejecting apps that used the platform. At that time, I think some devs were obfuscating PhoneGap and submitting the same apps, which were approved, so even then Apple were not objecting to anything actually in the iPhone PhoneGap code.
Since then Apple have had a much more informed stance towards PhoneGap and have approved lots of apps using the framework (there's a list on the PhoneGap site).
*full disclosure - I work for Nitobi, who sponsor PhoneGap's development. Though the original link suggests using PhoneGap in its preface, there are competing platforms, such as Rhodes and Appcelerator, that also get through to the App Store.
I'm friends with Andre at Nitobi, and he assured me that things are cool and apps are getting approved. I was still hoping that there was some kind of Apple statement about this. The blog post was very reassuring, thanks!
The book is about developing Web Apps (tailored/optimized for the iPhone) and so no approval process is required.
Edit:
Please see my reply to the comment below.
Also, this is from the preface of the book:
Fortunately, there is an alternative. You can build a web app using open source, standards based web technologies (jQuery and jQTouch, in particular), release it as a web app, and debug and test it under load with real users. Once you are ready to rock, you can use PhoneGap to convert your web app to a native iPhone app and submit to the App Store. If it is ultimately rejected, you aren’t dead in your tracks because you can still offer the web app. If it is approved, great! You can then start adding features that enhance your web app by taking advantage of the unique hardware features available on the device. Sounds like the best of both worlds, right?
So, the step to wrap your app with something like PhoneGap is only needed if you want to sell your app on the AppStore. You can try to submit and then, if it is approved, you may add more hardware dependant features (which aren't covered at all by this book).
Edit: where in the book did you see how to use geolocation, vibration or any other feature which is not available with a web app developed for mobilesafari?
That may be so, but apple will never let you ship an app they haven't approved. They have very specific language forbidding VM's and interpreted languages. So you may be able to dodge Objective C (like the Mono/Unity folks have) but you're not getting out of Apple's approval process.
...building a native app with Objective-C is a risky proposition.
Fortunately, there is an alternative. You can build a web app using open source, standards based web technologies (jQuery and jQTouch, in particular), release it as a web app, and debug and test it under load with real users. Once you are ready to rock, you can use PhoneGap to convert your web app to a native iPhone app and submit to the App Store. If it is ultimately rejected, you aren’t dead in your tracks because you can still offer the web app. If it is approved, great! You can then start adding features that enhance your web app by taking advantage of the unique hardware features available on the device...
The conversion is done by wrapping your web app inside a native app using WebKit.