Apple banning apps built with PhoneGap
blog.nachbaur.com
blog.nachbaur.com
Although I do understand that Apple has to keep some level of quality in their store (they're not doing a good job imho), clearly they haven't learned anything from their own history ... a platform friendly to hackers wins in the long run.
Linux is friendly on the server side, but on the client side there are many things lacking.
Until recently, Windows development more or less required commercial development tools costing hundreds of dollars; how is that any different?
Even now, the free Microsoft tools are much more limited than their for-pay counterparts and if you use tools outside of the ones Microsoft provides, you risk lack of support, incompatibility and less-than-seamless integration with operating system features.
I disagree in regard to Windows however, although to be clear, what "competing platforms" are you referring to?
On the other hand, they may be more interested in defining "winning" as selling product to an audience that is not opposed to paying a premium price for quality if that means sacrificing some flexibility.
Anyway, I'm not sure what's so "hacker un-friendly" about the current SDK. You can write and use anything you want on your own phone by paying nothing more than the $99 "anti-bozo tax", you just can't count on being able to distribute it via iTunes. If you're serious about being "open and free", you can even distribute your app without restriction in source code form.
...and for "serious" hackers, there's always the jailbreak option. Yes that will void your warranty and such but when has that stopped a good hacker before?
The jailbreak option is not a viable option when jailbreaking requires extra work on the user's part and carries the risk of impeding the upgrading of the phone's operating system.
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.