Thursday, March 13, 2008

Apple’s iPhone SDK Prohibits Real Mobile Innovation

Last week Apple opened up the iPhone and introduced a software developer’s kit (SDK) to allow third parties to develop software for the iPhone. This was a great step forward in that Apple had, for some significant period of time, suggested that writing software within the browser environment was sufficient, and that no native developer platform was needed at all.

Unfortunately, some of the details we have discovered about the SDK will have a real impact on the ability of developers to innovate on the iPhone. The issue is that Apple has set a policy that third party application developers can't create applications that run in the background. Currently, there is a minor uproar in the blogosphere about Apple’s policy on this matter.

The purpose of this article is to convince all of you that the uproar should not be minor.

Background Processing is the Key to Mobile Innovation

Prohibiting background processing is not just a question of one feature being left off a long list of otherwise very well executed features. The issue of background processing is *the* issue for a mobile device because it is key to two things:

  • telling the world about your status in some ongoing way
  • receiving notification of important events

These two things are the key to most new real innovations in the mobile space. To be clear, by innovation, I mean creating functionalities that have not been possible before. I do not believe that Apple’s beautiful new iPhone UIs or visual metaphor’s allows for the creation of truly new application categories. Apple’s tools are great, but they just make apps that were already possible, easier to build and easier to use. But as a developer, I want to create things that have been bottled up in my head but without the right platform, were fundamentally impossible to do.

Lets look at some of the specifics of what kind of limitations the “no background apps” policy really imposes.

Communication Notification

In order to innovate in the communication area, you must have notification. Without it there is no push email, no phone ringing, no instant messaging, no twitter notification, and on and on. Of course some of you will argue that you don’t need third parties to do this stuff because Apple will handle all that internally. But Apple didn’t invent instant messaging. They didn’t invent Twitter. They didn’t invent VOIP. And they certainly didn’t invent the phone. By making third party communications related innovation on the iPhone impossible, they are potentially killing the next great thing that could only be done on a mobile device, but won’t be because Apple forbids it.

Environmental Notification

Of course, there is more to this than just communications. You can’t even implement something as simple as an alarm clock without notification. More interestingly, there are a whole host of location-based applications that are impossible with the current restrictions. I’d love to have an app that notified me when I was near something that I have been looking for, like perhaps an open house for a piece of real estate in my price range. Personally, I believe that location based notification is the most fertile of all the potential new areas of innovation.

Presence & Location Broadcasting

Presence, the concept of notifying others that you are “available” in instant messaging applications, is a huge and important functionality. It has become important in a whole host of applications beyond pure instant messaging. In the mobile world the concept of presence takes on even more significance, and with location aware devices we can broadcast not just “presence” but location. Again, neither presence nor location broadcasting is possible without background capability and the Internet is filled with discussion about how these concepts can change social dynamics. But as it stands now, none of that innovation or exploration will happen on the iPhone.

The Politics

The rationale to Apple's position is never directly stated, but is implicitly clear. Background apps are risky because they can harm the user experience by bogging down the phone. This is, of course, bogus. There are many ways to address this through task prioritization, and sandboxing background tasks or even limiting their size. There are lots of other things Apple could do that I won’t list here. But the point is Apple has some of the brightest engineers on the planet, and this issue has been dealt with in Unix, and with real time systems for many years.

In short, this argument is a strategically placed fig leaf, which is easily blown away.

The truth is the real arguments are much more about business and an incredible ambivalence about developers. First, Apple is concerned about protecting its revenue streams, and about being the innovation leader on the platform. More importantly, Steve Jobs has a bizarre discomfort with being out-shined by third party developers on his platforms. And he has a lifelong personal preference for absolute control over everything. Often that drive serves him and his company well. In this case it does not.

The Dishonest SDK Rollout

Of course, its one thing to have a strategically flawed policy. It is another to attempt to trick the market with a disingenuous marketing event. At the SDK launch, Apple presented AOL Instant Messenger as an example of a product that was developed with the SDK for the iPhone. Now I haven’t used the iPhone AIM client, but I can’t imagine that it will not have presence or notification. But with Apple’s current policy, you can’t build a fully functional instant messenger because you can’t do presence or notification without background processing. Obviously AOL got special dispensation to break the rules. But the rest of us developers will not make it past the velvet ropes. And so, at least this aspect of the Apple launch was a lie.

Apple vs. Android

My company has been developing an application for Google’s Android phone operating system for the last several months. Our application would not be easily possible on any platform other than Android. In fact, important parts of the application are impossible without background processing. In short, Apple may be visually sexier, but I can actually innovate more effectively on Android. This should never be. I would love to develop for the iPhone, but right now I can’t see how to make it work. Interestingly, Android also builds maps in at an OS level, which, in my view, is far more important than great animation or the new screen pinching technology.

What To Do

Apple’s new platform will make it possible to create lots of great games, and really pretty more functional user interfaces. But personally, I’ll take one paradigm shifting application over a thousand cool games any day. So if you agree, I strongly suggest you say something. Link to this piece or restate the arguments elsewhere.

Apple does respond to customer uproar, and right now the SDK feedback is way too positive given the significance of what is missing. The market excitement is a response to the eye candy, which is great. Perhaps even necessary. But it is not sufficient. In attempting to keep all innovation to itself, Apple is really doing a disservice not just to us, but in a shortsighted manner, it is also doing a disservice to itself. In fact, Apple is slowing down the kind of innovation that will most assuredly drive the next generation of mobile experiences.

And so I say, Please, Mr. Jobs, tear down that wall.


  1. Great Post Hank, a clear assessment as always of the issues and cutting to the core of the matter.

    Steve Jobs may have learnt a lot standing on the shoulders of Palm and Windows Mobile but here is a lesson that Steve Jobs still hasn’t learnt.

    Why Was Palm able to succeed when all others before it failed (and by Palm the smart ones reading this blog know I’m really talking about Jeff Hawkins and Handspring).

    Because their SDK and coding tools where the bomb.

    This crippled sdk download that apple is pushing on the suckers is just plain defective and hardly ‘an opening on the platform’.

    Dean Collins

  2. Apple knows what they are doing and they have good reasons to make their choices. However they remain open and listen to the users. When the time is right they might allow background processing. I hope they are listening to developers requests.

    In the meantime the iPhone platform without background processing does not make it less of an iPhone. Lots can still be done and when background processing gets introduces we can just update our codes accordingly.


  3. I agree that this SDK limitation limits the scope of applications that can be created for the iPhone.

    I understand the security and performance concerns of running daemon type code. Maybe apple needs to add another level of developer to their development program that allow daemon developers to have their code reviewed and approved.

  4. apple opens it's iphone sdk so people can develop. no tech is meant to be 1 million percent perfect in it's trial period. up until last week everybody was crying" boo hoo hoo, no sdk" now they give you something and you're all trying to pick it apart for what you belief to be " an less than perfect sdk" because there is no background stuff. I for one know the deal and history should show you so does apple.

    They like many of you must make trial and errors before they put it all out into the world

    They are basically putting this out to see which way to go and how to implement all the things you are complaining about that are not there.

    Hank has a very good observation that it will be good for games only for anyone that is paying attention you must realize that gaming is becoming a HUGE thing in doing business in general. Alan Kay's Open Croquet project, Second life(which really sucks in many ways) and many other virtual type developments are all connected to gaming. Think about that.

    If you people think that the guy who basically started the personal computing industry, started Pixar(probably one of the highest money making studios as far as films and merchandising),and who also brought us the iphone, has just left out background processing(because maybe he and all the people around him just kind of overlooked it maybe), then I would say you are not looking at the big picture.

    Work with what you have now and make cool stuff and the rest will fall into place. Apple doesn't just do things and hope they work out. those are very savvy people. There's more than meets the eye here and they want to see how the wind blows before they allow certain things.

    Think I'm full of it?

    At present you are able to listen to a tune and at the same time answer your phone, talk, and then after your call, resume your tune at the same place.

    Do you really think that this won't be made available to all of us when the time is right.

    seriously think about it all.

    best regards,


  5. iPhones don't have to suck. They can rock.

    See ideas at

    Hank, please trade links with me!!!

  6. Hank,

    Very crisp, well articulated post. It will be interesting to see whether some of these limitations are trial balloons or not.

    I hope that they are, and that Apple continues to iterate their SDK strategy until they hit the sweet spot required to decisively win the hearts and minds of the developer community.

    Apple’s history with developers gives some reason for skepticism, something that I recently blogged about in, ‘The Scorpion, the Frog and the iPhone SDK.’

    Check it out if interested:



  7. I’m sure there are lots of good examples of background tasks that might be useful, but this article only gives really bad ones. Should Apple really convert the iPhone platform into a testing ground for the next Twitter? Does the phrase “security issue” raise any flags? You can’t invent a new communications protocol and roll it out in real time over a mobile device network–without any controls in place–and expect things to work out well.

    The iPhone isn’t a development lab, it’s a phone. It has to work. It can’t be run down dead because some developer releases what they think would be a good neo-Twitter/IM/VoIP client, and finds mass adoption before realizing they’ve introduced major performance problems or perhaps exposed significant security issues.

    Look at the security holes that have been discovered in Sun’s Java or QuickTime or IM or HTTP or any other protocol, and you have to second guess the ability of individuals primarily interested in “cool” to recognize every security issue they might raise in building apps on a platform that, unlike the iPhone, has no parapets at all.

    The second idea of ‘location notification’ sounds great, but how many notifications will your iPhone alert you to before the battery is dead from constantly polling its location? Real satellite GPS draws so much power that it typically needs to be plugged in (or have big batteries). That’s why the iPhone has a click to locate button rather than providing a constant update on your location. The author didn’t give this much thought.

    Apple also knows a thing or two about presence indication, and has worked hard to make Bonjour as efficient as possible in announcing itself and listening for available services. This is an OS level service, not something you want every third party app implementing independently, for many of the same performance, battery, and security reasons.

    Calling the the iPhone SDK “another to attempt to trick the market with a disingenuous marketing event,” and “a lie” is a bit too much over the top in hyper-emotional politics to even address.

  8. Dan,

    “Should Apple really convert the iPhone platform into a testing ground for the next Twitter? Does the phrase “security issue” raise any flags? ”

    I am not sure where, for example, implementing twitter on your iPhone would raise security issues.

    “You can’t invent a new communications protocol and roll it out in real time over a mobile device network–without any controls in place–and expect things to work out well.”

    Hmm… Not quite sure where I mentioned anything about communications protocols. But even if they were relevant to my argument, there is no dangerous magic in communications protocols. And in any case the SDK does not prevent creating communications protocols. Its a full C compiler with access to TCP/IP. You can put anything on the wire you want and as far as I can tell, apple could care less.

    “The iPhone isn’t a development lab, it’s a phone. It has to work. It can’t be run down dead because some developer releases what they think would be a good neo-Twitter/IM/VoIP client, and finds mass adoption before realizing they’ve introduced major performance problems or perhaps exposed significant security issues.”

    Dan, this is just technically inaccurate. One of the great things about unix is the ability to control processes. You can control how much CPU they get, how often they can access services, etc. There is absolutely no reason apple could not provide for the ability to run daemons in such a way to limit their resource usage.

    Also you keep referring to security. As far as I can tell there is no security axis here at all. Unix is quite secure. Its been around a few decades now and security has always been at the center of design requirements. Nothing the iPhone is doing should make unix any less secure than it has been for the last 30 years.

    “Look at the security holes that have been discovered in Sun’s Java or QuickTime or IM or HTTP or any other protocol, and you have to second guess the ability of individuals primarily interested in “cool” to recognize every security issue they might raise in building apps on a platform that, unlike the iPhone, has no parapets at all.”

    hmm… again with the security. Background apps have absolutely no correlation to security. And background apps have no correlation to Java, or quicktime. And java is not a protocol. These are completely orthogonal software concepts and services.

    “The second idea of ‘location notification’ sounds great, but how many notifications will your iPhone alert you to before the battery is dead from constantly polling its location? Real satellite GPS draws so much power that it typically needs to be plugged in (or have big batteries). That’s why the iPhone has a click to locate button rather than providing a constant update on your location. The author who wrote up this idea didn’t give this much thought. ”

    Actually, I gave it a lot of thought. And so have lots of other people. Its not exactly a new idea, and it is most certainly not my idea. First of all, the iPhone doesnt have a gps to burn so it would be hard to expend the battery using a service the device doesnt have. What it does have is location based facilities based on wifi and cellular, which are presumably services that can be used without burning out the battery otherwise the iPhone would be pretty useless. In any case, given that apple is smart, it would be trivial to restrict the number of times the daemon could call the location based software services from the background.

    “I followed your link to see other examples he pointed out, only to find that he’s calling the the iPhone SDK “another to attempt to trick the market with a disingenuous marketing event,” and “a lie.” That’s a bit too much over the top in hyper-emotional politics to even address.”

    Actually you misquoted me here, I guess since the actual concept is pretty troubling. Apple showed AIM as a product built with the SDK. You cant build AIM with the SDK since the SDK does not allow for background tasks to handle presence and notification. For apple to present AIM as the type of app that could be built with the SDK was a lie. It was not an emotional statement. I am quite dispassionate about this. I was developing software for Macs starting in 1984. I built a company developing mac software through the mid 90’s. I happen to think the iPhone is great. I have given it great reviews. But the truth is sometimes people do bad things. Sometimes they lie. (like jobs backdating the options). It happens.

    As I see it, you should switch sides and be supportive of the idea that they should fix this. I agree that they should do it in a way that prevents too many resources from being consumed. This is apple and that will not be a problem for them if they decide to do it. They are smart. My fear is that with commentary like yours they will feel comfortable that they can get away with not bothering. That would not be good for any of us.

  9. Background processing will come in time. Give Apple a year or so to see how third party development goes.

    This is exactly the same situations as when iPhone rolled out with no third party support.

    It'll come.

  10. the ipnone IS A DEVELOPMENT LAB for apple. just because people want it to work the way want it to work they work is irrelevant. the fact that you folk are even discussing this is not lost on apple's development folks you know.

  11. the way you want it to work right now..that's that i meant to say...pardon..i'm in europe and the party just started..hee hee hee

  12. Luis Alejandro MasantiMarch 13, 2008 at 10:52 PM

    "You cant build AIM with the SDK since the SDK does not allow for background tasks to handle presence and notification. For apple to present AIM as the type of app that could be built with the SDK was a lie."

    AFAIK, the AIM was built with the SDK's tools (you are correct here) but I could not be sure that this was made under the same legal agreement,
    The "two week test" could be done under a different contract.
    I agree with you that "it is misleading" but how can you be so sure as to say it is a "lie"?

  13. Luis,

    The SDK does not allow a background task or daemon to be created. Therefore since AIM requires this, presenting AIM as something that could be done with the SDK that we all are getting is a lie. To me, a purposeful intent to deceive is a lie. This was clearly purposeful. And it was clearly intended to indicate that "you can do this too."

  14. I don't know why an AIM type app can't be build without background task. I see how it wouldn't be as good but I don't see it as a lie to show that it can be done, just without notification.

  15. This is a great post, I put a link to its from our Product blog at under the 'iphone developer, not!' story.

  16. Hank, you're totally right with your post. I have the feeling that Apple is introducing a 2-class system where there are privileged apps like AIM, their push email, Cisco VPN and stuff like that, that all use background processing. But the average developers have to stick with a very limited functionality.

    Of course I'm pretty much aware of all the resource and security risks, developers must have to face when developing daemon apps. However all this is doable. Apple demonstrates it with its own apps. And hey, if you're misbehaving, Apple can always pull the plug and throw you out of the AppStore, revoke the cert - whatever.

    So I vote against a 2-class system, but for same chances for everybody. I'm totally confident that we'd see amazing apps that really take the platform to a totally new level.

  17. Hank,
    I've got to agree with you here. In principle, at least. Limiting the resources to daemons is easily doable and well-proven. I imagine they will release this functionality at some future date. OTOH, there could be reasons unconsidered that limit the designers from allowing this now. Battery use is difficult in a mobile device and one of the reasons Windows mobile largely blows is their implementation of concurrent proccesses. Thanks for the post!

  18. I'm afraid you're incorrect. You can definitely do 'presence' without background processing. The last user-selected presence change is simply remembered on the server. I don't know if an app can be sent to a shutdown procedure when the iPhone shuts itself down, but if so, the presence can even be set to 'non-present' in an *apparently* background manner which is not actually happening in the background at all.

    As for notification, there you have a much better argument. However, *many* uses of notification can be achieved without background processing, with a sufficiently robust alarm system. However, there is no question that there are also many that can't.

  19. Hank,

    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.

    Thinking that games are the only apps that the iPhone is good for because here is limited background processing access (not directly stated but strongly implied) is, at best, short sighted. I see the vast (by that I mean 99%+) of apps falling into the category of no background processing required. It might make some things a bit easier but that is a different thing than "required."

    I strongly suspect, the SDK will grow and change with Apple increasing access as time goes on. Personally, background processing is not on my list of "required" things and I am not doing games.


  20. LOL what a loser

  21. This is a function of scale.

    Apple simply doesn't have the resources necessary to pore over what will undoubtably be millions of lines of code that are being written right now.

    They do, however, have the resources to work with an extremely select group of partners; eg AOL, Cisco, EA, and other big-pocketed companies.

    But let's assume that you had the ability to launch a background daemon.

    Okay, we'll use your Unix resource limiting argument (which, if you've ever actually worked with ulimit, you would know that this is the dumbest idea ever and is only meant to stop runaway processes -- but I digress).

    You fire off your background task, and you have a limited number of CPU seconds to use. Now, somewhere along the line, that background task will hit that limit, because people have this annoying habit of leaving their phones running 24/7, yeah, shocking, right? So your process hits the CPU seconds limit because it's either using Quartz, or it's doing SQLite work, or it's doing XML parsing, or whatever. When it hits that limit, the process gets terminated.

    So now, you have a defunct background process, and if you're lucky, maybe, just maybe, the iPhone will be nice enough to send you a term signal that causes your background process to throw up a modal dialog that says "oh shit, guess what, we ran out of CPU juice, so we're stopping now".

    Do you realize A) how absolutely stupid that is from a user experience perspective? or B) how maddening it is to have to deal with a background process that you can't rely upon? or C) that any sort of timely work is essentially impossible, given that your background process is guaranteed to be running at nice 19 (because let's face it, nobody puts iTunes in a corner)?

    Apple has to draw the line somewhere. As a Mac developer, you get full blown access to loading frameworks, running background tasks, the whole shebang, because guess what, there is a honking big battery and a CPU that sits mostly idle inside your user's Macbook. That simply isn't the case with the iPhone. Adding resource and process limits isn't enough when thirty apps are all vying for CPU slices.

    Yeah, I'm writing an app, and yeah, it would be a lot cooler if I had the capability to throw a thread in the background and forget about it, but guess what, I'm working around it. I'm implementing the equivalent of an offline queue, and then working on the queue when the app runs.

    And by the way, Twitter _already_ _runs_ on the iPhone, because Twitter sends out notifications via SMS. AIM can work the same way (like it does with a lot of phones). I think there are a lot more options for application development than a lot of these knee-jerk reactions are thinking about.

  22. Hank,

    I asked you: How lonely does it get?
    You haven't answered yet.
    But I hear you coughing in the tower of songs.


  23. Hank,

    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.

    Of course, if you have any good examples, I'd love to hear about them.

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

    I'd be surprised if Apple didn't eventually allow background processes, and I agree that it will be necessary to move the platform forward.

  25. There may be other ways of getting status updates and alerts, without needing to run apps in the background.

    Would it not be better for one main background thread to do all the checking and polling at predefined (and maybe user-controlded) intervals? I'd much rather have a well-implemented pluripotential über daemon, than the inefficiencies of 1,000 developers kluding together their versions.

    I suspect/hope that Apple are working on some kind of unified background notification service ("Core Notification"?). In fact, I shall be submitting a feature request for this...

  26. Luis: ''The "two week test" could be done under a different contract.
    I agree with you that "it is misleading" but how can you be so sure as to say it is a "lie"?''

    So when Apple said "We are releasing the SDK. Here is an example of what can be done (AIM)", it is not a lie? If they had said that AOL had access to a special version of the SDK, then why didn't they say so?

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

    I do get the gist of the argument--that allowing background processes would grant developers greater flexibility and could result in some truly amazing apps. But I don't buy your conclusion at all--it depends on agreement that your assessment of what makes a 3rd party application useful is the one and only definition. And quite frankly, it's not.

  28. "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?

  29. I absolutely agree with this, and am frankly disappointed that Apple seems to have decided that Freedom Zero is not worth considering in the mobile space. How long have developers, in particular, lauded the fact that Apple offered not only the best toolkit, but the most UNIX-like mainstream OS, and made it easy for 3rd-party apps to have the same degree of functionality and polish as Apple's own.

    Now, between the crippled iPhone SDK (and the apparent waiting list/vetting process needed to even get a developer cert) Apple is showing that they basically think that they can do better than the independent developers that have made the Mac their home for so many years and kept it a viable platform.

    iPhone apps written with the current SDK will be pretty, but shallow.

    For those who think that resource limits on background processes are so tough: what exactly is different about foreground processes, then? It would be easy enough for a graphical app with focus to peg the CPU and GPU for several minutes, and cost you a huge chunk of battery and/or bandwidth; where, then, is the outcry about how developers can't be trusted with such precious resources, and even foreground apps should be severely constrained?

    Once you start down the path of declaring 3rd-party apps to be "second-class citizens," you enter a world no different from Microsoft's.

    Personally, while I love Apple's hardware, I will not spend one damn cent in the future to support their DRM-laden software stack. After 15 years buying Macs, my current Apple machine will sadly be my last, unless they cease treating their users and developers like precocious children.

  30. I think there is more to the iPhone than the animated and shrink UI features you mention. 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. We want it simply to work without having to trouble shoot which of the new apps are suddenly draining all the resources from our device.

  31. It's not generally constructive to look back, especially in anger, but from the history of self-serving and mercenary treachery of the developer community towards a company and hardware platform that arguably gave them their first meaningful opportunities to cut their teeth on truly groundbreaking usability applications, if I put myself in Apple's place for a mere instant I would swear an oath never to concede even an inch of control in software development outside of Cupertino.

    To those come-lately developers who were probably still sloshing around merrily in their fathers gonads when the events I allude to were going down, I will not even bother to expatiate on this history other than to tell them to go read it up and wise up ( is a good port of call to get the "big picture").

    Those that fail to heed the lessons of history (including Apple Inc) are doomed to repeat it endlessly. Apple would be twice damned if they allowed the ignoble events of the 80s and 90s to pan out again by losing sight of the big picture and getting lost in less significant detail of the wants and desires of individuals and a knowledgeable but philistine minority rather than the needs of the whole and the "greater good".

  32. anonymous hit the nail on the head with the AIM demo. There was nothing in the demo to indicate that they were using background processing, because they never exited the program to show you what would happen. It's entirely possible that the AIM client that AOL created in that two weeks required you to be in the app to receive messages and be online.

    The thing is though, minor changes to the AIM protocol could even allow for more. Because the iPhone has no concept of multitasking except in a few rare cases (phone, iPod, iCal), there's no concept of being "inactive" in a chat. In the iPhone, the only concepts available to the user are active or offline. So if AOL changed the protocol so that you could send messages to offline contacts (which you may actually be able to do already), then the AIM client would just need to fetch and display all the messages when it starts up. The user wouldn't care whether or not they were booted offline or not.

    The author here is thinking in desktop UI terms, which are not applicable to the iPhone UI. There's only one possible app that can be onscreen at anytime, so whether or not the user goes offline when the app is quit is irrelevant. The user won't know any difference.

    Bottom line is, background processing is completely unnecessary for an AIM client.

  33. Where and when did someone say AIM was running in the background at the SDK rollout?

    What AIM showed is what they were capable of building in two weeks with the SDK they had. No where did they say they built a complete application, nor did they say that it's running in the background.

    You may find an AIM application that only runs when it's in the foreground useless, but that is a separate issue from whether the SDK launch was a "lie" because AIM is doing something no one else is doing.

    What basis to suggest the launch was a lie?

  34. Thanks for all of your comments. While I cannot respond to all of your comments, I have responded to some of them in my summary post here.

  35. What interests me about the lack of support for background routines is how it affects systems that want to push information to applications on the iPhone.

    During the SDK launch, Chuck Dietrich from talked about the ability of his sample app. to use's "advanced workflow triggers" to push new information down to the iPhone. He even showed an example of more information arriving during the demo.

    BUT this information arrived while the application was OPEN in the iPhone. In other words, it wasn't so much a "push" as a "pull" by the running application.

    If the SDK doesn't support background threads how can applications like really work? How can the iPhone alert the user when new information is available from an external site unless the user keeps opening the specific application at regular intervals to check?

    Surely this impacts the potential of the iPhone to support a whole class of applications that monitor external events in some way - e.g. RSS feed readers, SNMP clients, etc. ??

  36. „Background Processing is the Key to Mobile Innovation“
    I just don’t get it. What’s the big deal about this? Programers don’t want to escape the paradigm paralysis and businessmen want to quench out the last cent in my pocket. Location based services which bombards me while I’m in a mall with the latest discounts and other needless information (for the customers because discounts are only used to get the consumer spend more money [mostly for things he also doesn’t even need]).
    The smarter way would be to offer the consumers a convenient way to browse the catalogue (with the discounts) on demand while standing in front or near the shop. You get the idea, we have this already THE INTERNET, so only the convenient way has to be solved.

    Another always mentioned case: I want to be notified if any of my friends or contacts in my address book are nearby. Ridiculous to implement this as an always polling service. If I want to know it I push a button and then get the info. The carrier already knows where I am, it is necessary to receive calls.
    Hell, why do I want to get everything in every situation at once? If I’m in need for a particular info then it is at a fingertip and not besides hundreds of other useless information.

    The argument for an IM app that it’s desperately in need for running a background processes is stupid, or more gently not well thought out. As some already mentioned it in comments before mine. You can read a more detailed description in solving this at this post (iPhone creativity – Third party background processes)

    Finally, I think the main problem is the paradigm paralysis. It has to be the old way or it won’t work. The old way was to squander CPU cycles and other resources; code inefficiently. Think about that.

  37. I have a touch and I am a gamer. Done be so hard on apple maybe after they see how AIM does with background and pressence then they will give more developers this freedom. Besides they never. Are too risky these days. They like to test the waters first. Pluss for games I don't care. And they have mail for the background and they have alarms and stopwatches and u can listen to music/control ur music while on safari

  38. Having worked in the mobile industry for nearly a decade, the app review and no-background tasks was almost certainly a demand of the carrier. Historically the carriers have been tyrants that aggressively defend their networks, so it's amazing that Apple got as many concessions as it has. I'm sure a large part of the app review process is a carrier blessing.

    Regarding resource control. Have you ever used rlimits? They are practically useless except for memory limitations. A "nice" setting of 20 would be somewhat useful for scheduling, but would not stop a process from dragging down the whole phone's performance.

    This belief of unix as having perfect security is bunk. Security is only as good as the weakest link. A single buffer overflow in an app could allow a hijacking of the iPhone. Now your phone becomes a mass emailing/sms zombie.

    Perhaps a buggy application starts blasting the network. A popular and buggy app running 24/7 would effectively take the EDGE network down. That would elicit a terrible blacklash from the carrier.

    Granted, all of these problems are issues for a foreground application as well. The difference is that the bad behavior stops when the user chooses to exit the application! Again, the scope of the damage is decreased from 24/7 to some short interval of time.

    Allowing all of these potential issues in the background opens a technical support nightmare for Apple. All of the iPhone owners are not uber-techies. They will blame Apple, not the invisible background task, when the phone performs poorly.

    One can make the red herring argument that all of these issues are problems for the desktop as well. That's true, but I don't want to play sysadmin with my phone!! Damnit, I want my phone to "just work".

    Apple knows that the limitation is vastly unpopular. It's a tough problem that needs a well thought out solution. Let Apple figure out how to create a global background daemon allows applications to register for notifications. I'd be surprised if they aren't already working on the problem.

  39. For the record, Twinkle, a jailbroken app on the iPhone and iPod touch, works perfectly with no worries about "communication protocol" issues (OMG, HTTP! ONOES!). It is even location-aware and can take photographs.

  40. Hi Hank,

    I am extremely interested to hear your thoughts on this topic now that Apple has made an announcement about the notification piece in today's WWDC keynote.

  41. Hank makes some cogent points (and it is mindless to criticize those points simply because he isn't doing development on the phone; e.g. somebody familiar with electricity doesn't need to touch two terminals with a 2,000 volt/high amperage potential to understand that it would be a Bad Thing to do.)

    Here are some additional ideas that would solve this supposed huge problem without crippling the phone's battery power etc.:

    1) Let the *user* decide to permit background processing to occur, either globally or on a task-specific basis. This could be in an "Advanced" setting. The default would be "no", and the program would tell the user it needs that capability when trying to run it, if disabled, then let the user decide at that point (if yes, enable it for him.)

    2) Allocate an OS enforced budget for background processing that must be shared among all background processing tasks and let it be user controlled, defaulted at say 5% (of time-slice, of battery consumption rate, etc.) and maxed at some low number. And when they pick it, make sure to do a realtime calculation estimating battery life effects.

    3) Rather than emulating Microsoft's stupid task manager, have a nice GUI app that lets the user rapidly see which applications have consumed the most battery power - and that should be possible at the O.S. level, right? Like highlighting power hogs by coloring the application icon a shade of red, the more power, the redder it gets.

    4) Let the *user* explicitly decide to pre-allocate the maximum level of resources (% time-slice, rate of battery consumption. etc.) a particular background-taskable program can use.

    5) Make it easy to kill all background processing programs.

    So rather than sneering at users for being too stupid to figure any of this out, focus on making it easy for them to handle the supposed problems while permitting the possibilities of realtime background programs.

  42. I have a much simpler reason for Apple's omission of notifications- $M$.
    SMS is a cash cow. The iPhone is an incredible dichotomy of cheap massive 3G connectivity (3G) and incredibly expensive and limited communication (SMS).
    There is no technical reason behind this. There is one very big business reason behind the lobotomizing of the iPhone SDK.

  43. i agree with the author! there is no innovation without is too bossy.every apple fanboy is defending steve jobs!its just a company for godssake,you spend the cash for the iphone so demand more !i have one and i want more functional apps so should you.if u are concerned about background apps running down batteries dont use.people like me we would use them.

  44. Great Post hank. Yes, totally agree. i am in the process of downloading the SDK. We have built applications for Symbion and Microsoft phones, however, we are keen to delve into the IPhone space. Unfortunately, if it is as you say, not much point.

    Great article,

    Stephen Morton

  45. Your overlooking one very important issue. If apple allowed background processes, the developers would take full advantage of this, and not all developers realize their impact. If everyone took advantage of background tasks then the battery of the phone would be almost useless.

    The goal is to have a phone that functions as it should and allow developers to take advantage of the platform without taking away from the core phone.

  46. I think Apple used the battery thing as an excuse for not allowing background programs to run. When the iPhone runs out of RAM, the phon...eerrr...toy resets. So allowing only one program to run is a patch job to reduce the chance of this happening.

  47. Hank, thanks so much for posting this. I've had the same thoughts but you put it so eloquently. The battery issue is complete BS. It could be handled, as many posters have's a complete red herring. I think the posts about $M$ (SMS) cash cow, and carrier protecting are the real issue.

    Anyone who thinks that the programs you would create with backgrounding are not important...I'm sorry but that's like having a phone that doesn't ring, that you can only call out on. I know most of you can't think of what doesn't exist because it does take some programming background and some innovative vision, but think of that analogy a phone that I can only use to call out on!

    Anti competitive, innovation stiffling telco behaviour.

    I rent a mobile device, but its functionality is severely limited by the network carrier because they don't allow outside parties to message the device. Sure we can send an SMS to a device, but what I want is to be able to send a message to a device that wakes up an application and then that device application does something.

    We already can initiate network connections from our device to any internet service via our data plans. But these are one way data plans. Mobile devices can recieve messages, they already listen for phone calls and sms's, so thats not the limitation. We want all of our devices to be able to listen for messages as well as be able to send messages.

    If this were the case we would see an explosion of super useful applications and users mobile devices would become so much more than a phone. Can you imagine if you could only make phone calls on a mobile device but couldn't receive them? No one would buy a phone in that case! The same applies to generic data messaging for software. If you can allow software to communicate freely back and forth, it is like moving from the age of a word processor to email. I can't believe how frustrated I am by this crippling. Its even more frustrating to read peoples posts about how this isn't important.

    If Apple were able to do this, or if any device can do this, they would create an amazing eco-system. iPhone is in the stage of before the internet. Remember word perfect when it was text only...great for getting essays done, but I can't imagine what life would be like without the net. The net would not exist if it didn't allow servers to listen for connections. No email, no Web, no nothing!

  48. Hank,

    No one has mentioned the one thing that I would worry about, as a user of the iPhone, if Apple were to allow spawning of background processes, Viruses. I’d hate to have my phone dial some bastard’s 900 number a thousand times because I loaded a cool looking game, visited some website, or got too close to an evil WiFi or Bluetooth device.

    I’d also hate to have to have to buy and maintain a virus protection on my phone.

    Limiting the ability of a program to spawn background processes and controlling the distribution of software for the iPhone helps to protect Apple’s users (including me) from potentially costly viruses.

  49. great post,

    summarizes my opinion of apple and jobs in an article.

  50. Hi Hank, I'm not a tech guy, but a marketing type guy... though I'm researching SDK a little to help my tech guy in a project we're working on. I just want to say that this article is really, really good. Not only for it's content but for the ensuing discussion it inspired.

    I can understand it and it's all very interesting... plus it gives me ideas. You see, I didn't know about "background processing" or that it was an issue or that it was "in or out"... but now that I know gents like you are railing for it and that it is a very real possibility in the future, I can have ideas developed and ready to hit the road when background processing becomes available.

    Thanks so much,
    Sam Freedom

  51. The article is good,Apple has to draw the line somewhere. As a Mac developer, you get full blown access to loading frameworks, running background tasks, the whole shebang, because guess what, there is a honking big battery and a CPU that sits mostly idle inside your user's Macbook. That simply isn't the case with the iPhone. Adding resource and process limits isn't enough when thirty apps are all vying for CPU slices.
    you can get more feedback from this

  52. I agree to everything in the Blog. I was warned before about the iPhone. Still stupid enough I bought one.

    While I like the look and feel, I see a lot of
    disadvantages compared to other mobiles.

    Specially Apples behavior (reminds me at Sony) in terms of the SDK sucks.

    They make many things wrong but don't let other fix em :D

    Fair enough; they have lots of Apple Fanboys supporting them in what they do (for for me unknown reasons).

    I want an SDK and policy not preventing 3rd apps to give me (a paying customer) a functioning GPS, not preventing 3rd apps from extending the stupid calendar with more alarms, etc... etc...

    As soon as there is an alternative out (touchscreen with abilities and size of the iphone) with windows mobile.

    I am gone and never look back!

  53. Hi Hank,

    After a year or two of post and counter-post, and seeing Apple's App Store go from strength to strength, this issue of backgrounding apps versus notifications has been overtaken by several events which should possibly modify our arguments.

    Sadly, I see no acceptance of this in the rhetoric here, only the same old emotive stances.

    Now that the iPhone 3G packs GPS, and the average user has several pages of applications all vying for CPU time, is the battery issue really a red herring, given the chip capacity?

    Jail-breaking software (which allows background apps)is now a byword, and has had several iterations of upgrades. Surely many commenting developers here (yourself included, possibly?) have had the chance to evaluate the impact of backgrounding and the applicability of notifications as an alternative by switching back and forth from jail-broken to official software and testing applications' general performance.

    What are your thoughts now?

    My brief personal experience of jail-breaking the iPhone seems to justify the contention that inelegant clutter, reduced stability and security, memory lockups and reduced battery life go hand-in-hand with backgrounding.

    Given Apple's well-known product philosophy of elegance, simplicity and fun, and what is known now about the capabilities of the current iPhone/Touch platform, does the conspiracy theory of fascistic control and damned lies still stand or not?

  54. Great Information and post! It is very informative and suggestible for the user of solar energy, May I think it can be beneficial in coming days...

    iPhone Application Developers


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