Any ambitious regulatory scheme will face pressure to expand, in order to protect the flanks of the main regulation against users’ workarounds. Apple’s strategy of regulating which apps can run on the iPhone and iPod is just such a regulation, and over the last week or so Apple has been giving in to the pressure to expand its regulation.
To illustrate Apple’s regulatory problem, consider a hypothetical iPad app called Ed’s App World (EAW). EAW lets you download items called EdApps, which consist of instructions that the EAW app carries out. Any developer can create an EdApp which expresses its instructions in Ed’s Programming Language. It’s entirely possible to create an app like EAW.
Apple’s regulatory problem is that Ed’s App World is effectively a competing app store — EdApps can do anything that apps can do, and any developer can create and distribute an EdApp. If Apple wants to prevent competing app stores, it has to keep apps like Ed’s App World from existing.
Apple has long been trying to keep specific technologies like Adobe’s Flash off the iPhone and iPad because these technologies have EAW-like features. Now Apple has expanded its regulation to say that only certain programming methods are acceptable. Here’s section 3.3.1 of Apple’s iPhone developer license agreement:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
This rules out many common programming languages and tools. To developers, it looks like Apple is trying to micromanage how they do their work.
Apple’s ban on programmable apps goes beyond just Flash. This week Apple banned Scratch, a widely used educational tool that introduces students gently to computer programming by letting them construct animations. Why did Apple ban the Scratch app? Presumably because Scratch animations involve elements of programming. Computing educators were unhappy, to say the least. Mark Guzdial of Georgia Tech put it this way: “Want to be truly computing literate, where you write as well as read? There’s no app for that.”
What’s really interesting is that despite Apple’s best efforts to block these apps, there is an enormous EAW-type system that Apple hasn’t had the guts to block: the web. Thanks to so-called Ajax technologies, the web has become a vehicle for delivering app-like functionality (within web pages). Apple’s Safari browser on the iPhone and iPad supports these apps well. It’s hard to imagine that Apple could get away with blocking all of the Ajax-enabled sites we use every day. And Apple’s Ajax problem will become even worse as HTML 5 comes online, with even better support for web-based apps.
If you’re not a techie, this stuff may seem like inside baseball to you. But it does affect what you can do and see. You may not know all of the details of why the app store starts looking more and more like Disneyland, but you’ll notice that it’s happening.
Finally, I want to address the common objection that most people don’t care about limits on programming, because they don’t know how to program. To me, this is like saying that you don’t care about restaurant closings because nobody in your house knows how to cook. If you can’t cook for yourself, you should care more about restaurant quality. If all of the good restaurants close, good cooks will just make their own good meals — but you’ll be out of luck.
