The iPhone Has Blinders On
I bow to my esteemed colleague Craig Hockenberry’s greater experience in iPhone development; but I must disagree with his take on the infeasibility of background applications. He gives two reasons why networked apps shouldn’t run in the background — one technical and one user-interface.
Battery life.
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. *
My immediate response is that, yes, polling is inefficient. Everybody knows this; but it’s also easy to implement, which is why way too many protocols use it. Normally the problems with polling first manifest as scalability problems on the server (as Twitter quickly discovered), but in the case of mobile devices, polling kills battery life.
So it’s a good thing that none of the real instant-messaging services poll. AIM, Jabber, MSN, Yahoo and ICQ all open a socket at login and leave it open, sending data only when necessary. If you suppress buddy-list updates while the app isn’t active, then data only needs to be sent when you send or receive an IM.
The remaining issue is one I don’t have the technical knowledge to answer: how much less power does it take to leave the EDGE radio passively listening for packets, as opposed to sending them? (Anyone who knows, please comment.)
One possibility is that it’s the same standby state the radio is already in (since obviously it has to be listening for incoming cellphone calls and SMS messages), so it incurs no extra battery drain. That would make non-polling background network services like IM clients totally feasible.
The other possibility, though, is that even listening for EDGE IP packets uses a lot of power. Which would be bad news, as it makes any background notifications other than phone calls and SMS impractical. But I don’t really believe this is the case — because if it were, how would the iPhone’s upcoming “push email” support for Microsoft Exchange work?
(Moreover, I have to point out that my prior cellphone, the T-Mobile Sidekick, had excellent AIM support, as well as push email, from day one, so it clearly is possible. The Sidekick’s battery life was decent, with maybe 3/4 the standby time of my iPhone.)
User-interface clutter.
From Craig’s second post:
You now have five independent sources for notifications. How do you let the user know which one is which? One might say, “make the sound different.” Another might say, “make something flash in the status bar.” Someone else might say, “make the phone vibrate.” Or even, “put up an alert box.” A truly sick individual might say, “Do all four.”
Can you see where I’m going with this? Your phone soon becomes a fricken’ pinball machine as multiple applications fight for your attention. With 24 notification permutations for every application, things will quickly get out of hand. *
I don’t buy this at all. In fact, I think it’s paternalistic. Yes, user interface design has to consider unintended consequences of users’ own actions, but this is a situation where the consequences are entirely obvious to the user: the more notifications you turn on, the more distractions you’ll get. The remedy is just as obvious: if you end up with too many distractions, you turn some of them down or off by using the exact same steps you used to turn them on in the first place.
I don’t mean to put words in Craig’s mouth, but I think that between the lines, that quote says: “You’d be able to turn on so many notifications that I would find it intolerable.” He’s dismissing a huge swath of functionality because it could be overused in ways that he personally would not want on his phone. That’s not a valid argument.
[It is, however, the kind of thing that’s already gone on with Apple’s own iPhone apps. My pet peeve is that the calendar’s alarm cannot be customized. It’s hardwired to emit two pathetic little bleeps, and that’s all, whereas phone ringtones are customizable and repeat. Clearly this was designed by and for people who have no problem remembering to attend meetings, and never procrastinate appointments, but will drop everything to answer the phone. Unfortunately I am completely the other way around, and I’m sure I’m not the only one.]
There’s also considerable irony here, in the fact that Craig’s best-known application is a client for Twitter, the service that is today’s poster child for “constant annoying notifications”. Clearly, then, he finds Twitter’s level of intrusiveness tolerable, whereas I generally don’t (I have an account but almost never use it.) On the other hand, I do find instant messaging invaluable, and mourn the loss of the mobile AIM presence I used to have on my Sidekick. Not that I got a lot of IMs while away from the computer; but the ones I did get, or sent, were often important to me. Chacun a son gout.
Gloomy conclusions.
I’ll end this with two spot-on quotes. First, from developer Hank Williams:
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.
And c|net’s Tom Krazit’s response:
That makes sense; remember that friend or relative who got a mobile phone but never turned it on? That practice greatly diminishes (although some might say it enhances) the value of a mobile communications device, and one-way communication is not what has made the Web so interesting in its second decade.
Bingo. I’ve been obsessed with what we now call “social software” for over a decade; and the iPhone SDK doesn’t give us the full functionality we need to do this kind of stuff. Basically, the iPhone has blinders on, like a cart-horse: if it’s not already looking at you (in your online manifestation) it can’t see you, and you can’t get its attention. That’s great for a cart-horse, but it’s death for any kind of social interaction.
As I said above, I am aware of the technical issues (and would like to understand the details better). There may need to be work done to allow multiple applications to receive background notifications, in a practical manner. For all we know, Apple may already be working on this. But of course we have no way of knowing, because, in typical Apple fashion, they will absolutely refuse to admit the existence of the problem, much less any efforts to work around it, until they have a complete solution to spring on us. Unless of course they just don’t care; entirely likely, since quite a lot of people upstairs at Apple don’t seem to ‘get’ social software at all. We just have no way of knowing…
March 21st, 2008 at 8:11 PM
Joe Realist -
I’m not saying anything bad about MobileScrobbler, and, like you, I would very much like to see Apple drop the “nanny-like attitude” and allow background processing, but it’s not as simple as saying “here’s one app that did it and it worked great, so Apple’s stupid for not allowing it everybody unfettered access to use background processing and deliver apps through the App store”. I’m sure the reasons underlying Apple’s decision are legion.. I may not like the decision and might not agree with it even if I did know all the facts, but pointing to one well-written application and saying Apple’s wrong because of that app’s very existence is simplifying the case a little more than I’m comfortable with.
March 21st, 2008 at 9:13 PM
“MobileScrobbler not only runs in the background and interacts gracefully with the iPod software without affecting battery life”
On the contrary, I have found that MobileScrobbler kills my iPod’s battery life. I was very disappointed to discover that it keeps the wi-fi connection alive while the device is locked and listening to music, sending updates after each track finishes. I now have to actively turn off wi-fi in order to force MobileScrobbler to the only sensible thing, which is to send batch updates when the user wakes the device.
Cocoa is both the iPhone’s biggest asset and its worst enemy. It’s too easy for a developer to move their code from Desktop Cocoa to Mobile Cocoa as directly as possible without much consideration for the fact that it’s running on a very bandwidth/CPU/battery constrained device. MobileScrobbler is a perfect example of this. Sure, it won’t update over EDGE, but its background wi-fi network usage is very wasteful and just plain unacceptable. Is this the kind of wasteful behavior we can expect from iPhone applications? Well, if they can’t run in the background then maybe not.
But the bottom line is that the iPhone UI doesn’t allow the user to task switch or to explicitly quit applications; therefore, no background apps. There are advantages and disadvantages to this kind of design. Personally, I would rather have the ability to control which apps run and which don’t. and task switch between the ones I do want to run.
March 21st, 2008 at 10:27 PM
I’m kind of surprised that no-one assumes that the lack of background processing is of the same reasoning that the original Mac didn’t have a text mode (or at least the reason I imagine the original Mac didn’t have a text mode!): Most programs that would use it don’t actually need it, and the overall user experience is improved if that majority of programs are “forced” to do the right thing (even if it’s harder for the developers at the outset).
Personally, I think that folks are way too uptight about this: Apple surely has a plan. I believe the no-background-applications line about as readily as I believed the ajax-as-sdk line from last year.
My best guess (hope?) is that they’ll allow background processes which don’t have any UI (and potentially severe limits on memory lest they be shut down). I assume that the standard IPC tricks work in the iPhone OS?
March 21st, 2008 at 11:29 PM
Having taught mobile development for several years, I have mixed reactions to “background processing”. On one hand, power consumption scales linearly with the CPU clock speed, so revving up the processor to do any computations is going to cost you battery life. (Now add frequent sound and/or the vibrating phone notifications and there goes your battery!) On the other hand, if apps could register for async notifications (perhaps via a managed polling service), it would make sense to let them register a stub.
I hope this limitation is one of those “we can fix it in rev 1.1” kind of issues.
March 22nd, 2008 at 9:15 AM
The reasons he states for the lack of background apps are silly. My Nokia E51 has WiFi/3.5G connectivity and the same 128 MB of RAM the iPhone does, yet manages to run multiple background apps (music player, web browser, combo IM/VoIP client, and games) for days at a time without charging the battery, all on a 396 Mhz ARM11 processor. If it can be done right on Symbian, surely Apple can do it on the iPhone, if not better! What happened to ‘Think Different’?
March 22nd, 2008 at 2:47 PM
Darren:
Thank you for the constructive feedback about MobileScrobbler. The next update will include a preference toggle to queue your tracks instead of transmitting them while the device is asleep. Feel free to suggest future improvements through the bug tracker on the MobileScrobbler website.
Thanks!
March 23rd, 2008 at 5:01 PM
“SMS -> URL -> App would be a good way to do push?”
Possibly a Apple owned background process could handle the url handler ( sent as an SMS?) and launch the app via the url handler. Given the LaunchMe sample code might well be a possibility :-) Not sure how this helps mobilrscrobbler but it could help those of us who want our own “push” technology.
March 23rd, 2008 at 7:04 PM
Exactly! I replaced Twitterific with Twhirl as my desktop twitter app because Twitterific was so frickin annoying and gives you no chance to scale down the incoming tweets. With Twhirl, it only displays a couple at my designated interval. Facebook Apps have shown that widget (mini-program) authors cannot be trusted with the power of alerting the user to whatever activity whenever they wish.
March 23rd, 2008 at 8:16 PM
For those of you who don’t have mobile hardware experience.
Poling can actually be lower battery suck than direct connect TCP sockets.
The way the GSM and CDMA radio works is that it tries to keep the best possible connection open between the phone and the nearest cell. In a heavy populated are like a city this is usually not a problem since you have five bars every where.
But this also means that there is ALLOT of hardware layer (OSI 1-3) data passing going on to establish the best connection between the numerous cells in view, continuously monitor the signal strengths (typically 4 or more), and worry about handover to the next tower if you are moving.
That’s allot of juice.
Additionally, keeping a TCP connection open but sending nothing guarantees the conncetion will be terminated by the carrier. Carriers are motivated to keep the scarce GPRS resources open, so they typically implement a 3-10 minute ‘kill’ window. No data passes in that time and it kills the connection. SO_KEEPALIVEs are ignored as are ICMP packets. (and you thought Comcast traffic shaping sucked). So if you use an always-on connection you have to build in your own ‘keep-alive’ packets at the application layer (OSI 6-7) instead of relying on TCP frames, OOB frames, or ICMP ethernet frames to do the work for you.
The final ‘screw you’ from the phone battery is that if have even 1 bar missing (80%) signal strength, the battery is dumping all it’s power into the radio to try to boost the signal strength. The power valve between the battery and the radio is variable and can set to low (sitting next to a cell gettin’ sterilized) or supper high (left on in the overhead on the plane).
The debate between polling and always-connected on cell phones (any cell phone) is somewhat moot. because of the pretty even trade offs in power management, it turns out that a well designed application and protocol makes MUCH more of a difference than the hardware and TCP/IP stack implementations, regardless of the network connection models.
It is a rare think these days when the application developers hold all the cards when it comes to usabillity and performance. It also means you get blamed for everything :)
-C
March 23rd, 2008 at 8:55 PM
Does anyone know how Google Android is going to handle this issues? It could be interesting to see how they are handling polling and multitasking.
March 25th, 2008 at 1:56 PM
@Paul Handly: nope, you’re thinking of the old version of Exchange ActiveSync. The current version uses, essentially, an open GET, as does the UC AJAX SDK that could be used to implement an OCS 2007 client on the iPhone.
More broadly. as I argued a couple of days after Craig’s original post, both of the problems he cites are not only solvable, but largely solved in the current incarnation of mobile apps for Windows Mobile.
May 23rd, 2008 at 2:26 AM
I’ve been thinking about this too since the launch of the SDK, and your post inspired me to share:
http://l8rs.blogspot.com/2008/05/iphone-20-sdk-limitations.html
Apple will need to address this or be surpassed by Android which surely will.
Regarding your power question, yes an open TCP/IP socket simply listening over EDGE drains about 10x power over the regular check in for SMS or voice call. This may change in future physical layers, but with standard GSM chipsets that is what we see on our scopes.