Bampot of the Week: Alexander Wolfe

John Gruber has his occasional Jackass Of The Week award, for which Rob Enderle seems to be in line for a lifetime achievement award. I needed a more Scottish equivalent, so here is my Bampot1 of the week: Information Week's Alexander Wolfe, for his overblown and incorrect piece about the iPhone SDK entitled "iPhone SDK Developers Angry At Apple's Tight Control".

Let's take the piece apart, Gruber-style:

Apple's mindset is apparent from the get-go. They've gone non-disclosure crazy with the iPhone SDK, though admittedly no more nuts than usual. Here, what they're doing is keeping the all the stuff people want to know under much tighter wraps than they need to. For example, you can download the iPhone SDK for free, but you have to pony up $99 to get at the really good documentation, sample code, and developers' videos.

This is simply not correct. Firstly, the NDA is a standard thing for pre-release software from Apple and many other companies. The iPhone NDA is little different to others I've seen but to discuss the contents of the NDA any further would be to break its terms.

Wolfe makes a factual error in stating that you have to pay $99 to get the documentation and sample code: you get that when you download the SDK. The documentation, samples and videos are available for the price of registering for a free ADC Online developer account. The videos are available via Apple's ADC on iTunes service.

OK, that's relatively minor. Pay the $99 and be done with it. I think the bigger problem for developers is going to be death by a thousand cuts. By this, I mean that Apple never seems to put all its cards on the table at once. For example, on Sunday Phonemag reported that the SDK contains a tidbit noting that the iPhone won't run more than one app at a time, so when users switch applications, whatever is running in the background will get killed.

If Apple "never seems to put all its cards on the table at once", how come we know about the no-background-threads limitation? If it were a hidden limitation, we would only learn about it when someone tried to write a background app and it failed to work. Documenting limitations isn't the same thing as hiding them.

From Apple's standpoint, this is done to maintain decent performance. However, developers are likely to see it as just another screwing.

If Apple had promised me that I would be able to write supported background applications with the SDK then, yes, I would feel screwed. However, to my knowledge, no such promise was made. Having used Windows Mobile devices that do allow process to live on in the background, I can only hope that Apple enforces this limitation as rigidly as possible. Nothing else makes sense for the user in a resource-constrained environment like a phone.

The trick for we developers is to make it look like the app was running all along.

Me, I want to know what's supposed to happen if you're in the middle of something important and your iPhone rings. Does your app blow up?

Yes, the only possible explanation for what happens when another app is launched is that the iPhone deliberately crashes the one you're working in. For "blow up", let's substitute "get suspended, saving its data for later resumption" and then we can answer yes.

The same thing will happen to your app when the user hits the Home button. Does Wolfe think that the Home button will be made into a "crash my app" button in iPhone 2.0?

There's lots of complaining about the fact that all iPhone apps have to be approved by Apple, will be sold by Apple, and Apple will get a 30 percent cut of all sales. On the other hand, John Siracusa at Ars Technica says that "developers see dollar signs" in iPhone apps, so presumably they'll deal with the restrictions.

Great argumentation: "lots" of unlinked, unattributed 'complaints' and the one attributed remark actually refutes the point of the paragraph.

Turns out, though, that developers are limited in what iPhone functions that can tap for the apps they're building, according to Adam Houghton's post on his eponymous blog. Houghton characterizes as a "glaring" omission his discovery that developers can't access calendar appointments, music and videos from the phone's iPod app, nor phone and SMS functionality.

So there's missing functionality. The SDK is beta. File an enhancement request.

How is Apple's rule that only apps it has signed can run on the iPhone going to play when it comes to corporate applications? One commenter on Slashdot ...

...and that's the point at which you have to laugh and close the tab.

This is a lot to digest, and quite frankly most developers will suck it all up because, hey, it's the iPhone.

I think, right now, "most" developers serious about the iPhone are still reading and reading and writing test apps and figuring things out. Despite it being a lot to digest, that's apparently no reason for Wolfe to hold off on filing an ill-informed attack piece on an SDK he clearly has not even downloaded and investigated. If he had done so, Wolfe would know that you don't have to pay $99 to get the documentation, sample code or videos.

Wolfe seems to have totally missed the point about the SDK. He mostly seeks to criticise the no-background limitation, but the majority of unresolved questions in all of this are about the App Store. Here are my questions:

  • How do we do a public beta release without charging for it? I never charge users for beta releases.
  • Will developers be able to generate coupon codes for free downloads? This is very important for promotional purposes.
  • How will the App Store handle discounted upgrades to new versions? Upgrades keep the lights on in year 3.
  • How and under what circumstances might Apple revoke an application's right to run? Does the customer get a refund, and from whom?
  • How will it handle demo versions? Trying before buying is important. Seems like this would be easy to do with FairPlay embedded in the applications.

For me, those are the real questions. The technology is great (which, given the NDA, is about as much as any developer should be saying about it right now) and all the known unknowns are about the business deal.

[Update: 1. Bampot (Scotland, slang, pejorative) idiot; an objectionable and foolish person.]