Monday, March 17, 2008

Response to "iPhone SDK inhibits Mobile Innovation"

The “Apple’s iPhone SDK inhibits Mobile Innovation” article has generated an enormous response. Specifically 4000+ people have read the article since it was posted on Thursday. To put that in context that was just a bit under my unique visitor count for all of Feburary. The piece was linked to by the dean of the Macintosh commentariat John Gruber at as well as Hacker News (, dzone, and a bunch of other websites and blogs.

The comments have generally been either in agreement, or in the case of John Gruber, largely but not totally in agreement. Even in his case it does appear that I effected his thinking on the subject. As of this writing, the dzone website has the article listed with 14 vote ups and one vote down. And so my mission of educating people on this issue and changing some minds has been largely achieved here and so I want to thank you guys for spreading the word.

There were 33 comments, the most ever for this blog, and while I can’t respond to all of them, I want to thank everyone who took the time to write. I did also want to pick a few out and address them in a post since others might have had similar thoughts or questions.

From Steven:

Interesting write up but I do take exception in thinking there are some problems that can ONLY be solved with Andorid (or some brand XYZ OS). In 25+ years of programming, I have found that background processing is simply one tool (and in the grand scope of things a very small tool) in the overall tool chest.

My Response: I did not say, and do not believe that some problems can only be solved with Android. I believe two things:

  • At the present time, Android is the *easiest* platform to do the things we are doing. This relates to communications, which requires background processing, and location based apps, because Android understand maps at the OS level. The mapping stuff is not core to the argument here. I provide it only as background.
  • Background processing is absolutely required to do *communications* apps. If you're doing Excel on the desktop or Doom on the hand held, you will not have a problem.

From Demailien:

You claim that resource management problems for background third party apps have already been solved in real time systems. Frankly, I'm calling BS on that. I can not think of a single real time system that is open to background process third party apps (already a very rare beast), that has created a good solution to this. Indeed, the only example that I can think of (WinCE), is generally considered a textbook case of why this sort of programming is a bad idea for real time systems.

My Response: Hmm… I love it when people quote you as saying something you didnt say, and then attack you for it.

I didnt say this: "You claim that resource management problems for background third party apps have already been solved in real time systems."

What I said was that the problem of background tasks running safely has been resolved. But more importantly I think maybe you are not clear on the definition of a real time system. For a full definition read here. Phones actually do not qualify. Real time applications are applications where the response time must be guaranteed. This has typically been the case in the embedded software world. Probably the most commercially successful RTOS is VxWorks. Windows CE is most definitely *not* an RTOS and is never sold as such.

Moreover, I did not say that any RTOS supported third party applications. What I am saying is that many platforms have demonstrated the ability to finely control the amount of processing power, memory, etc that an piece of code can use. These techniques are *totally* transferable, given that a phone is a far less critical than some of the environments where these kinds of things are often run.

In this particular case, the types of background tasks we are talking about could be scheduled to run at perhaps 1/1000th of the available processing power, which would essentially be negligible. This is just not hard.

From Timothy:

Comparing Android, which is not actually available on any phone, to the iPhone SDK, which is a beta, seems a little odd to me. Who knows how Android will behave when available on an actual product.

My Response: As it is, the Android SDK *is* better for communications. The reason is clear. You can’t do communications *AT ALL* with the iPhone based on the current spec. So on that front, you are right, there is no comparison.

From Anonymous:

Actually, the AIM example was perfectly valid. You can use AIM for chatting when your want to chat. If you exit the app, sure now your chat client is no longer running. But nothing in the demo or in the discussion implied that it would--only you assumed that it had to be real-time, constantly on, and behave identically to a desktop equivalent. But it doesn't have to, and for many, if not most, users, the ability to use AIM for quick chats is a huge win even if the live notification is not present.

My Response: Ok so if you are on your iPhone, do you appear in your friends buddy lists as available? If not then you are saying the iPhone would be the first outbound only AIM client. If so, then what happens when in the 99.9% case your phone is inactive, or doing something else and does not receive your IM. I cannot imagine AOL presenting such a design as a real AIM client. But indeed it is AOL and perhaps stranger things have happened. If AOL does introduce such a lame turd for their iPhone AIM client, you and others who suggested the same will be right and I will be wrong.

From Anonymous:

"Our application would not be easily possible on any platform other than Android."

Any? What about platforms other than Android or iPhone? Would it be harder on OpenMoko, for example?

My Response: OpenMoko may end up being a fine system, but it is far more bare bones than Android. And so while everything we are doing could indeed be done on OpenMoko or Qtopia for that matter, it would not be “easy”. Of course this is indeed better than the iPhone, where these sort of communications based applications are impossible.

From Kelake:

You as a developer may care about the lack of this feature in the sdk at this time but I highly doubt that the majority of the customers for this device do.

My Response: End users don’t know they want something until they see it and understand its usefulness. This is the way innovation works. People didn’t know they needed PCs, or spreadsheets, or graphical user interfaces, until they saw them. With background processing enabled, developers will create innovative apps that users will care about very much.


  1. This comment has been removed by a blog administrator.

  2. "[OpenMoko] is far more bare bones than Android"

    Can you explain how? I'm no expert at either, but OpenMoko is Linux, with (for the most part) the same libraries the workstation on my desk is running. Android has some nice stuff, too, but it looks like mostly the same level. I don't see anything that Android offers that OpenMoko either doesn't offer, or couldn't trivially be installed on OpenMoko.

    If anything, OpenMoko looks higher-level, because (as a developer) I can pull in basically any Linux library or language I want, while Android gives me Java only.

    "OpenMoko may end up being a fine system"

    So may Android: neither OpenMoko nor Android is officially released yet (though I can buy a phone today that will run OpenMoko, which is more than I can do with Android! :-)

  3. Technopeasant here, with a couple tangentially-related comments:

    1) I'd love to see a real word processor for the iPhone/Touch. How about something like OpenOffice's program, or even a non-junked-up version of Word or WordPerfect? If Apple's going to be installing handwriting-recognition software a la the Newton on the Mac OS X and probably the iPhone and Touch, it sounds as if a full-on word processor for their handhelds is also in the cards (or should be).

    2) Apple should make a case for the iPhone/Touch that has solar cells on the outside. You'll run down the battery faster than the cells can charge it, but it should extend use time an extra hour or so. If you turned the iPhone/Touch off and let it charge in the sun, you could probably have it charged at least half full in the course of an afternoon. (If you could connect extra foldable solar panels to collect more light, charging time would shorten greatly.)

    Here's a solar charger case for the SteriPen, which is a UV-light-using water purifier: The SteriPen's dimensions are thicker than those of the iPhone/Touch, so the corresponding case for those two items would be thinner than that of the SteriPen.

  4. I love how you miss the huge piece of very important information in the SDK announcement:

    Apple will run a single background daemon on the phone which will passively listen for background events, and fire up the app they were delivered for on demand.

    AIM is no doubt implemented as such:

    1. AIM is opened and signs on.

    2. AIM registers for notifications (buddy presence, IM, etc.)

    3. AIM is backgrounded (killed), but remains online until the phone disappears from the notification server (no network connectivity, turned off, etc.)

    4. If messages, etc., come in, an alert is displayed; if the user wants to respond, they touch a button like "Show", just like SMS works, and AIM starts up.

    5. When some event causes the user to sign off (disconnect, turned off, dead battery, etc.), they show as offline to buddies.

    That framework is perfectly usable for ANY comms app. At worst, you need to write a gateway to translate server-side events into Apple's events standard.

    As a customer and a developer for the iPhone, I don't WANT your background apps. Background apps drain battery and reduce usability. No matter how well you "manage" those apps, having 16 apps each taking a "managed" CPU slice to do background push/pull is a broken concept. Apple's means of addressing this is not only innovative, it's something that desktop OSes could emulate.

  5. Wow. Amazing how dumb Mr. Anonymous is. He is all over the internet leaving poorly thought out comments. seemingly thousands every day. I don't know how he does it, but I will give him credit at least for being very fast. But Here Mr. Anonymous doesn't even look at the date of the article he is commenting on to realize that the article was written before Apple's recent announcement.


Note: Only a member of this blog may post a comment.