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.
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.
"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.)
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?
* 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.
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.