How Apple Really Screwed Up With New License
sheddingbikes.com
sheddingbikes.com
I actually predict that this will be a major problem for Apple in the
future, but probably won't impact their bottom line for their mobile
platforms. Programmers never forget things. They are notorious for
not updating basic knowledge they believe and for spreading myths
and rumors about technology for decades. I can actually see a situation
building where programmers who maybe wouldn't have worked on an
iPhone application would still avoid targeting Apple products simply
because of the stories about Apple doing "A Section 331" on them.
This.Despite my personally benefitting from the new policy change, (I write Obj-C comfortably and will benefit from the reduced competition,) I think Apple is making a grave mistake trying to extend their review checking process in a manner that can only be done in reality by visiting each and every developer. I'm not convinced Apple's in-house analysis tools will be able to capture violations in a manner consistent with their current license wording.
It's just going to degenerate into a cat-and-mouse game with the larger and/or more tenacious middleware developers, leading Apple to waste resources and R&D money on license enforcement, driving down profits and adding significantly to the large pile of ill will Apple has accumulated in the last few years. Apple is still living down past quirks and excess of their platforms, like "Cult of Apple evangelism" and "one-button mice," that are no longer true, but hang around their necks like a long decaying albatross. In short, this could help cause Jobs to lose control of his platform's message to the masses if the people able to recommend their hardware and platforms keep sticking "asterisks" to their recommendations.
Stupid rules are not improved by selective enforcement. The randomness, the unfair application of them makes it worse.
What I believe programmers are truly angry about is that Apple broke their long standing promise of supporting multiple languages when they originally attracted them to the platform. They're really saying:
"You told me if I bought a mac, and an iPhone, and an iPad, that you would create LLVM and MacRuby and Python bindings so I can code in my favorite language. You lied!"
Nobody is really saying that because neither Apple nor any of their employees have ever told anyone such a thing. On one hand the ban of interpreted code, except for Javascript, has been there since day one, so no sane programmer has had the illusion that they can use Ruby, or Python, or whatever to write iPhone apps. And on the other hand there is absolutely nothing preventing Apple from amending that clause in the license agreement once the technical limitations, e.g. garbage collected Objective-C runtime, behind toll-free, ahead of time compiled wrappers like MacRuby disappear. Especially since MacRuby in particular is an Apple run project.
So it's hard for me to see why an app that was written in Ruby or Python would have been disallowed before the recent changes.
And it seems the C64 app (the one that's up now, that can't run arbitrary code) will be disallowed after these changes go into effect.
I'd sure like to hear ideas of how that could be worded. I strongly doubt they'll back down and allow the Flash compiler at this point. But they obviously want to keep Monkey Island, and perhaps even Unity 3D. How could they possibly word a new version of the clause to make this distinction clear? Can a formal distinction be made?
"An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. 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)."(emphasis mine)
However it was changed, with OS 3.0 SDK I believe, certainly before the OS 4.0 SDK changes, to its current wording:
"An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built- in interpreter(s)."(emphasis mine)
I still maintain my position that for quite some time now developers should have had no expectations to be able to write applications for the iPhone in Ruby or Python, or some other interpreted language or at least to be able to distribute them through Apple's app store. Although in reality there seem to be plenty of applications in there that have some scripting component or another.
No, they can't, because the predicate for the Microsoft enforcement action was their monopoly position in the desktop market, and the cause of action was their attempt to use that monopoly to create new monopolies.
Apple has nothing close to a monopoly on smart phones (they are crushed by RIM).
I'm also confused by the thesis of this blog post, which seems to be that there was a bait-and-switch pulled on the Apple dev community writ large. The vast, overwhelming majority of iPhone apps are written in ObjC, and Ruby is no more a second-class citizen on OSX today as it was last year.
The curtain has closed; Apple is now evil... move on.