iOS 4 limitations: Multitasking saves state, doesn't check for timeline updates

We've had a few TiPb readers ping us to ask what's going on with timeline-based apps like Twitter, IM, RSS, etc under iOS 4 multitasking -- specifically why they aren't updated or updating any more when they open. The answer is the current timeline update conundrum.

First, it's important to remember that Apple didn't include background timeline updates in their multitasking API. Apps can stream music, they can wait for VoIP activity, and they can handle location for navigation or check-in, but they can't update your Twitter, IM, or RSS the way Apple's own Mail app can. Apple's SVP of iPhone Software, Scott Forstall said they prefer iOS handle that via push notification instead.

Push notification is fine for alerting you that a new update (tweet, IM, article, etc.) has come in, but when you launch the app -- because of the lack of background timeline updates -- the app has to then check back with the server and download every update since the last time it ran.

Under iPhone 3.0, this was handled by most apps when you launched them (some more quickly than others). Under iOS 4, however, apps now save state and restart from where you last left them. And therein lies the problem -- many apps aren't checking for updates because they haven't been relaunched, they've just been continued from their last saved state.

No relaunch, no check for updates.

UPDATE: per comments below, tweets, and emails, developers are telling us that apps can, in fact, be coded to check for updates when they return to the foreground and that it's not overly difficult to implement (and some apps are indeed implementing it).

If that's indeed the case, the question becomes: why is the only solution in many of our favorite timeline apps still a manual refresh? (i.e. trigger the reload action by tapping a button or other gesture, sometimes backing out a screen or two to get to a place you can do it -- which defeats some of the benefit of saved state.)

Do we need to start a "naughty and nice" list for this functionality?

Have something to say about this story? Leave a comment! Need help with something else? Ask in our forums!

Rene Ritchie

EiC of iMore, EP of Mobile Nations, Apple analyst, co-host of Debug, Iterate, Vector, Review, and MacBreak Weekly podcasts. Cook, grappler, photon wrangler. Follow him on Twitter and Google+.

More Posts



← Previously

UPDATED: Apple comments on iTunes fraud - dev banned, change your password

Next up →

Apple updates MobileMe iDisk: Universal for iPad/iPhone, multitasking for iOS 4

Reader comments

iOS 4 limitations: Multitasking saves state, doesn't check for timeline updates


Not a big fan of multitasking. I feel like i spent a lot of time closing at least 3-4 pages of apps at a time, even tho most arnt even written for ios4 yet. Apple needs some sort of way to toggle which apps are automatically backgrounded, make a way to force shut down an app easier than holding lock then home button, or a way to clear all tasks or select multiple apps to close at once. Just my 2cents

It is VERY easy to implement. When the app comes to the foreground, it alerts the app, and the developer can refresh it then. I know from experience from being a developer ;)

@iSkythe: then why are apps updating to support saved state and not including update checks on return to foreground? :-/

Some apps are already doing this. The "Official" Twitter App does it, when you restore the app it immediately initiates a new data pull (if it's been longer than some period of time since the last one, to avoid API rate limits).
However, I've seen the exact situation you describe with apps like the FaceBook app.

@AppleFan- those apps you are closing aren't even running for the most part. That's just a recently used list of apps you're looking at. Unless they have specific backgrounding activities there's no need to delete them.

Yes, Apple made it VERY easy for developers to perform any updates when the app comes back from a frozen state. Simply override the applicationDidBecomeActive method in the main app delegate - this method is called when the app becomes active.

This is why we still need to jailbreak and run Backrounder. Almost nothing was changed by this "new" multi-tasking feature other than music in the background. May be a big deal for pandora and slacker people but I use a calendar app and quick docs and they both have to re-open and refresh each time I re-launch them from the task bar. It truely is a "recently used list" rather than a multi-tasking list. I wish it only showed the apps that are actually doing someting in the background.

I just started noticing this problem, primarily with weather apps. If left in a saved state, the weather displayed may be hours or days old and they do not have a refresh button. So you either have to change your location and then change it back or close the app and relaunch.

@Hungwell & @ReneRitchie: thanx I was closing those apps in the bckground jus like @applefan because I thought they were either draining the battery or using up memory.

IRT closing apps. The Apple rep who happened to be at Best Buy when I went to return my I 4 that was rapidly draining said that the apps that weren't updated for 4.0 indeed were ruining in background and were part of of my battery issues. I turned the phone in nonetheless and await solutions to that and the antenna and proximity issues. Or who knows Droid X. Although I'm plenty happy with my 3G these days.

Yeah, weather bug opens at saves state and rechecks when re opened, which is fast and awesome. Accuweather on the other hand just shows old info until you re launch it.

the thing about the whole "music in the background" is that Pandora is NOT just playing the music, but is also requesting the next song to play, keeping track of what songs are playing, and requesting more songs to play at the end of the current one.
What i am wondering is why couldn't someone make a twitter app that not only plays music, but also uses that conduit to grab new tweets?
I am guessing Apple would block it because it would be side-stepping the API so to speak.

This is why Apple's fake multitasking sucks. I was mainly looking forward to this for instant messenger based applications, like Twitter and Beejive, but the fact that it doesn't actually update the app in the background it's pretty much useless.

Facebook definitely has this problem. Flip back to it and it shows "6 minutes ago" or whatever for timeline based on the last time you refreshed before switching out of the app.
I also use MobileRSS which best I can tell hasn't yet updated to any iOS 4 "multitasking" features.

I think everyone can agree that Facebook is a joke. Between their sucky iPhone app and stealing private data, I wouldn't be surprised if they ran that company into the ground.
My company recently blocked Facebook on our company network because they found that the browsers were accessing and uploading from our Outlook address books when people accessed their Facebook accounts...

I believe there's an even worse issue on apps like Tweetie (now Twitter for iPhone) where when you force the app to close using the double tap home, hold the icon and "remove" it, then you open it again it thinks it crashed and restores an old database.
Another but I just stumbled upon is the iSSH app sending me a local notification to alert a connection was about to expire when it wasn't even on the running apps list... Very odd.

I'm definitely not a fan of the "multi taksing" crap apple is trying to pull. I have noticed a battery drain unless I go and close out the apps being stored in so called "frozen mode". In my opinion apple tried to rush out a product (software update and hardware update) without having it fully tested. Clearly "changes everything" in a bad way.

Minor point (though maybe not to him, since tipb mispells is most of the time): Forstall. Not Forestall.
Major point: About a month ago, while iOS4 was still in Beta, Marco Arment (instapaper, tumblr) blogged that Apple's implementation had already caused him some issues with his customer base, because what Apple calls multitasking is not what users commonly expect as multitasking. He noted that dissatisfaction tends to be directed at the app -- (Rene's naughty and nice list would seem to qualify here, as well -- even though as Marco notes of the complaints, "As long as iOS “multitasking” can do much less than traditional multitasking — which will probably always be the case — this is going to be an issue."
Rather than call for full multitasking, Marco proposed a single new multitasking process type added to iOS4 -- essentially allow apps to register in a background network queue. Quoting his proposal:

  • The application gives the system an NSURLRequest and an ideal refresh interval, such as every 30 minutes, every few hours, or every day.
  • iOS executes that request, whenever it deems that it should, and saves the response to a local file.
  • Next time the application launches, iOS hands it an NSData of the most recent response.

Since iOS would be in charge of when the request should execute, such a proposal would not seem to impact battery life or foreground performance, but the most time-intensive component, the network request, would still occur in the background and transparently to the user. Since the loading and parsing would only occur upon app launch, it would not interfere with other foreground processes at all, either, but it would appear far more responsive to the user than network loading and parsing in one fell swoop upon launch. Perhaps as importantly, since the network request would be finished, one could load fresh tweets, RSS feeds, whatever, while in a no-coverage area.
Marco's proposal seems very reasonable, limited, and directed, but it would in one fell swoop enable not just his app (Instapaper), but all Twitter clients, RSS readers, and anything else that would like fresh content on an interval.
His June 10th Blog Entry on the topic:

I'm about 99% Twitter for iPhone refreshes when you return back to it. But I know Facebook does not. Devs certainly need to implement it though.

It's 100% app dependent on the refresh issue. Any developer can easily implement "refresh-on-restore" functionality.
Background tasks are completely another matter. Until Apple releases more API calls for background stuff, it's not going to be "true" multitasking.

Many other app update as well when it comes back in the foreground (I can think of PushMail which I just opened now, but there are certainly many others). My understanding is that developers who didn't implement this just didn't test very well with iOS 4 devices. For Reeder, which I uses so many times a day, that's a real pain (and clearly some sort of misrespect from the developer who must have earned tons of money with his -- very nice -- app). There is no way to update while in the background, but it's a clear mistake not to put the boiler plate code in appDidEnterForeground to do the updating bit on demand.

So I guess when devs start implementing it correctly we won't have this problem. A jailbreak should satisfy those who want to run apps continuously. But I can't think of many that you would want to run continuously. Especially instant messengers. Isn't push notifications combined with fast switching enough? On android and winmo I rarely ran IM clients all the time because they would just drain the hell out of my battery. Push notifications and fast switching is a dream come true for someone like me who chats across multiple protocols and wants to conserve battery.

Facebook definatley has this issue, if you have it in the background, you need to manually refresh to get the latest posts, if you kill it from multitasking, it will automatically refresh next time its opened !

From everything I've seen and all the developers we've spoken to, Apple's multitasking system (and yes, it's true multitasking no matter what anyone else tells you -- multiple tasks can and do run at the same time -- so stop that) is off to an excellent start.
It's not rushed. It's considered. It really tries to strike a balance between user perception, user functionality, device performance, and device power. And it does a great job.
I wish it included background timeline and a way to maintain persistent internet connections for things like SSH and hopefully those will come in a future update.
It remains a very Apple like solution -- in both the very smart, and very limited meanings of the word.
Other mobile OS are doing it differently to be sure, and have their own pros and cons, but this is a robust, legit system.
For most users, it accomplishes most tasks, with the least impact.

For The person that posted best buy told them apps not made for ios 4 stay in the back ground it's completely FALSE. In order for any app to have any backgrounding or suspended state features it must be compiled in the new sdk. If not it has ZERO multitasking capabilities.
As for the refresh issue, when and app is un suspended you can code it so you call a refresh. It comes down to programers just recompiling there apps to quickie support app the app suspend feature. More apps will be coded correctly in the future. There is also the ability for apps to keep internet connections alive for 10 mintues after it's suspend to finished downloading or keep and ssh/ irc session open. Gps can be made to stay on all the time ( which can drain your battery fast) but it's great when you are recording tracks and when programers implement it properly (like only keeping the gps on while you are recording a tack)
Sure there's more APIs apple can do and I'm sure they are working on it. But so far I live the multitasking and the battery drain for me has been no existent.

Twittelator updates when relaunched and I now know why Facebook has stopped updating when I open it again and I have to refresh.

Well, no, it is not "true" multitasking in the sense computer users have been accustomed to since the early 1990s. It is multitasking in that separate tasks A & B can run (essentially) concurrently, but it is not in that Apple defines strictly what A & B can be, and those restrictions have never been part of the definition. I would never argue Apple's approach is illegitimate or not robust, but Apple deliberately confused the issue by appropriating a term that has meant one thing for 15 years, and not qualifying it or explaining the restrictions they have introduced. Yes, they explain it to developers, but to users they just say "iOS does Multitasking." Developers like Marco then field complaints and get negative reviews from their users that their apps do not "Multitask," because the users do not understand Apple disallows it. All they know is that Apple says iOS multitasks, and that Instapaper does not.
Apple gets the benefits, and the developers get the blame, and are left to try and explain. Since Apple did not (and will not) put a necessary adjective to describe their flavor of multitasking, or attempt to explain it to iOS users, others have to do it for them, and you cannot expect them to be complimentary in such a situation.

@Dev: That's certainly valid but at the same time it lets users off far too easily. Mobile is analogous to but not identical to desktop. iPhone's virtual keyboard isn't the hardware one users are used to. Folders aren't the same as desktop hierarchical views. Users adjusted to pre-emptive multitasking (I had Amigas for many years ;) ), they'll adjust to abstracted multitasking as well.
If developers really can poll for updates on resumption, that eliminates a lot of complaints about timeline.
And if users weren't complaining about multitasking misconceptions, they'd probably be complaining to devs that their apps were chewing up too many resources, causing crashes, or draining power. Sadly, most developers only hear complaints from users.
Would Apple more clearly explaining the 7 multitasking functions help users or confuse them? I don't know. Right now developers not adding saved state when they offer iOS 4 compatible apps probably confuses things more.

Letting users off too easily? Most people on this site, yourself included, argue that iPhone's success stems from the fact "it just works" and it does not force users to think about things they do not have to. You cannot simultaneously praise Apple for this focus on simplicity and let them off the hook when they ignore this focus to deliberately sow confusion.
You are letting Apple off way, WAY too easily. There was nothing to adjust to when going from cooperative to preemptive multitasking, unless you think users had to struggle to accept less crashes. Besides, it is meaningless whitewashing to call this "abstracted" multitasking. This is restricted multitasking. There is nothing necessarily wrong with this, and it might indeed be a useful tradeoff for mobile devices.
Apple is making no effort to explain the restrictions, and they are letting developers take all the heat and support costs. They are going one worse, by claiming a term -- multitasking -- that traditionally means something more than Apple's implementation, and conflating its use simply to be able to fill in the checkbox in vs Android comparisons. Apple knows this deliberate confusion puts extra burden on their developers, both in terms of work and in terms of complaints, and they plow straight ahead, providing not even the minimal support a good platform vendor should.

That should have said most people on this site, myself included...but I am sure Rene has argued the same point in the past, too :)

@Dev, I meant in terms of what they understand. Folders on iOS 4 are very limited hierarchies but the word makes a certain amount of sense and matches the functionality enough that it obviates the need for a lot of complex explanation.
For many users, "Pandora while surfing the web" was the poster child for "not multitasking" (even though iTunes app could stream in the background just fine). Now Pandora can stream while surfing Safari as well. They can do Skype, they can do TomTom. If a dev updates to include saved state, they can leave their game, take a call, and come back to where they left off. Not calling that multitasking would be more confusing.
First time I booted up a Droid and launched Chrome Lite it spat an out of memory error back at me. There are trade-offs to every approach, and reasons for users to complain to devs in every implementation.
If you go to Apple's page on multitasking, the do point out it's different (they call it smarter, the right way, which is hyperbolic but differentiating none the less). They point out exactly in which ways iOS multitasks -- fast app switching, audio, voip, gps, local notifications, and task completion.
Frankly, I'm not sure putting up a whole page on the very popular site can be consiered "no effort".
And the reason I bring this up is because I think arguing the semantics of the label takes attention away from the real problems -- no support for timeline updates (though, again, if update on resumption is true, that might be mitigated), no support for background network connections (SSH), labeling apps as iOS 4-compatible when they don't support saved state, etc.
It's multitasking. Done. Now the issue is how well and how can it get better, both from Apple and devs.

Again, you are giving Apple way too much benefit of the doubt here. On the very page you cite, Apple lists a few things the iPhone can do in multitasking, but none where it cannot. Now, if you are the "average" user, are you going to read that, and assume that it can ONLY do those six things, or are you going to assume that the word in big bold letters at the top of the page means what you (through your past device experience) have known it to mean for 15-20 years, or are you going to assume that Apple has redefined a common term to mean ONLY those half dozen things.
I think even the most pro-Apple fanboy (and I write this with my iPhone 4 plugged into my 17" Macbook Pro) would have to admit that at the very least, Apple is deliberately capitalizing on overloading a commonly understood term, and, at the worst, being disingenuous in their naming. If, as they hyperbolically claim, they are doing it "right" and better than anybody else, they could have called it Smart(TM) Multitasking, and been done with it. An adjective would have been more honest, and anything that would have given the community a hook would have been appreciated, but Apple deliberately chose to muddy the waters.
Regardless of where you fall on that spectrum, it is not simply semantics. The (mis)use of that term has incurred real costs for developers. Not counting the small amount of work to add saved state and other features, it is a simple fact that developers whose apps would benefit from more "traditional" multitasking are receiving support calls and negative reviews (which historically lead to reduced sales) because users are expecting multitasking that the developers cannot deliver. Apple's marketing efforts serve only to exacerbate that problem.
It is easy to dismiss it as mere semantics when you are not the one bearing the cost.

@Rene -- as for what to do next, even if Apple was willing, it is far too late for Apple to rectify the misinformation in their naming, but to see a plausible technical next step, read through Marco's June 10th post, linked in my first comment. While still restricted, Marco's proposal adheres pretty closely to Apple philosophies about opening only what is necessary and the primacy of the OS over apps -- but what he puts forth would satisfy a HUGE percentage of those developers and their users:
Twitter/RSS clients would be able to poll in the background when iOS allowed them, and even persistent SSH connections would be possible by scheduling some manner of keep-alive command on an interval less than the session timeout. (Yes, that last one might require a bit of user tweaking, but, honestly, the people who need persistent SSH connections are exactly the sort of people who would know how to do it.)
That is not going to help with your third issue -- calling apps without saved state iOS4 compatible -- but you imply would be the neutron bomb of confused semantics. :) The apps run just fine under iOS4. They are perfectly compatible. They do not take advantage of every feature, but they run. Redefining "compatible" to mean "takes advantage of feature XXXX in the latest version of the OS" would create the same problem people like Marco are facing with "multitasking," only a million times worse. Instantly, perhaps 85% of the App Store would be labelled iOS4 incompatible, giving them an effective death sentence when many of them have no need or use for saved state, and on a plurality of devices out there (2G and 3G), such a term would be completely irrelevant.
And we would get this amount of fun every single software release, where Apple would essentially have to re-approve every single App in the App Store as developers rush to resubmit before each major iOS release to avoid the death sentence of being labelled "incompatible." The App Store has enough trouble with the current flow of submissions; recycling each year's approval again evern June would benefit neither developers, Apple, or us users. Separating apps with saved state and similar new features as iOS4 "Enhanced" or similar, that would likely be fine.
See, semantics matter :)

I love reading these stories where you people complain about iOS4 not multitasking right. That's because it's not multitasking, it's just an illusion of multitasking. It's a pause and switch. Not a running int he background and switch, which is true multitasking.

I personally find this multitasking confusing. I forget which apps can actually "multitask". I find myself having to always remember which apps can and cannot each time I'm about to close an app to handle a text. But I guess we will have to wait because ios 4 is still early..

Many here would accuse (Copy of) Dev of Nitpicking. Now the nature of his nitpicking and execution may be a little different than what full nitpicking has meant for decades but it is nitpicking all the same. :|
When one uses a microscope to study the rose, the beauty and fragrance of it can easily escape one's zoomed myopic perception.

Cute, but to rephrase myself above, it is easy to dismiss it as nitpicking when you are not the one bearing the costs.
And, for the record, I have no problems with the technical tradeoffs Apple made with their take on multitasking, but it is a simple fact that their marketing measures around it have incurred unnecessary extra costs and headaches on a class of developers.
You don't care. Fine. But don't expect those of us left with those headaches in Apple's wake to be ecstatic about it.

i dun noe if this was mentioned above (i didnt feel like reading all that lol). I noticed this the first day i upgraded to iOS4 while using the Safari Browser. Sometimes it doesn't post back properly.

Apple's 'multi-task' solution doesn't make sense to me. All I end up with is pages of 'open' apps. There's then no point using the extra dock as it's 10 pages wide so why have it?
I can't tell which apps are just open and which are multi-tasking? Where's the 'shut down all' option?
Seems to me almost as sensible for the device to run every single installed app in the saved state mode and be done with it.
I just think it's a very odd implementation and the JB backgrounder system was better.

...also, if you do use the new dock, say, to go back to the app store or maps you used earlier, why is there a delay before any info appears? That is not multi-tasking as far as I'm concerned. That is re-loading.

stop calling it multitask coz its not!!by the way,you fanboys are so stupid you wpuldnt wanna multitask..just do it one at a time...hahahahahaha

I could read Dev and Rene's back-n-forth all day, especially while I'm at work! Lol, I learn so much. Thanks guys!

Anyway, time to toss in my 2 cents:
iOS4's multitasking is TRUE multitasking, just restricted. No one here can really say that it's just "saved state". I will say that with some, maybe even most apps run along this path of pausing while you execute another function. However, when you take apps like Pandora and Slacker as examples - they continue to run while you pursue other apps. Those are 2 prime examples (maybe only examples) of real multitasking on iOS4. This is why I say it's not just a "saved state" sort of deal, but rather real functionality - just restricted.

Kudos to Dev, it is refreshing to finally see comments from the Apple supporters finally calling out true issues that we as consumers are force to accept as "enhancements". The bottom line is that this is not true multitasking and one page on Apple's website does not offset the countless advertisements using the term multitasking as we know it.
I am not Apple user, I do however like their products. They have always been easy to use and stable. I do not like Steve blo-Jobs attempt to tell me what I like and dislike or when new products are released with "improvements" and "upgrades" with things that other phones have had for months and even years.
I have been using the 3G for 2+ years now and have been very happy with it, but when I jailbroke it and the phone realized its potential I swear I would not go back and I'm not.
Do not piss on my back Steve Jobs and tell me it is raining. You had a good thing going until you took us all for lemmings.

So it's not really multitasking if it is in a saved state now is it? It's not black if it's black but just a little lighter now is it?

Hi Jordan, can you detail the process a bit more? A potential candidate would have to provide you with the source code or do you work off of the binary? Thanks!