John Siracusa:
Cumulatively, these actions represent a huge bet placed by Apple. The proposition is this: Apple is betting it can grow its platform fast enough, using any means necessary, that developers will stick around despite all the hardships and shoddy treatment. Each time it chooses to do what it thinks is best for the future of the iPhone OS platform instead of what will please developers, Apple is pushing more chips into the pot.
[…]
The win scenario is big: Apple as the dominant player in the most important new technology market. Microsoft-level dominance. But the flip-side is terrible—though I can see how it may have snuck up on Apple.
Unsurprisingly, the incentives for Apple and developers are not fully aligned. Larger developers will write for all the major platforms, regardless. For smaller developers, it matters little whether Apple achieves Microsoft-level dominance. They can be successful without a home run. Provided Apple continues to make a good product, the iPhone is likely to always have more marketshare than the Mac has enjoyed over the past 25 years. On the other hand, smaller developers could be in big trouble if they get banned from the App Store, or stuck in limbo. They’d probably be happy to trade some potential iPhone OS marketshare in return for certainty that if they follow the rules and spend the time and money to develop a product, Apple will let them sell it.
David Heinemeier Hansson:
It’s hard to build a business on a platform where you feel like you cannot trust the men in power. If they can take down Adobe a few days before the launch of their flagship product, what hope do smaller players hold?
Alex Blewitt:
Here’s what would be outlawed for future iPhone development with this new SDK agreement in place…
The list could go way beyond Flash, depending on how the rule is interpreted.
Jonathan Rentzsch:
Google behaves in predictably evil ways.
Apple remains innovative in their evil behavior.
Nathan Vander Wilt:
It’s surprising to me how many dozens of articles have focused on a tiny little extension of Apple’s incredible power over App Store developers. The written rules have changed a bit: so what? Apps still get rejected for all sorts of unwritten reasons or just sit unapproved for “continued study”.
App Store Code in App Store iOS
Louis Gerbarg:
So, if you will indulge my claim that backwards compatibility is hard (even absent the private API issue) it is pretty easy to see why supporting other runtimes is ceding a lot of control to a 3rd party. Imagine if 10% of the apps on iPhone came from Flash. If that was the case, then ensuring Flash didn’t break release to release would be a big deal, much bigger than any other compatibility issues.
Lots of applications using the same framework or library (that only uses public APIs) should, overall, reduce the amount of work that needs to be done to maintain compatibility. There are fewer roads to maintain, and each fix is magnified to hundreds or thousands of applications. Gerbarg is saying that Apple would prefer that each developer reinvent the wheel to prevent the wheel manufacturers from gaining any influence.
The reason is that I think Adobe holds much more of the blame. Adobe is a large company with a significant, and complicated, relationship with Apple. They have frequent high level contacts and meetings. Adobe has known for quite some time about Apple’s desire not to have Flash on the iPhone. There is no doubt in my mind that if they asked Apple to bless this they were rebuffed, and if they didn’t ask the only reason they didn’t was because they knew Apple would say no.
Of course Adobe should have asked for a blessing. They should have known that it doesn’t matter whether you follow Apple’s rules. What matters is whether Apple likes you or sees you as a threat.
Apple should also find some way to loosen the license to officially allow games to use included interpreters for their internal logic. I don’t know how to do that without opening up loopholes, but that is what lawyers are for. If they don’t do that then effectively they are just using their discretion on a case by case basis, which is completely legitimate, but causes significant uncertainty for developers. Ideally Apple should have some provisions for adjunct or secondary runtimes that let developers use internal scripting.
It strikes me that this whole issue is mostly about politics and appearances. I doubt that Apple cares whether applications use libraries or interpreters or parser-generators for their engines. And I doubt that most developers who are upset about Section 3.3.1 care much about Flash. If Apple had simply said that Flash was banned, in any form, they would have achieved their goal, and the rules would be clear. But Apple didn’t want to say that, so they came up with the messy ideas of no interpreters and originally written in Objective-C. This seems like an impossible line-drawing problem, so I think we can expect more convoluted, post-hoc rules and discretion going forward—and, thus, more risk for developers.
