Benjamin Mayo
Reactions to http://www.tuaw.com/2010/06/14/multitasking-in-ios4-is-not-a-magical-sparkle-pony/
With the upcoming iOS 4, Apple has announced a solution for some of those applications, but only a handful of specific kinds of applications: location data, voice over IP (VoIP), and audio. You will be able to stay on a Skype call even if Skype is in the background, once Skype adds support for it. You will be able to listen to Pandora Radio in the background once Pandora adds support for it. Your GPS app or other location-aware app will be able to keep tabs on your location in the background, once it is updated. In fact,Tom Tom has already announced that its navigation app will be background-ready, so your "At the end of the road, turn left" announcements will come through even if you're doing something else. That's it, though. Background processing is extremely constrained to three specific areas, which Apple believes will cover most of the things that most people want to do most of the time.
Up until this point the article is good. The description of pre-iOS4 multitasking is correct. However, iOS4 isn't simply constrained to location, VoIP and streaming audio. There are, in fact, seven services developers can use. Background audio is one. VoIP is one. Streaming audio is another.
But, there's more. A slightly tenuous one Apple notes is "push notifications". I don't class this as multitasking; it is push notifications - completely separate. Remember, a year ago, Apple were saying (which was a blatant lie) that push notifications were instead of multitasking, so they can't be the same thing. Local notifications are, and that's the next service. This allows push-notification-like alerts that do not need a server running, thus no internet connection is needed either. Therefore, alarms and timers can background (making a noise/alert when the time ends), TVGuide.co.uk can alert you of your next episode of Glee extremely easily. Heck, even We Rule could make a noise when your crops are done. This is a multi-purpose service; it doesn't have one set function (unlike the first three), and has many applications.
The same is true with task completion; something the article blissfully ignores. Task completion lets an app complete a task, the thread is then destroyed as soon as that task ends to save resources. A very good example Apple states is letting photos upload. Enter Flickr, upload 20 photos. Go out of Flickr. Photos continue to upload. That's multitasking. And that's not "location data, voice over IP (VoIP), and audio" at all. For more examples, task completion allows for the user to continue to check email whilst waiting for the downloads of songs in Tap Tap Revenge to finish.
The largest flaw of the article is yet to come though.
According to a few developers who talked to pocket-lint.com, don't hold your breath for multitasking support in all your apps. One developer said "Why would you want to multitask during a game?" I don't know who this developer was, but I would like to remind him/her: the iPhone is innately a multitasking device. All applications should be ready at all times to exit at the user's command. Why? Because the phone might ring.
If the phone rings and I answer it, will your application bring me back to exactly where I was when I left off? It should, but very few applications get this right. With iOS 4, that oversight is going to be much more glaring especially since Apple is promising people that apps can remember where they left off. Starting with iOS 4, if your app doesn't do that, your customers are going to expect that you are working on a new version that will. Yes, even the gamers. Save your state and bring us back where we left off when we exited your application and you'll be ahead of most applications.
Umm, that's the last function of the multitasking solution; fast app switching. That's why Apple is promising people. In previous versions of iOS, state-saving was the sole responsibility of the developer, but it was possible. The reason it had little use was because it was difficult to implement. It required large rewrites of some codebases, due to the nature of Objective-C classes. Apple has recognized it was an issue, and have responded with a first-party API set to abstract the difficulty to the OS. Apple's solution (memory caching) is better aswell, allowing for 1:1 instantaneous restore of state. This means games put you right back in your place mid-game, if you got a call, if you got a new email, if you needed to do anything. It works and it's here; here's Steve showing it off with a game of Tap Tap (about 4minutes in).
In conclusion, Apple's implementation of "multitasking" isn't perfect from a function perspective (the overall experience is very good though), although it certainly is better than what the article makes it out to be. I agree, the OS needs a background-updater for things like Instapaper, and Marco Arment's proposal is good. I had a similar idea, utilizing a new type of push notification. This push notification would do nothing user-facing, but push relevant content (such as Instapaper articles) to the device. The OS stores this, and then - once the app is reawakened - informs the app of the new content and let it deal with it. Even a socket link API would do the trick for IMs, so the app doesn't need to reconnect to it's streaming server. The socket would be able to be left open but idle, reducing the wait time for the app to interact once the user returns.
Multitasking in iOS4 is not a magical sparkle pony. It's a magically sparkly unicorn that is close enough to a pony to reasonably allow Apple to call it a pony for the vast majority of users, when it still has a horn on it's head.
OFFTOPIC:
I foresee a UI issue with Apple's solution. The onus is on the developer, which is fine. However, if the behaviours become widespread (which I think they will be) the user experience is terrible when it isn't present. Flickr may have updated itself to allow for background uploads, but SMALLPHOTOCOMPANY hasn't. The user backgrounds SPC when uploading photos, as they are used to the Flickr app doing the right thing. What is the user going to feel when they return to the SPC app to realize that their upload failed, and - worse - they have lost their photos?
Hopefully, Apple will have a fix for that - soon.
Hi there. I run this blog for fun, have coded some Google Wave robots, and maintain an exploration into the human mind. Now we've got that out the way; scroll back up and keep reading.
Theme created for Posterous by Obox and customized by yours truly.
Comments 18 Comments
Yes, and TJ acknowledged that it's part of iOS 4. The problem (as noted in the developer quote immediately above it) is that some developers are not interested in implementing the suspend/resume hooks -- they are simply going to flag their apps as "does not background" and will hard-quit when you switch apps.
I don't think anyone is saying that iOS 4 isn't a big step forward. TJ was trying to make the point that the expectations around multitasking/backgrounding may not be realistic, mostly because they are not necessarily as 'free' for devs as Steve made it sound.
Happy to link to your feedback from the TUAW post if you like.
However, I disagree on several points. I re-read the article and feel that you don't mention state-saving and are very concentrated on only three backgrounding services, forgetting the others entirely which skews the plane a bit.
Also, I think developers ARE going to be VERY interested. When the app doesn't background (from what I've seen, the state-saving seems to be the easiest implementation) people are going to complain. I'm hoping that Apple have an identifier on the App Store to show it's multitasking status too. Developers want money. The public will wisen to the new functionalities, and market forces will force developers to update, if they wanna keep revenues.
Personally, I know I will be reluctant to buy paid apps in the future if they don't state-save.
Keep up the good blog.
You:
"Also, I think developers ARE going to be VERY interested. When the app doesn't background (from what I've seen, the state-saving seems to be the easiest implementation) people are going to complain"
TJ's post, a section that you quoted:
"With iOS 4, that oversight is going to be much more glaring especially since Apple is promising people that apps can remember where they left off. Starting with iOS 4, if your app doesn't do that, your customers are going to expect that you are working on a new version that will. Yes, even the gamers. Save your state and bring us back where we left off when we exited your application and you'll be ahead of most applications."
It sounds like you two are more on the same page than you might think; that's all I'm saying.
And TJ seems to be of the opinion that developers are opposing the new idea. I'm saying the opposite. I'm saying they will crave the new idea. People will demand these features; developers will bring it to keep their revenue streams active.
I know I am much more unlikely to buy an app now if fast-app switching isn't in use. Or any other multitasking API where appropriate.
At WWDC, Apple made it very clear that their iOS devices are revenue streams for developers. Developers will want to retain that. That means embracing new technologies and hardware.
Any developer that uses the iOS 4.0 SDK automatically gets state saving enabled. That alone should mean a lot of apps with updated functionality. A lot of apps won't even need to do anything at all to get this functionality. And the ones that do need work will need far less work than it would've taken under pre 4.0 devices.
He's citing another source that actually talked to game developers who have no intention of implementing suspend/resume or saved state; that's a specific data point. You're saying that your sense of the market is that developers would be well served to pick up these features and run with them; that's a prediction.
I'm not saying he's right and you're wrong -- I sincerely hope developers jump in with both feet. I think, though, that his original point is still valid: user expectations for multitasking are not necessarily aligned with what the reality is going to look like, at least in the near term. Apps will need to be relinked with the 4.0 frameworks, resubmitted and
One other slight technical point: I don't know if you've looked at the iOS 4 developer documentation or if you're basing your assessment off the public demonstrations, but [I am told by those who have read the developer docs] the background downloading capability you're citing is intended for short hold-overs of downloads that haven't completed when the app is asked to exit. It's not at all clear that it will allow for extended downloads over a long period while the app is not running.
> suspend/resume hooks -- they are simply going to flag
> their apps as "does not background" and will hard-quit
> when you switch apps.
Other developers will implement this immediately, get great reviews for it, and drink the milkshake of developers who don't. This is not the comatose PC industry, it's consumer electronics. There is competition.
You are wrong thinking that app state save/restore is now automatic. It is not. At any point in time, the "frozen" app may get unloaded from memory (too many apps running, or the more recent apps using too much memory). The "frozen" app is unloaded instantly, and not given any chance to run code.
Therefore, to properly save state, you still have to do it manually when the app is going from "active" to "frozen".
(If you don't do this, then, from the user's perspective, the app will behave randomly. Sometimes it will seemingly save state — the app became "frozen", then user returned to it; sometimes it won't — while being "frozen", the app got unloaded because of low memory.)
Could apps use it to attempt tasks such as background updating?
"What I found when I first installed the beta was that I quickly managed to have over a dozen running apps in the background burning up the battery."
Nope. The apps stay in memory, but are not run. There are no running processes for these apps, so they do not affect the battery in any way.
(The only apps that *do* run in the background are VOIP, audio or location-tracking background apps, which were only introduced in iOS 4. No apps currently available from the App Store run in the background.)
They even save state across the phone being turned off or even replacing your iPhone and restoring the iphone from backup! It's very cool.
I like it and don't want it changed!
Hopefully plenty of apps are updated to support it soon.
"He's citing another source that actually talked to game developers who have no intention of implementing suspend/resume or saved state; that's a specific data point. You're saying that your sense of the market is that developers would be well served to pick up these features and run with them; that's a prediction."
I've talked to developers and examined documentation unofficially. Developers want to use it (fact). I'm sure there will be a minority who don't want to, but (my prediction is) market forces will correct those opinions. Also, the docs show that recompiling to 4.0 specs is all that's needed for memory caching. That means, if an app does not use private APIs, a developer simply has to download the new kit, and remake their app and resubmit to get the new functionality. When it's that easy, the jump is going to be non-existant. The only time further work is needed is if private API's are used (which will break in the new SDK/get you rejected) or if you want to add other stuff on pause and resume, like the countdown in the Tap Tap Demo. That takes work - the basic functionality requires no extra coding.
"but [I am told by those who have read the developer docs] the background downloading capability you're citing is intended for short hold-overs of downloads that haven't completed when the app is asked to exit. It's not at all clear that it will allow for extended downloads over a long period while the app is not running."
I think the limit is ten minutes (although I have a feeling apps can request more at the end of ten minutes if needs be; don't quote me on that). That's ample time for the examples I gave in the piece. Do you think that's misrepresented? Even if you do, it's still multitasking functionality - neglected in the TUAW post.
NB: It's not just downloading content. It's anything that doesn't require user interaction. Be it downloads, heavy calculations, loading the next level of a FPS, CPU turns in a game of chess, audio (though this is better served by the background audio APIs), video. Anything. It's the most unrestricted part of the solution.
I love the fast app switching in iOS 4, but I'll make the argument that it makes life harder for developers. As pointed out by Anonymous, now apps will behave randomly. Whereas pre-4.0, you could be lazy and not save state, at least on every launch, the app did exactly the same thing. Now, sometimes it'll return to your previous screen and other times it won't. An average user will be unable to explain why.
"I love the fast app switching in iOS 4, but I'll make the argument that it makes life harder for developers. As pointed out by Anonymous, now apps will behave randomly. Whereas pre-4.0, you could be lazy and not save state, at least on every launch, the app did exactly the same thing. Now, sometimes it'll return to your previous screen and other times it won't. An average user will be unable to explain why."
Not quite. Pre iOS4, some apps returned you to the previous screen and others didn't. It's an idea that a lot of people understand already. iOS4 is just going to make it better.
I respect your view, but I detest you seeing the opportunity for developer laziness as a feature. That is terrible; the attitude reduces the quality of apps in the short, and long, term. Apple blocked the Flash app compiler for the same reason. It doesn't let devs be lazy; they have to be proactive, produce good applications and fight in the lucrative market that is the App Store. People complain because app quality is low; people complain when Apple tries and stops this.
Nobody wins.
For "saved state" apps to "survive" e.g. a device reboot there is absolutely no difference in the amount of work to be done by developers between OS versions 3.1.3 and 4.0?
"Now, sometimes it'll return to your previous screen and other times it won't. An average user will be unable to explain why."
Exactly. Which in the long run will force all app developers to implement state-saving to eliminate such jarring experience.
@Mikey
Correct. There is no difference. If you want real state-saving, you should implement state serialization by yourself (be it a .plist, or Core Data, or something else). And, with the new fast app-switching behaviour, you are practically forced to implement 1:1 state-saving, down to the state of each control on-screen — otherwise, we're back to the "random" experience discussed above. The days of "partial" state-saving are numbered.