John Gruber's take on iPhone background apps | Hacker News Reader

John Gruber's take on iPhone background apps

daringfireball.net

6 pointssanj13 comments

from http://daringfireball.net/

direct sublink is: http://daringfireball.net/linked/2008/march#fri-21-jens

"Another one from the I-don’t-agree-with-it-but-it’s-well-worth-reading dept.

For what it’s worth, I believe the number one reason why the iPhone OS doesn’t allow background processes is RAM. Battery life, CPU sharing, bandwidth — all of these are factors, too, but I think RAM is foremost. The iPhone has just 128 MB of RAM and no swap space. A good chunk of that 128 MB goes to the OS itself and the built-in apps that do run in the background — Phone, Mail, Safari, and iPod. There really just isn’t much left over. If Apple were to just allow background processing now, what would happen is that background processes would often wind up getting killed by the OS at some point when the frontmost app needs more memory. From the user’s perspective, it would seem as though background apps inevitably mysteriously fail and stop running. You can argue that you’d rather have that than no third-party background apps at all, but it’s clearly a reasonable trade-off for Apple in terms of consistency and obviousness in the user experience.

Wait a few years for iPhones with 1 GB of RAM and it’ll be a different story."

Open articleView on HN

Its definitely not RAM.

Android devices with significantly less RAM handle it fine. When a Service is scheduled, it is only allowed to run while resources (battery, CPU, memory) are sufficient to keep the critical processes (currently visible UI, current application) running. The OS has permission to kill off background Services without warning as needed to preserve the user experience.

No, the reason with Apple is simply political.

It's not just RAM, but it's not political either. It's battery life, I should think. Remember this is a phone we're talking about and if that phone has to be recharged every six hours because some application constantly wants to poll the internet, that's really not acceptable to most users (and they won't fault the app for the poor battery life, they'll fault Apple).

I agree strongly with the battery life argument. Its an important note to make that the battery is run down because of frequent wifi/edge use. I've seen accounts of pre-sdk iphone hackers making programs that ran the battery down in hours just polling for tweets every minute or something similar. That same hacker said that ideally there would be some sort of registration for wifi/edge time that would bring up a connection every T minutes and tell all the programs registered to that listener that they now have 1 minute of access to the internet to poll whatever service they needed.

i don't think an android comparison is appropriate. different implementation languages, different philosophies, different hardware expectations, etc. for example: "The OS has permission to kill off background Services without warning as needed to preserve the user experience" -- apple would NEVER go for that. while it might be the right thing to do technically, it would badly confuse the user: "why did my app stop working?" apple just doesn't play like that.

and are there any actual android devices available that this idea could be confirmed against? last i heard, there weren't any.

Well, I don't think Android apps just get nuked from one minute to the next - they get a chance to shut down and save state.

If anything, Objective C is going to be more efficient in terms of processor cycles and memory, so that point would go to the iPhone.

I prefer Android's approach: laissez faire, and see what works out rather than attempt to foresee everything beforehand and risk killing off good apps before they even have a chance.

did you read where the sentence you're apparently replying to said "background services?" i wasn't talking about "android apps getting nuked from one minute to the next."

almost all the arguments here are on technical merits. me, gruber, and others seem unable to convince you guys that apple quite often doesn't make decisions based on technical merits, but rather on what will make a better experience for the user.

gruber, me, others, etc, certainly aren't arguing that background apps aren't possible. the argument is whether it's advisable, given the current limitations on memory, cpu, battery, apple engineering time, and backward compatibility.

one of the main things that makes windows suck so much is microsoft's slavish devotion to backward compatibility. there are things in the win32 api that got there because the 8086 didn't have memory protection, for crying out loud. apple doesn't want to commit to a public api until they know it's a good one.

"I prefer Android's approach: laissez faire ..." spoken like a hacker, rather than like a typical user of a mobile phone. apple is always going to prefer thinking about these things from the point of view of the user.

Yes, I know they're talking about background services.

> apple doesn't want to commit to a public api until they know it's a good one.

> "I prefer Android's approach: laissez faire ..." spoken like a hacker, rather than like a typical user of a mobile phone. apple is always going to prefer thinking about these things from the point of view of the user.

Well, I am a hacker, and I'm not going to apologize for it:-) I'd rather have that freedom, and see what happens. I get your point, and think it's a sensible one, but when all is said and done, I'd rather have a more open system. I think that Apple has certainly demonstrated that their approach is a good one for certain types of users, but it's not one that I prefer.

Thats correct, you can save your state just before a Service is killed. The onDestroy() method is always called by the OS first. And Android will automatically try to restart your Service, when resources are sufficiently available again.

I also prefer Android approach, even if theoretical performance might be lower not being native.

I can't believe this is actually being discussed in technical circles seriously. The limitations around the iPhone SDK are more certainly NOT technical in nature - phones (both smart and otherwise) have had background processing and multitasking for years and has never caused any problems.

Doesn't anybody remember last year's mantra of "the web is the only SDK you need"? The same people that believed that line of BS, and now spreading this updated BS.

Apple is a control-freak company and these decisions are purely political. Jobs & co only wants you to do with the phone what they like, not what YOU want, its just that simple.

http://www.pbs.org/cringely/pulpit/2007/pulpit_20070906_0028...

Since reading this bit by Cringely last Autumn, I can't help but think of a lot of Apple's output through the prism of "being alternately seduced and tormented"; e.g. the iPhone SDK which is only supported for use by recent customers of Apple's (Intel) personal computers.

http://daringfireball.net/linked/2008/march#fri-21-jens

The little star at the end of each link is the permalink.

Much appreciated.

Yeah..the ram thing is a crock IMO. Wasn't THAT long ago that 128 mb was a LOT of RAM. Sure, you have to be careful, sure you might not be able to do everything you want with fancy bells and whistles but I don't see why it should be a valid reason to preclude background apps.

Reply on news.ycombinator.com