Monday, April 12, 2010 [Tweets] [Favorites]

All About the Framework

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.

2 Comments

If the fear is that Apple could become dependent on some other vendor (such as Adobe), perhaps Apple could force any such translation layer or interpreter to be publicly available as open-source.

And it'd put a lot of pressure on Adobe for making Flash opensource.

http://michelf.com/weblog/2010/reconciling-proposal/

> 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.

Not a defense of the clause, but it's interesting to note that a "total environment" type framework like mono or cider may need to do weirder things than any normal app ever would, because an app has the luxury of changing its mechanisms to mesh better with how the system works. If you're mono, the contract is set, and the contract is very detailed, and you have to meet it. To do that may require perching the whole kit and caboodle on something precarious. Mono is trying to run code when every thread is detroyed, and there are ordering problems with respect to other pthread_exit handlers.

Cider does similar interesting things. It continuously registers a signal handler for every signal that catches the signal and tries to go on.

The Go language is written not on top of libc, but rather directly to syscalls, which are not supported API and does change between OS versions.

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment