[lethain]

I think the developers of phone gap are at fault here for suggesting that their platform/toolkit is usable on the iPhone. Whether or not developers agree with the restriction against interpreted code, it has been very clear since long before the public iphone developer kit that it was not allowable to write code in an interpreted language.

The exception to this is websites running javascript when a browser visits them (i.e. client side javascript for a webapp), and that is quite different than packaging javascript into an application and deploying that application to an iPhone.

[mbrubeck]

Here's the actual text from the iPhone SDK Agreement:

"No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple’s Published APIs and built-in interpreter(s)."

It only forbids applications from interpreting code that they download. The JavaScript code for PhoneGap apps is installed on the phone. Also, it has an explicit exception for using built-in, documented interpreters like WebKit/JavaScriptCore. (Otherwise no applications that embedded a WebKit control could legally view any web page that contained script elements.)

[jasongullickson]

I don't know everything about how phonegap works, but I gather that you embed your javascript code in the application (as opposed to downloading it from a webserver) and this code is loaded and run by the phonegap host app code when your app is launched.

Imagine a poorly written application that inadvertently allows it's javascript source to be modified by a third party. This third party then would have the ability to exercise any of the api's exposed by the phonegap host process. Again I'm not intimate with the functions that phonegap exposes, but I can imagine a few parts of the native SDK that you wouldn't want intruders probing on your phone.

This is why Apple doesn't allow all of the SDK's tools to be accessed via javascript running in the browser (Safari) they provide. They do expose some native controls (as can be seen on iphone optimized websites and apps) but there is a limit and I imagine this is one of the reasons.

[pieter]

My guess would be that according to Apple's interpretation, you're allowed to:

* run javascript from remote sites using the existing JS API's (so you can create alternative browsers, like there already are in the App Store) * expose custom objects to the JS world, and use those from local scripts

but you're not allowed to:

* download scripts and allow them access to your native JS objects

but the distinction is a bit hazy. There are also problems with 'interpreted code'. What about native code that is downloaded and executed? How about code being JIT'ed (using LLVM, or even something like C-code that is compiled and then run)?

Personally I think that something like PhoneGap is very useful for the iPhone ecosystem, as it's a bit similar to how the apps on the Palm Pre work. But Apple might be concerned by the lack of any security within the JS world -- you can't allow access to some objects from local scripts, and disallow them from remote code. Apple might be working on creating some kind of access layering within the JS world, and then expose this functionality themselves.

[lethain]

Although I understand the appeal of your argument, using a 3rd party workaround to provide support for performing javascript interpretation outside of the browser--whether or not they happen to be hijacking the system's underlying javascript interpreter--is not an "Apple Published API".

[mbrubeck]

As far as I can tell from the PhoneGap source code, it just embeds a UIWebView and hooks into its standard APIs and events. I didn't spot any unpublished APIs in use. Can you give an example of what you mean by "hijacking"?

If I built a non-PhoneGap application that used a WebView to display pages I built with HTML/CSS/JavaScript, do you think that would violate the SDK agreement?

[jasongullickson]

PhoneGap doesn't appear to expose any of the Private API's however it does expose parts of the SDK that are not normally available to web-based applications when run via Safari. I have a post above that elaborates on why Apple may find this objectionable.