Craig Hockenberry on iPhone SDK and backgrounding
Craig Hockenberry is the man, the myth, and the legend behind the absolute best Twitter application on the Mac (he works for the Iconfactory). We would all love to see Twitterrific on the iPhone, but Craig offers up a "healthy dose of reality" regarding the iPhone SDK and backgrounding services (applications that run in the background even though the phone is running a different foreground app).In a recent blog post, Craig attempts to explain why Apple will not be giving developers access to backgrounding services on the iPhone. He points out that in a mockup design of "Mobile Twitterrific," based on the jailbreak/community toolchain, refreshing the XML data from Twitter every 5 minutes led to a dead iPhone battery in only 4 hours.
"The heart of the problem [is] the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements," he says. "Whenever that hardware is on, your battery life is going to suck."
He also reiterated what Apple said about the "Core Location" feature that Apple provided in the SDK: use it only on an "as-needed" basis. Craig said that the issue of backgrounding services may get addressed later on, but right now Apple is preventing iPhone developers from "shooting themselves in the foot." He said that it will take months before the desktop developers have gotten the mindset of an iPhone developer, and that thinking like a desktop developer will lead to bad designs.
![TUAW [Cafepress]](http://www.blogsmithmedia.com/www.tuaw.com/media/tuaw-cafepress-promo.png)
Reader Comments (Page 1 of 2)
Galley said 8:35AM on 3-17-2008
That sounds like a reasonable explanation.
Reply
mk said 8:49AM on 3-17-2008
Still, it makes IM and VoIP applications pointless.
Why not just show a message to the user asking whether to allow this app to background or not, warning him about the implications on battery life?
(Also, why not allow the installation of unsigned apps after displaying a warning dialog that this app is potentially dangerous?)
Reply
DJCarbon43 said 12:08PM on 3-17-2008
Because Apple != Microsoft
^_^
starkruzr said 4:20PM on 3-17-2008
That was not a reason. It was an observation.
S. Jenkins said 8:44AM on 3-17-2008
And the reason why they demonstrated AIM at the SDK special event was because...?
Reply
Chris Coleman said 8:48AM on 3-17-2008
I think they're going to have to rethink AIM just a little bit. Offline messaging can fix that right away. If you remember ICQ back in the day, you could send messages to people who were offline and they'd get them when they signed in. I think AIM will have to adopt this method.
ramond said 8:43AM on 3-17-2008
Sounds like it might have been badly designed. By using the power management APIs you can wake up the phone at specific times to do a task and then sleep again. I figured out thats how Mail works and I copied that technique for my application. Anyway the result is you can run an app for a few days waking it up every 5 minutes.
Reply
ramond said 8:45AM on 3-17-2008
Also try Navizon, it uploads your location to the buddy tracking service every 15minutes and has no obvious effect on battery life. It also is using the wake up technique.
Poon Tangy said 8:45AM on 3-17-2008
Delicious Library, Twitterific ... do you TUAW folks have any actually useful software on your Macs?
Reply
bravedeer said 8:50AM on 3-17-2008
A solution to the problem is to let the third party apps run in the backgrond as long as the user is using the phone. The moment it's locked, the application is suspended. That would let us IM while using other applications.
Reply
Christian A. Strømmen said 9:18AM on 3-17-2008
I don't know what his application is doing, but I'm currently running both a RSS app and Apollo (AIM and MSN) on my iPhone right now, and have for months, and I don't have a problem with battery life at all. These applications are running all day long.
Reply
orntwo said 9:25AM on 3-17-2008
The power management argument is fairly weak when you compare the iPhone to other devices... I used instant messaging and left it on (along with Skype) all the time on my blackberry (with Bluetooth, WIFI & EDGE always on), there was no noticeable change in battery life when I began doing this.
Battery life does seem terrible compared to the blackberry, but I also find myself on the internet much more than with the blackberry. I suspect the difference is a more power-hungry processor and a power draining (albeit nicer) screen, I seriously doubt that the iPhone radios use anymore power than my blackberry radios did. In fact, I find it a rather odd argument from a professional, especially given the wide array of phones that run three radios all the time with these kinds of applications.
Reply
Sean Flanagan said 9:56AM on 3-17-2008
Craig is rolling his eyes at all of you. You entirely missed the point of his piece. This is someone who has been developing for the iPhone for months, and is speaking from experience. He developed a network-dependent app for jailbroken iPhones, and was able to do so without using the "wake up" technique. He is essentially calling it a copout to use such a technique, since he was able to figure it out without the help of the SDK.
If one person coding a network-dependent app can figure out a way for it to work without the help of the SDK and documentation, I think Skype and AOL will be able to figure it out with all the documentation, tools, and a team of developers.
Reply
len said 10:05AM on 3-17-2008
People have been solving this sort of issue on Symbian platforms for nearly a decade, and BlackBerry devices initiate GPRS connections for every email and pushed update, and my BlackBerry has the best battery performance of any device I've owned.
So, are they really saying that iPhone developers are less skilled? We have to be protected from ourselves?
Reply
Dave said 10:16AM on 3-17-2008
Wow, amazing. Windows Mobile phones have been running things in the background for what, like 8 years now? The iPhone is one sexy beast, I'll give it that, but the lack of some very basic functionality is mind-boggling. It's all part of Apple's control game - you must make apps "our way". They would have loved to just keep everything as WebApps, but they finally realized they could make more money with an SDK.
It's a damn shame. I love my Sprint Touch - yes, it's not as sexy as my iPod Touch (yes, I own both, I'm weak!), but it sure works a lot better as a phone and PDA.
Reply
ramond said 5:29PM on 3-17-2008
Actually you are wrong, windows mobile professional (pocket pc) devices turn the CPU off and applications are stopped when they go into standby. Its always been that way.
northernphoto said 11:08AM on 3-17-2008
Finally some reason added to the iPhone SDK debate.
But can he answer why the iphone can't make it to Canada?
Reply
Eric said 11:10AM on 3-17-2008
Seems pretty pathetic in terms of battery life. I can leave my n810 signed into IMAP, AIM, YIM, Gtalk, and SIPPhone for 2 days without a recharge ( at least ). And it's connected to WiFi 98% of the time and never "sleeping" ( the screen does go blank most of that time ).
If this is the best the iPhone can offer then I'm glad that I didn't jump on that bandwagon too quickly.
Reply
tpp said 11:15AM on 3-17-2008
I think everyone of us understands why Apple is doing that, but I still find it totally bogus.
IMHO it would be much better if we (developers and end users) were given a choice. I would be COMPLETELY happy to recharge my phone more often to have the possibility of running some apps in the background.
Reply
Benson said 2:30PM on 3-17-2008
Apple's not selling a phone; they're selling a beautiful phone experience. If it was just a phone, providing maximum flexibility to devs and users would make sense; but some choices would wreck the experience (by killing battery life or responsiveness of foreground apps), so they can't permit those choices. Only they themselves, or sufficiently trustworthy developers, can be permitted to make tradeoffs that won't appreciably harm the experience.
If choice is what you want, rather than a guaranteed experience, perhaps the iPhone (Apple's way) is not for you. Go with either the iPhone (hackers' way), or some other device entirely.
Reply