Part 1: The Law

Options

Everybody that owns Apple hardware or writes code for Apple platforms opts-in: users opt-in to buying the hardware, developers opt-in, or opt-out of developing for the program. A lot of people so far have chosen to deal with Apple, although honestly there have always been some fringe elements that really complain vocally about stuff.

The people who chose not to do it are unwilling to deal with the fact that Apple has provided the platform, has provided an incredible distribution infrastructure, and has put forth an unprecedented level of effort to make all of this work, and then effectively told the development community “There are some guidelines you need to follow. The reason our products are so great is because we have very high standards, and we push ourselves like crazy to make these things great, and our expectation is that people that buy software from our store are going to have a great user experience, so we are not going to sit back and allow your app to kill the phone.”

In order to help ensure that these guidelines are observed, Apple recently updated the language of section 3.3.1 their terms of service agreement, resulting in a great deal of consternation and at least a few rash decisions.

Section 3.3.1 – the Letter of the Law

There has been a lot of concern expressed over section 3.3.1 of Apple’s updated terms of use 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).

People are evidently reading way too much into the “Applications must be originally written” part of the statement “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.”

Michel Fortin is one such person:

Insanity at its best. If I need to write a parser for my application, can I write it in Lex/Yacc? No, because even though those tools just generates small snippets C code from a grammar it wouldn’t be originally written in C. What about regular expressions? What about routines optimized using assembler code?

Michel is clearly not understanding the point of this mandate, which should not prevent any of the options he is suggesting from being accepted by the App Store reviewers.

Section 3.3.1 – the Spirit of the Law

What people seem to be ignoring is the example provided parenthetically immediately afterwards: “(e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited”). This is what Apple is calling out, not source code generation tools like yacc.

Part 2: Why 3.3.1 Matters, or Middleware, Quality, and You

Quality Control

The thing that’s actually very interesting about this is, the demographic of people that would not be doing Objective C code are people that are trying to find a shortcut to getting something on the platform. They’re not the people that trying to use the tools that Apple provides to make the best possible applications, they’re the people that have targeted middleware (like Flash) in order to get their apps on lots of different platforms.

What the updated language of 3.3.1 is really doing is culling the developer herd for people that are specializing in developing apps that are optimized for the iPhone and iPad. Apple has made the call, that they are only interested in applications that are specifically targeted for their platform, and are tailored for that platform. They have no interest in things that are intended to be easily portable to other platforms because, by definition, you are making compromises in terms of quality in exchange for cross-platform compatibility.

Multitasking

Apple’s desire to provide a great user experience has historically led them to omit any support for multitasking amongst 3rd party applications. This omission wasn’t made because Apple is mean and wanted people to be unhappy, but because there were too many factors outside of their control to easily provide multitasking in a way that wouldn’t ultimately result in a unacceptable user experience for their customers.

Now, in iPhone OS 4.0, multitasking will be supported for the first time, and there are guidelines that applications are expected to follow. In light of this fact, it seems natural that Apple would have much more serious concerns about translated software built on top of 3rd party runtimes such as Flash or Unity.

The fact of the matter is, if we were developing iPhone applications using Adobe’s Flash publication process, I’d really have no ability to know whether or not my application would actually adhere to those guidelines. Who’s going to say whether or not something published through Adobe’s Flash tool is going to be well-behaved when it’s backgrounded?

Vendor Complacence

The other thing is that, as far as Adobe and Flash are concerned, Adobe has been dragging their feet for about a decade, doing as little work as necessary to sell their Mac offerings. Leopard has provided support for mainstream 64 bit applications since 2007, and developers have had the opportunity to start developing 64 bit applications well before that, but Adobe hasn’t needed to provide a 64-bit version of the Mac: most customers that care about such things will complain loudly and buy what Adobe hands them anyway. It doesn’t really have that much impact on Adobe’s yearly earnings statement.

Flash performance on the Mac is inferior to Flash performance on Windows for the same reasons: it’s good enough for Adobe, so they aren’t in any hurry to make it better.

There is no reason to assume that Adobe would be in any hurry to improve the performance of their Flash offerings on the iPhone, either. Which would put Apple (if they allowed Flash on the iPhone) in the intolerable position of providing their customers with a crappy user experience while at the same time being completely impotent to do anything about it, because Adobe doesn’t care as much as Apple does.

What It All Means

This is a fight for quality of user experience, and multitasking without compromising that user experience. Since vendors like Adobe can’t be trusted to look out for Apple’s priorities, Apple will look after them instead. If middleware vendors can’t be trusted to respect the rules of the playing field, they will be simply be banned from the game.

The fact of the matter is users are choosing to buy the platform, not because there’s a bunch of Flash apps for it, or because there’s a bunch of Unity-based apps for it, but because it’s a great platform.

Apple is saying, “if you want to have software on this hardware, here are the rules.” And everybody makes their choice: many people complain, but they often still fork over their money, and go along with it. Consider: users are willing to opt in to using AT&T as their carriers in order to use an iPhone. After that concession, anything else is pretty much gravy by comparison.

Update:

It appears that I’m not alone in hypothesizing that this is primarily related to multitasking concerns.

Update 2:

Nothing but net: “We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”