Tuesday, April 13, 2010

Steve Jobs and iPhone Developer Agreement Section 3.3.1

On reading Steve Jobs’s response on Section 3.3.1, there are two things that struck me:

First, like John Gruber, he doesn't seem to understand the implications of the new text in section 3.3.1. In particular, it says:

Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine...

This does not prohibit the use of cross-platform toolkits, which is what he seems to think it does. There are many cross platform toolkits that are written in C and C++. What it does prevent (as I mentioned in my post yesterday) is using other languages, something Jobs's argument completely ignores. That he wouldn't understand what the the text of this section actually means is pretty disturbing.

The other thing that struck me is his reason for wanting to keep cross-platform toolkits off of the iPhone OS. He's afraid that cross platform toolkits will make it easier to write apps that exist on both iPhone OS and competing platforms, and that if the same apps exist on other platforms people won't have a reason to purchase iPhone OS products. This suggests a lack of faith in the technology of the iPhone OS platform.

With the changes Apple has made to section 3.3.1 they are setting a very bad precedent. People have complained about the behavior of other platform owners in the past, including IBM, Microsoft, and the various game console manufacturers, for imposing all sorts of nasty restrictions on developers, but none of them have ever gone as far as to forbid the use of either toolkits or source-to-source translation. That Apple would do this suggests to me both a lack of respect for developers (and hence, a failure to understand that without third party developers a platform is basically worthless), and also a lack of faith in their own platform's merits.

posted Tuesday, April 13, 2010 (2 comments)

Monday, April 12, 2010

iQuality™

iPhone/iPad app developers:

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:

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

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 Lex, YACC, ANTLR or any other compile time parser generator. (for example: to produce a parser for parsing data fetched from the web)
    • Using a compile-time template engine. (for example: to generate HTML for emails)
    • Using gperf for perfect hashing.
  • 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.)

Other App Store policies have similar problems. For example, it seems extremely unlikely that containing an interpreter is positively correlated with low quality. Instead, the no interpreters rule locks out a certain class of app. You cannot have a PostScript or TeX viewer without an interpreter, for example. Emulators for old machines are also affected. (Technically an emulator is an interpreter, though Apple seems to allow emulators as long as they don't let the user supply new code to be emulated/interpreted.) Even Safari runs afoul of this rule given that it includes a JavaScript interpreter, but of course Apple doesn't need to follow their own rules.

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.
posted Monday, April 12, 2010 (1 comments)