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 daringfireball.net as well as Hacker News (news.ycombinator.com), 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.
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.
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.
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.
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.
"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.
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.