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.

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:

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.

I have an unlocked Android (G1) phone. Miranda would like an iPhone, so we've decided to switch to AT&T. She can get her iPhone and I'll put a SIM card into my Android phone. (I'm okay with 3G not working on the Android.)

My initial thought was to get a free phone from AT&T, But then it occurred to me that this would use up my phone subsidy for two years. I tried adding a second line to a family plan on AT&T's website and then removing the phone, but it wouldn't let me complete the order. I decided to chat with their customer support. Here's the conversation I just had with them:

▶Thank you for your patience! An AT&T sales representative will be with you shortly.
▶You are now chatting with Tiffany, an AT&T sales representative.
Tiffany: Hello, Laurence.
Tiffany: Welcome to AT&T online Sales support. How may I assist you with placing your order today?
Laurence: I want to get a family plan with 2 lines, but only want one phone, as I already have an unlocked GSM phone that I would like to use.
Laurence: Is there a way to do that?
Tiffany: I will be glad to assist you.
Tiffany: You may order a free phone so that you can get the SIM Card from that phone.
Laurence: Im thinking about if the phone I'm using breaks or something, I'd probably rather get a better phone than just using the free phone. By getting the free phone I'm essentially locking myself out of a subsidized phone for 2 years though, right?
Laurence: (It also seems like a waste to get a phone I'll never actually use.)
Tiffany: If you would like, you may purchase a SIM Card in the store for $25, but once you sign the contract, it will be 2 years before a upgrade discount is given.
Laurence: I have to wait 2 years to get a subsidized phone even if I don't get any phone to begin with?
Tiffany: Yes, since the terms are for two years.
Laurence: So there isn't any way to get the contract, but hold off on getting a phone until later unless I want to either wait 2 years, or pay the full, unsubsidized, price?
Tiffany: You may set the line up online as a individual plan, then when the phone arrives, you may merge the lines in the store as a family plan and inquire on later getting a phone at a discounted price if you are not purchasing a phone at the time.
Laurence: I'm a bit confused.
Laurence: Let's pretend I was just getting an individual plan.
Laurence: Is there a way I could get an individual plan with just a SIM card (no phone), and then a few months later get a phone at the same price as if I'd gotten it when I got the plan?
Tiffany: The SIM Card will provide you with service, the service is for two years, it is not necessarily the phone, it is the contract that you are agreeing to which determines your discounts on the phones.
Tiffany: You term will still be 2 years, making it that amount of time to upgrade to a new phone for a discount.
Laurence: I understand that. I'm just surprised that I have to use the discount at the beginning of the contract or I lose it.
Tiffany: I do understand.
Tiffany: I do recommend that you visit your local AT&T Store to inquire on the procedure of using it at a later time.
Laurence: Ok, I'll try that. Thanks.
Tiffany: It was my pleasure, may I be of further assistance today?
Laurence: No, that's all I wanted to ask about.

The part that's especially ridiculous to me is that AT&T is essentially forcing me to waste their money. If they would let me save my subsidized phone discount for later, chances are I wouldn't even use it. Instead they're telling me I have to use it now, which means I definitely will and on a phone that I'm not even going to use. I don't even want to think about what that $25 charge for a SIM card that Tiffany mentioned is about.

I just saw Sunshine, and while going through the extras I was pleasantly surprised by this short video about the design of the user interfaces on board the ship in the movie. The whole video is pretty interesting, but the part that made me literally laugh out loud starts just after 1:47.

Occasionally I come across images that are hosted by Flickr, but which don't have a link back to the photo page on Flickr. This seems to be especially common on message boards and image bookmarking sites like FFFFound. Being able to get to the Flickr photo page is nice for a number of reasons: you can see other photos by the same author, see the metadata, notes, comments, others sizes, etc.

A Flickr photo URL looks something like this:

  http://farm2.static.flickr.com/1407/1085850486_23589455e2.jpg

Flickr has some nice documentation for their URLs. The URL above is of the form http://farmfarm-id.static.flickr.com/server-id/id_secret.jpg, so the photo ID is 1085850486 and the "secret" is 23589455e2. It's possible to find the photo page by using Flicker's API call "flickr.photos.getInfo", which returns XML containing the photo ID. That's tedious, and won't work in a bookmarklet.

Some more searching turned up the http://flickr.com/photo.gne?id=id URL. I can't find any official documentation for this, only some posts in the Flick help forums. It appears to work though, and it wasn't too hard to turn it into a bookmarklet.

To install the bookmarklet, just drag the following link to your bookmarks or toolbar.

[Flickr photo page]

To use the bookmarklet, first make sure that the photo is the only thing open in the browser tab/window. In other words, the URL in the address bar should be for the .jpg hosted on flickr.com. If the photo is embedded in a page you'll generally need to select "View Image" (or equivalent) from the context menu. (FFFFound is an exception: it caches the images, so you'll instead need to click on the image to be taken to the original) One you're on the image, just click the bookmarklet to be sent to the Flickr photo page.