In the short term, open and/or free might not be as attractive, but after you've seen these things come and go, they become more attractive, even if there are some initial deficiencies with regards to proprietary systems.
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.
One of the reasons Windows won was by being open to developers. It was pretty common back in the days for OS vendors to put a price on the SDK. And Linux was just starting.
Linux is friendly on the server side, but on the client side there are many things lacking.
"One of the reasons Windows won was by being open to developers. It was pretty common back in the days for OS vendors to put a price on the SDK"
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.
Windows, and MS-DOS before it, were vastly more open to development than competing platforms. Microsoft and Borland's development tools weren't free, but they were cheap. MSDN subscriptions didn't start becoming a significant revenue source for Microsoft until well after its monopoly status was assured.
That depends on what you mean by "win". If by winning you mean their platform is adopted by hackers and becomes popular with the subculture, then yes I agree with you.
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?
Hackers care about being able to work unfettered. Not being able to distribute your application in a form that anyone with the hardware can use would qualify as fettered.
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.
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.
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.)
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".
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?
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.
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.
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.
As someone who has an iphone app live in the app store created with PhoneGap I call BS on this one.
I think the problem is consistency within the approval process instead of lying the problem at PhoneGap.
If this is merely based on platform, Apple is simply setting a precedent for other frameworks. From a business perspective, they don't want to lose direct control of the development of applications, especially since the Apple app approval ;) process has been shown to have holes as of late.
23 comments
[ 2.6 ms ] story [ 39.2 ms ] threadAlthough 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.