Apple banning apps built with PhoneGap(blog.nachbaur.com)
blog.nachbaur.com
Apple banning apps built with PhoneGap
http://blog.nachbaur.com/2009/05/open-letter-to-apple-iphone-developer.html
8 comments
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?
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.
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.
As much as we'd like for that to be true, I don't think it is, otherwise Linux would have "won" a long time ago.
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.
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.
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.
I won't contest you in regard to MSDOS, in many ways the Borland tools were superior to Microsoft's and were fairly affordable as well.
I disagree in regard to Windows however, although to be clear, what "competing platforms" are you referring to?
I disagree in regard to Windows however, although to be clear, what "competing platforms" are you referring to?
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.
How is it BS? Are they not disapproving iPhone apps on the grounds that they use Phonegap?
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.
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.
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.)
"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.)
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.
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.
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.
* 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.
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?
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.
[deleted]
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.
software dictators!
I think the problem might be that Phonegap allows people to develop rich internet applications. From there, it's only a hop and a skip to implementing a web browser, which they do not want app developers to do. Look at these two pages to see how I arrived at that theory:
http://groups.google.com/group/mozilla.dev.platforms.mobile/...
http://gizmodo.com/5072333/opera-for-iphone-ready-to-go-if-n...
I don't think this can be true - look at iCab Mobile, for example - it's pretty upfront about being a web browser.
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.