Monday, April 12, 2010
iPhone/iPad app developers:
- Pay $99 for the privilege to improve Apple's platform by developing new apps for it.
- Have only one option for distributing their software, which involves paying Apple 30% of their revenue.
- Risk having their apps disapproved after the app has already been developed. Reasons for disapproval include:
- Having functionality that overlaps with existing or future Apple products.
- Including an interpreter of any sort as part of the app.
Note that initial approval doesn't mean you won't get pulled from the App Store later on because Apple decided to change the rules.
- And now, due to Apple's recent changes to section 3.3.1 of the iPhone developer agreement, developers must use an Apple prescribed programming language: Objective-C, C or C++. This new rule means that you can't even use a compiler that emits one of the allowed languages.
Apple apologists often claim that these hurdles improve the user experience by acting as a sort of quality control. Sometimes a comparison to the "Nintendo Seal of Quality" is made.
The Nintendo Seal of Quality was developed by Nintendo in the 80's as a response to the "video game crash" that happened earlier that decade. One of the reasons for the crash was a glut of crappy games that made people wary of buying games in general, and eventually lead to the (albeit, prolonged) death of Atari and much of the video game industry at the time.
A recent example of this sort of argument was John Gruber's Daring Fireball post on the change to section 3.3.1 of the iPhone developer agreement. In it he says:
On the one side, this rule should be good for quality. Cross-platform software toolkits have never — ever — produced top-notch native apps for Apple platforms. Not for the classic Mac OS, not for Mac OS X, and not for iPhone OS. Such apps generally have been downright crummy.
The iPhone OS Kindle app is excellent, a worthy rival in terms of experience to Apple’s own iBooks. The Mac Kindle app is a turd that doesn’t look, feel, or behave like a real Mac app. The iPhone OS Kindle app is a native iPhone app, written in Cocoa Touch. The Mac Kindle app was produced using the cross-platform Qt toolkit.
There are a few serious flaws with his reasoning here.
First of all, there's the question of whether cross-platform toolkits have ever produced top-notch native apps for Apple platforms. (The "for Apple platforms" qualifier here seems superfluous to me, but I'll let it go.) He claims that they never have, but I doubt that he has actually performed a exhaustive survey of software for Apple platforms to determine this.
Virtually all software with a graphical user interface that exists on more than one platform makes use of some sort of cross-platform toolkit. While it's easy to spot a badly ported application, applications that have been ported properly are indistinguishable from ones that were written "natively". It wouldn't surprise me at all if a number of the "top-notch apps" Gruber uses actually do use a cross-platform toolkit without his knowledge.
In fact, Firefox is built using XPCOM, a cross-platform toolkit (the "XP" actually stands of "cross-platform"). One could even argue that WebKit is a cross-platform toolkit as well (though it's specific to HTML rendering, rather than being a general GUI toolkit). So if Gruber is right then none of Safari, Google Chrome, or Firefox are "top-notch native apps".
But for the sake of argument, let's say Gruber is right and that cross-platform toolkits really have never produced top-notch native apps for any Apple platform. It doesn't matter, because the "cross-platform toolkits" argument is a complete red herring. Take a close look at the text of section 3.3.1:
There's no talk about toolkits here — it's talking about languages. There is nothing about this rule that prevents you from using a cross-platform toolkit provided that it's in Objective-C, C, or C++. Qt is a C++ toolkit, so if it weren't for the fact that it relies on a pre-processor (which is unusual for cross-platform GUI toolkits) then there's nothing about section 3.3.1 that says you couldn't port a QT app, like the Kindle application, to the iPhone OS.
Some of the things section 3.3.1 actually will prevent are:
- Writing apps in other languages that teams may be more proficient in (Lisp, OCaml, Erlang, Scala, Python, Ruby, Java C#) even if C, C++ or Objective-C is used as an intermediate step.
- Hand-coding inner loops in assembly code (a common practice in games).
- Using domain-specific languages for specific tasks. For example:
- Using code transformation tools. For example:
- Internationalization tools that perform build-time string extraction and reinsertion.
- Macro processors like m4.
- Using existing libraries written in other languages. For example, many numerical libraries are written in Fortran.
As a software engineer, I'd be very surprised if any of the above had a correlation with lower quality applications. On the contrary, it tends to be the more proficient software developers that use a wider variety of tools, including ones like those listed above. (Luckily, actually identifying apps that violate this policy would be very hard, if not impossible, without the source code. If it weren't for this fact, we'd likely see a number of existing apps get pulled off of the store.)
But never mind what I think. Even if the intent behind these policies was to keep low quality apps out of the App Store (which is hard to believe) the fact that the App Store is full of crappy apps is evidence enough that they've failed in this regard. These policies don't work to keep low quality apps out. The various high profile examples of apps that have been either disallowed, left in review limbo or lobotomized also speak strongly against the notion that Apple's policies have anything to do with improving things for their users.
So to sum up:
- Many of Apple's policies don't appear to have been designed to improve quality.
- If they were designed to improve quality, the large number of garbage apps on the App Store make it clear that they aren't really working.