The Battery Life Thread
Following the iOS 4.2.1 release in the news and in forums I came across a discussion thread in Apple’s forums that is about the issue of some users having extremely poor battery life after the upgrade from iOS 3.2. I have not yet upgraded to 4.2 and I might in fact hold on to 3.2 for a little longer for other reasons, so I don’t know yet, if I will be affected the same way. There are some users claiming that this is what is to be expected now with multitasking and several apps taking up resources at the same time. Reading through these, I could not help to notice that there seems to be a fair bit of confusion and misinformation going on about how multitasking might contribute to this issue
So from a developer point of view, let me just state a few things. Please note that the general tone of this is that the “Apple/iOS version” of multitasking is by no means comparable to what you know from Mac OS or Windows, so many analogies are just not correct.
iOS multitasking – A not-so-layman explanation
I would like to put a disclaimer here that have not yet had the chance to develop anything “big” for iOS, but I do believe I know enough about software development in general and the iOS environment in particular to clarify a few things. Should I be wrong in any respect, I would be glad to be corrected by someone with a deeper knowledge in the comments.
Switching apps in iOS prior to v4
In versions of iOS without multitasking (let’s just call them ‘old’) whenever you hit the Home button, the app currently running gets a signal from the OS that the user wants it to shut down. The app then has a chance to do some housekeeping, e. g. store some information in its private storage area in the flash memory about what pages are currently open in a browser, a reading position in a larger text or the like. It has only a very short time to do this, before the OS forcibly terminates the application and returns you to the home screen. That is to ensure the user does not get the impression the device is stuck or feels slow to respond.
At this point, there is no running trace left of the app. In particular, no background downloads etc. are possible in this state.
Please note that this applies to 3rd party apps only, things like he iPod app or Mail directly from Apple can play by different rules, but stay with me.
When launching any app in the old iOS versions, one of the first things most developers do is make it look for the information it might have stored when it was last quit. Using this information it can be then possible to return the app to a state that is close to what the user left it in – for example open the same browser pages again or jump to the last known reading position. How close it gets to restoring the precise situation as before depends in how well he developer did with this task. There is no additional help from the iOS with this. That is why some apps come up with their default view every time they are launched, while others quite accurately allow you to resume where you stopped.
The key point is: Once you are on the home screen, nothing can use up any battery that is not from Apple itself.
Putting apps to sleep with iOS 4
Now, with the advent of “multitasking a la iOS” a few things changed in that sequence described above. First, everyone might want to have a look at Steve’s keynote speech (available in iTunes as a free video podcast) where he explained how they did multitasking “right” to prevent the typical battery drain that is often seen on e. g. Android devices which feature something much closer to true desktop type multitasking.
One of the key points to realize here is that with iOS there is no such thing as a “generic” background application. Instead, there are a few (7 if I remember the keynote correctly) specific things that iOS (‘new’) allows developers to use. For example one of these is background audio playback, allowing other apps to behave similar to the iPod app. Another thing is finishing an up- or download that might be in progress when the home button is pressed. And a few more…
However, all these tasks are very specificly designed for by Apple and cannot be extended by app developers on their own – which is why certain kinds of background apps that exist on Android cannot currently be done with iOS.
Another thing to know is this: When the new iOS was introduced, a lot of apps got updates with release notes along the lines of “now supports multitasking”. What’s behind this is that developers have to explicitly opt-in to a different application lifecycle if they want to participate in the new multitasking world that is a little more complicated than what was described above.
Instead of just getting a note from the OS to shut down upon a home key press and then being terminated, the developer can choose to have his app “paused” instead. In essence, iOS will still tell the app about the home key event, but then it will not let it terminate, but just stop giving it any more resources, especially no more CPU time. In effect the program is still in memory at this point, but effectively just halted, as if you were hitting the Pause button on a DVD player.
The user can now start a different app from the home screen and work with it. The one she used immediately before is now displayed leftmost in the task switcher bar that comes up with a home button double click. Now this is important:
Just because an app is displayed in the task switcher does NOT mean, it is running! In fact, most apps are even ACTUALLY NOT running, but just consume some memory in their paused state. They do NOT cause any additional battery consumption, because they are halted!
The only way for an app to consume power/network bandwidth/any other resource is to use one of the aforementioned specially prepared iOS features. If you do not use an app with suchlike functionality, multitasking itself will NOT impact battery life.
What happens now, if you select an app from the task switcher? Let’s say you are currently writing a text in some sort of editor program and need to look up some things in a dictionary app you were previously using and that is now halted.
When you bring up the task switcher and hit the Dictionary icon, first of all the editor app is paused the same way. Once that is done, the dictionary will be unpaused and its GUI be animated to the front. Because it was just paused, it goes on whereever you left it. Simply speaking, it does not even know it was paused just a second ago (even though as a developer you do get notified and might want to do some additonal work like checking if the network is still there or the like to update your GUI).
At this time, the editor app is in that deep-freeze pause state. So in effect, iOS is not really multitasking in the sense that there are two or more apps running at the same time, it just makes switching between them much faster with this pause/resume trick. And because there is only one app running at a time, battery consumption is roughly the same as before, if all goes well.
Pause them… All?
There is one question that might come up in this: How many apps can be paused at the same time? Well, actually not too many, because iPads only have 256MB of RAM (not to be confused with the 16/32/64GB flash storage) and every paused app needs to fit into the remaining space that the currently running foreground app does not actually need itself. The iPhone 4 has 512MB, so it is less tense in there, but the principle stays the same.
Say if your editor was now waiting in the paused state while your dictionary is up, iOS might decide to really terminate it (just like the old iOS versions) if the dictionary app requested a lot of memory. If for example the dictionary had an integrated browser, surfing to graphics rich websites with it might require a lot of RAM.
In that case, in order to keep the foreground app running smoothly the OS might decide to reclaim the RAM the editor is currently taking up and just very uncerimoniously literally kill it in its sleep. This is why ‘well-behaved’ apps try to limit their memory usage to the minimum at all times to prevent others from being killed (and of course being killed themselves, because sleeping apps that use a lot of memory are an easier choice for the OS to kill).
If that happens, the app is still listed in the task switcher and will just be launched in the same way it would be in old iOS. From a user experience standpoint that is a very sensible choice Apple made here, because from the user’s perspective there should be no distinction between resuming an app from sleep or relaunching it – in the end the only thing that matters if that now she wants to use it again.
If the developer did his job well, the app will still resume to the state where the user left off, it just takes a little longer because the app is launched ‘cold’ and has to take care of that stuff itself, just like in the old iOS.
Explicitly terminating apps
Several times in the forums people point out that the price you have to pay for multitasking is manually teerminating applications when you want to preserve battery life. While for most apps we now know this is bogus advice, because they are not doing anything anyway when paused, it is nevertheless good to know that you actually can terminate an app manually.
When would thiis be helpful? Well, being paused and resumed as an app sounds fairly simple in general, but any developer with a little bit of experience will agree that most things are not as simple as they might at first seem. Without going into detail here, it is not very hard to have an app get into a f****d up state through any combination of programming mistakes.
In general people have learned that most problems can be cured by shutting down and restarting an application. While inconvenient, this used to work… That is, until iOS4 came along.
Because leaving an app by pressing the home button does not actually terminate it, any problematic state it might be in will be happily suspended by the OS and just as happily be resumed when you hit its icon again. BTW it does not matter whether you start it from the task switching bar or from the home screen.
If you have an app that is in such a pitiful state what can you do, short of going the Windows-Way of rebooting the whole OS? Well, you can remove it from the task switcher by holding on its icon in there until it shows the little red sign in the upper right corner. Pushing that sign will cause the app to be terminated, just as if you had been working with a memory hungry foreground app and the system had decided to evict it to free memory.
All nice and good, but I want my battery life back!
So where does this all leave us with respect to the problem of iOS 4 upgrades apparently sucking people’s batteries empty way faster than before?
Well, unfortunately all this knowledge is no silver bullet – it just helps us understand that this particular problem most probably does not have anything to do with iOS-style-appswitching at all…
If you are not using apps that do use any of e 7 background features – and you would probably know if you were, because these new features would usually be something you were looking for explicitly when buying the app –
using multiple apps ‘at once’ pausing and resuming, i. e. switching back and forth between multiple apps, will NOT cause significantly increased battery drain.
It also explains why nobody in the discussion forum so far has confirmed that removing apps from the task switcher (or not even starting any app after a reboot) really made any noticable difference.
This is the sound of inevitability
That all being said, of course life (and technology ;)) is even more complicated… Strange as it may sound, in fact, being a sibling/offspring of Mac OS X, iOS has always been a real multitasking OS from version 1 on the original iPhone, way before the Appstore even existed.
There are at any given time a lot of processes running, for example the home screen (“springboard”), background processes that monitor network signal strength, listen for incoming phone calls, push notifications etc. and several more.
And because that is so, there are a lot of variables in the game that can cause extensive battery drain. As with any piece of software there are certainly bugs in iOS. And as is often the case, bugs do not affect all users and device configurations the same way. If that were so, they would have been noticed by the iOS team and be fixed before the rollout of a new release.
But some problems only occur on certain hardware plattforms, certain timezones, certain configuration settings etc. Moreover problems might only arise on freshly installed systems, or only on updated ones, maybe even only if you went through multiple version uodates in a particular sequence.
The point is, that there is no way on earth all these combinations could be tested in advance. One can be very sure that a lot of tests were conducted before any serious update is rolled out.
However I have to also say that in my experience there have been a number of really serious quality problems with Apple products in the recent past (iPhoto 11 anyone?) and that Apple’s policy of being quiet about these until either being pressed very hard or until they just put out another update does not do their standing with customers very much good…
There is some discussion floating around on the net that a slightly higher energy consumption might come from the Find-My-iPhone feature that is now included for the iPad as well. Even though I did not yet see the effect myself I find it hard to believe that the huge drains we are talking about here are caused by this feature alone. But maybe making sure it is turned off can alleviate the pain until a real fix is found.
In the end, I assume there are one or more bugs in 4.2.1 that directly result in extremely quick battery depletion for some customers, but do not affect fine the majority of others. That is why there is so much heated debate about the whole matter.
While it does certainly not help anyone when people who do not have the problems just deny that there is one based on their own experience and try to make other people feel too stupid to use their devices, sadly those seem to be the loudest ones (see Phily_Phan’s posts, esp. the 3rd from the bottom).
I think I will try 4.2.1 regardless – if I am lucky, it will work just fine, but if not, I won’t hesitate to downgrade to he trusty 3.2 and wait for 4.2.2.