On Apple, The SDK, and Backgrounding

by Eric March on March 18, 2008 at 7:46 pm

Twitterific author Craig Hockenberry is just another dude who’s gotten his mitts into the iPhone SDK, but he’s got a few things to say about the big question of running background tasks on the iPhone — what he calls a “healthy dose of reality.”

Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh.”

The heart of the problem are the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements. Whenever that hardware is on, your battery life is going to suck. My 5 minute refresh kept the hardware on and used up a lot of precious power.

You can read his whole blog post here.

Now, I certainly agree with him to an extent. Mobile devices have a finite amount of juice, and the more you ask that device to do while it’s tucked away in your pocket, purse or briefcase, and not in active use, the more it’s going to drain your battery. That much is a given. Nevertheless, I can’t help but think that, whether consciously or not, there’s just a little bit of Apple apologism going on here, and I’ll tell you why.

To begin with, mobile development is nothing new. It has had well over a decade to mature and become an industry in its own right, starting with Palm, and then expanding to Windows CE/Mobile, Symbian, Java, and now iPhone and Android. Let me be clear here: Developers have had a lot of time to figure out that developing for a mobile platform is different than developing for a desktop platform. You are dealing with limited system resources, smaller screens, more limited input methods, less powerful hardware, and a battery of very finite capacity, and all of this must be kept at the forefront of a developer’s mindset when tackling any given project aimed at a mobile platform.
Any developer worth his salt knows this. On any platform that a developer is approaching for the first time, there is always the initial period of exploring boundaries, of course; any developer worth his salt would see how far they can push the envelope, too. It’s just part of the natural process of discovering what can and cannot reasonably be done. This is no different with the iPhone, and many developers are now discovering these boundaries.

Many of the boundaries are hardware limitations. Some of them though are arbitrarily enforced by Apple, and to my surprise, there are some developers who are okay with that — even taking the tack that Apple knows what they’re doing and were right to do it. I will not question that Apple knows what they are doing; they are very shrewd and they’ve pretty much nailed marketing and industrial design. But were they right to do it?

Mobile development is nothing new. I feel like I need to repeat this because Apple seems to be approaching developers as if it is, and they invented it. For some things, the restrictions make sense; sandboxing apps does provide a much more secure and stable environment for them to work within, even at the expense of some liberty. It’s kind of like the TSA of the application development world; nobody likes it, it’s an inconvenient pain in the tuchus, but it’s a necessary measure to ensure the safety of all, and while we could do without it, we would do so at our own peril and open ourselves to risks from viruses, trojans, and ~~rogue airliners~~ other nasty malware.

For other things though, Apple is acting like a parent looking after a child who hasn’t yet been able to pair actions with their consequences by restricting their freedom and telling them what they can and cannot do even when the only reason not to do it is because the child may hurt itself or inconvenience others if it isn’t careful. Apple is making the assumption that all developers are going to try and approach iPhone from the mindset of a desktop developer, and as such will try and develop iPhone applications in the same way. To head that off, they are forcing all developers — even those who know better — down one single path that won’t let them develop iPhone apps from a desktop perspective.

For something like allowing applications to run in the background — to whatever extent they need — this strikes me as arrogant and condescending. To begin with, developers aren’t idiots. If a developer writes an application designed to run in the background, they’re going to monitor the effect it has on system performance and battery life as part of routine testing. If the developer finds any aspect of its functionality unacceptable, it will go back for further refinement until such time as the developer is happy with the results. If the end-users who use the application aren’t happy with the results, they will either stop using it (or not get it in the first place if they get word that it isn’t very good) and/or they’ll talk to the developers and complain of its issues.

Unsurprisingly, this is how software development works pretty much everywhere, and how it has worked since mankind was first able to grasp a joystick. Mobile software development has, since its inception, been even more stringent in its development cycle because there are more and different concerns that developers must be aware of and factor into their application designs. Palm, Windows Mobile, Java, Symbian — heck, even proprietary dumbphone software has all been developed with these considerations in mind. The idea that the iPhone is any different, and therefore must be regulated differently, is absurd, as is the idea that developers who want to climb on board the SDK wagon are going to approach their design from a desktop perspective just because it’s an Apple product.

That isn’t to say that all developers are going to observe the difference; I’m sure there will be some new developers who have never done mobile development before who will end up writing applications in a manner designed for desktop use but shoehorned into a mobile framework. But so what? It shouldn’t take them long to figure out that it doesn’t work that way, and even if they end up releasing product built on that foundation, the public aren’t going to like it very much due to its unreasonable demands on the system and they’re not going to use it. That in itself, even beyond letters of complaint, will tell the developers that they’re doing it wrong and need to rethink their design strategy.

Smart developers should be able to scale their background applications to a mobile footprint such that they do not require much processor time and do not access the network (be it WiFi or EDGE) any more than necessary — ideally, at a user-defined interval so the user can decide how much battery they want to eat.

Thus we come to the user. Apple is also concerned that if the user installs too many applications that run in the background, then their overall iPhone experience will become degraded and the user won’t be happy with the way things are running, to say nothing of whether one app will conflict with another and cause issues. Yes, this is indeed a valid concern — as it is with desktop computers, and even other mobile devices. But is Darwin so fragile that it will crumble at the first hint of conflicting daemons? No, I don’t think it is. Darwin is, at its core, OS X, which at its own core, is BSD. While that doesn’t make it impervious to crashing, it does make it pretty robust. And if the user is experiencing performance and longevity issues because they have a lot of background apps running? Well, that’s the user’s own fault, isn’t it? Don’t run so much at once and you won’t have a problem. Otherwise, deal with it.

Furthermore, is Apple worried that the user is going to blame the iPhone for not being able to run two dozen background apps without any performance degradation? Maybe, but they’d be morons; scaled up, they’d have the same issues on a desktop computer — and I am inclined to believe that all but the most “special” of end users would probably realize this on some level.

Apple is playing the helicopter parent to what it perceives to be a bunch if potentially unruly and incautious children who need to be strictly ruled in order to prevent them from getting into any trouble — or getting anyone else into trouble. Restricting developers to some certain degree is sensible if they want to provide a safe environment that is proof against malware. However, the degree to which they place their restrictions, going as far as to force certain design choices on developers, and by extension their users, is taking things too far. While there are valid arguments against the idea of background applications, they are weak at best, apologetic as worst. Apple really ought to just let developers and users alike skin their knees like all the other kids and call it a learning experience. That’s part of a new platform’s maturation process, and at least developers and users alike will know to avoid doing it in the future, and we will all benefit from an overall richer experience as a result.

If you enjoyed this story, join the growing number of subscribers to our RSS Feed for live updates!