7 ms·

John Gruber's take on iPhone background apps

6 points by sanj 19y ago

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

jsjenkins168 19y ago
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.
- mtts 19y ago
  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).
  - maximilian 19y ago
    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.
- allenbrunson 19y ago
  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.
  - davidw 19y ago
    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.
    - allenbrunson 19y ago
      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.
nilobject 19y ago
http://daringfireball.net/linked/2008/march#fri-21-jens http://daringfireball.net/linked/2008/march#fri-21-jens The little star at the end of each link is the permalink.
- sanj 19y ago
  Much appreciated.
martythemaniak 19y ago
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.
- sjh 19y ago
  http://www.pbs.org/cringely/pulpit/2007/pulpit_20070906_002891.html 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.
TrevorJ 19y ago
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.

6 points by sanj 19y ago

jsjenkins168 19y ago

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.

mtts 19y ago
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).
- maximilian 19y ago
  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.
allenbrunson 19y ago
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.
- davidw 19y ago
  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.
  - allenbrunson 19y ago
    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.

nilobject 19y ago

http://daringfireball.net/linked/2008/march#fri-21-jens http://daringfireball.net/linked/2008/march#fri-21-jens The little star at the end of each link is the permalink.

sanj 19y ago
Much appreciated.

martythemaniak 19y ago

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.

sjh 19y ago
http://www.pbs.org/cringely/pulpit/2007/pulpit_20070906_002891.html 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.

TrevorJ 19y ago

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.