Daniel Eran Dilger
Random header image... Refresh for more!

Ten Myths of Apple’s iPad: 9. It can’t multitask

Daniel Eran Dilger

Here’s segment nine in my series taking on iPad myths: no the iPad isn’t incapable of multitasking.

Ten Myth of Apple’s iPad: 1. It’s just a big iPod touch
Ten Myth of Apple’s iPad: 2. iPad needs Adobe Flash
Ten Myths of Apple’s iPad: 3. It’s ad-evil
Ten Myths of Apple’s iPad: 4. It was over-hyped and under-delivered
Ten Myths of Apple’s iPad: 5. It’s just a Tablet PC or Kindle
Ten Myths of Apple’s iPad: 6. It needs HDMI for HD video output
Ten Myths of Apple’s iPad: 7. It needs cameras
Ten Myths of Apple’s iPad: 8. It’s a curse for mobile developers
Ten Myths of Apple’s iPad: 9. It can’t multitask
Ten Myths of Apple’s iPad: 10. It needs Mac OS X

Dear rubes: 9. It’s a myth the iPad doesn’t multitask.

Okay, so this gets a bit tiring, but Apple didn’t design the iPhone OS “without multitasking capabilities.” The simple truth is that the iPhone OS inside the iPhone, iPod touch and the iPad explicitly multitasks all the time, using the same preemptively multitasking Mach/BSD kernel as the desktop version of Mac OS X.

The iPhone is constantly running processes that listen to the mobile network for incoming calls and texts, it runs an iPod process for playing back music all the time, it watches for background notifications being sent to idle apps, and there’s a variety of other things always going on. This is the definition of multitasking.

Understanding multitasking

A preemptively multitasking operating system appears to run multiple processes at once by very quickly switching between processes, a task managed by the OS kernel itself. This happens so quickly that several processes appear to be running at once, something like frames of a movie creating the impression of motion.

In many cases, the iPhone and its sibling devices are actually multiprocessing as well by running concurrent tasks on different processor cores. For example, when playing back video, the iPhone can spin off the heavy lifting involved with decoding H.264 to a specialized processor core while the main processor core continues to handle other tasks, such as listening for updates or maintaining the user interface.

A cooperatively multitasking system expects apps themselves to relinquish CPU control and share communal system resources in order to allow the user to work with several apps at once. The Classic Mac OS appeared to offer multitasking in this way, but if an individual app ever stopped responding, the illusion of multitasking immediately collapsed because the system might likely never recover.

With a preemptively multitasking kernel like the iPhone OS’s Mach/BSD, the kernel will simply take control back from a bad app and terminate it, or the user can kill an app that isn’t responding. In any case, the system continues to multitask without apps needing to cooperate; the kernel enforces this behavior.

iPhone multitasking

When less is more

A single-tasking operating system would be one that can only ever run one app at once, like the classic Palm OS or the original 1984 Macintosh. In both systems, everything was designed to only allow one app to run at once. The reason for this in both examples was to provide the foreground app with full control of all system resources at a time when there wasn’t much RAM or CPU available.

For similar “finite resources” reasons, the iPhone, while it is completely capable of preemptive multitasking, is artificially and arbitrarily limited from running multiple third party apps concurrently.

The iPhone OS does not launch a bunch of foreground apps at once because there’s no room for a windowing environment and insufficient resources to support multiple concurrent applications all trying to hog the processor behind the foreground interface that the user sees.

The iPhone is not a server and it doesn’t present multiple concurrent app windowing, but it does multitask.

Multitasking in a mobile environment

Most of the people talking about “multitasking” in the iPhone OS do not seem to understand what they are talking about. Using a single word to broadly cover up many nuanced details is simply not useful. What they usually mean to say is that the iPhone does not run any third party apps as background tasks, at least without first breaking its security model (via a “jailbreak”).

How well does this aspect of “multitasking” — actually “app concurrency” — work in a mobile environment? Well, the implementation is important. All multitasking models are not the same, so speaking of “multitasking” as a simplistic bullet feature is very misleading.

Microsoft proved what a dumb idea multiple app windowing would be in Windows CE / Windows Mobile. It launches multiple apps at once, each in full screen, overlapping windows. When you close a window however, it doesn’t necessarily shut down the process. And windows may be hidden behind other windows. It’s a mess, it robs the battery, it makes no sense to the user, and it does not allow any clever interaction between apps. It’s “multitasking” in name only, not in the sense of being useful.

In many ways, Palm’s original single-tasking Palm OS was better; the battery lasted much longer and it was more understandable to users. There was minimal need for users to have multiple apps running at once at the time anyway.

Google’s Android proved that copying Microsoft results in the same degree of success as Microsoft, at least in mobile devices. Sure you can “concurrently multitask,” as long as you want to trade usable battery life for the freedom to manage processes yourself and if you don’t mind gaining the ability to install spyware and spread viruses without even knowing it.

A top Android app is a tool to kill out-of-control multitasking. However, there’s no app for Android that can protect users from installing malicious background spyware and viruses. Apple built in a security system that makes those things virtually impossible to install under the iPhone OS.

So anyone who complains that the iPhone or iPad “doesn’t multitask” is simply signaling that they don’t understand what this means. Or, perhaps, that they want to muddy the waters to ensure that their readers not really understand what it means.

Inside Google’s Android and Apple’s iPhone OS as software markets

Mobile Multitasking

When Palm created its original operating system for the Palm Pilot 15 years ago, it licensed a third party embedded OS kernel in a single-tasking configuration. In other words, the Palm OS simply could not run multiple processes at once due to licensing limitations imposed on its kernel.

In contrast, Apple started with its own preemptively multitasking kernel and implemented a variety of background services to provide its iPod, phone, SMS, notifications, clock, and other background features all the time, regardless of the foreground app. But Apple also took the novel step of making the iPhone simple enough to work in an understandable fashion.

Rather than allowing users enough rope to hang themselves with a mess of background applications that aren’t obvious to the user, Apple designed the iPhone OS to launch apps in a sandboxed environment where apps can only see their own data. They can’t access the private files of other apps or reserved system information.

When the user hits the Home button or accepts an incoming call, iPhone apps must immediately quit. This prioritizes the needs of the user over the convenience of the developer, and forces programmers to build apps that remain ready to terminate at any time. Apps simply can’t ignore the user or the OS kernel and remain running in the background, whether they have good intentions or malicious ones.

iPhone 2.0 SDK: The No Multitasking Myth

Multitasking and security models

The only way apps can be run concurrently on the iPhone is by breaking its kernel-level security, which enables both the idea of running multiple apps in the background and also opens up the device to spyware and other malicious threats. You can’t have one without the other. That’s why the desktop Mac OS X and Windows XP/Vista/7 both expose users to a certain risk of malware that the iPhone does not.

The Mac is largely protected from malware problems by virtue of its authentication mechanisms; users can’t install background apps without presenting their admin credentials, and can easily scrub away any malware after it gets installed. On Windows, it’s much easier to get infected without even knowing it, and it’s far more complex to clean up a problem afterward thanks to the convoluted Windows Registry.

Forcing users to manage their own security in a mobile environment is even more complex, and the risks are more intense because pervasively networked mobile devices can do more damage. Without a vigilant security model like the iPhone OS presents, a mobile device gone rogue could send spam in your name at your own expense, it could report your position to some malicious follower, and it could expose your personal contacts, calendar, and messages in ways that never really become a significant problem on the Mac desktop.

Google’s Android Market Guarantees Problems for Users

Thinking about security for users

In developing the iPhone and iPad, Apple actually thought about what users needed to do and what they didn’t want to do, and used that information to create an experience tailored to the mobile, networked environment.

In contrast, both Microsoft and Google have essentially worked to bring the PC desktop to mobile devices without really rethinking anything, which presents the illusion of greater functionality while secretly delivering a massive dose of insecurity, risk, and complication.

Most users are not only unaware of this, but also lack the expert security credentials to adequately manage this extra complexity on their own. And they shouldn’t need to. Even on the desktop, mainstream users have been forced to deal with and suffer through security issues that they needn’t have.

In the new frontier of mobile devices, thinking about security is critically important, particularly given the multibillion dollar mess that everyone witnessed blossoming around the naive PC desktop.

It’s too late to grieve about PC viruses, but it’s not too late to act to prevent a similar crisis from becoming pandemic on our mobile devices as well. Apple seems to get this, while Microsoft and Google either don’t or don’t care.

Three exceptions to the iPhone app model

While Apple’s mobile-optimized iPhone app model makes more sense for most users than the Windows PC desktop mess that Microsoft simply dumped on its own mobile devices (or the hybrid model Google used for Android which opens up some benefits along with its can of worms related to security, manageability and usability), there are several exceptions that the iPhone did not accommodate.

The first and most prominent is that many apps want to stay active in the background just to listen for updates: news, incoming calls, status updates and so on. Following the initial release of the iPhone SDK, Apple introduced a cloud notification service to address this side effect of its restriction on third party concurrency.

Apple’s notification server allows the mobile device’s operating system to accept incoming requests for its non-running apps, and either badge them or pop up an alert so that users can launch the app and take action based on the update. This allows apps to respond to external events without requiring that they be running in the background all the time.

Apart from listening for notifications, there are at least two other reasons apps might want to multitask: one is to provide a background local user service (such as replacing the features of Apple’s bundled iPod app for music playback while another app is running) and the other is to serve external data while the app isn’t in the foreground (such as reporting the phone’s location to Loopt or Google’s Latitude server).

iPhone Push Notification Server tied to Snow Leopard Server

Addressing exceptions in Apple’s iPhone OS app model

It’s widely expected that iPhone 4.0 will introduce a new mechanism for enabling specific third party apps to run in the background, either to provide an always on local service or to act as background external server of some sort.

Either option would rob the system of CPU power and memory, resulting in problems that most users would blame on the iPhone itself, rather than their own use of it. Which is, of course, why Apple restricts the way third party apps run.

The most prominent of requests for app concurrency relates to Pandora Internet radio and Latitude-style updates, both of which Apple could add to its own set of bundled apps and simply allow third parties to access as a system wide service.

For example, adding radio feed support to the background iPod process could enable third party apps to tap into it to provide a unique user interface that can play music that continues even when their app is quit.

Latitude or Loopt could similarly use a central OS service that reports the user’s location at a given interval. Those third party services could also send notifications to their app when other users send a messaging request, allowing the services to work even when the third party app isn’t actually running.

Most other needs for third party background tasks could similarly be rolled into the core OS, enabling the kernel to manage how much time to devote to those tasks itself rather than according background apps all the resources they demand as they run in the background, irrespective to what the user is trying to do in the foreground.

Engineering vs. marketing

As it is, Apple’s existing single app model (with notification exceptions) makes a lot of sense as a way to keep things secure and easy to understand for users. That’s especially the case right now because the iPhone and its generation of smartphones isn’t really capable of unlimited app concurrency or acting as a full-time server.

What about the blazing fast iPad? Well it certainly didn’t beg for multiple apps to be running in the background when I tried it, but anyone who wants to install a background process will probably get the opportunity within weeks of its release thanks to iPhone 4.0.

And again, there are a variety of ways Apple could roll out general background services that all third party apps could access without actually opening the floodgates and creating the potential for apps to do things that users must manage themselves.

Apple’s multitasking model for the iPhone and iPad really represent a triumph of engineering (making tough decisions to provide the best overall experience) over marketing (communicating to users that you’ve done a great job). After all, if Apple had made easy, populist decisions to satisfy the pundits first, the iPhone and iPad would face the same problems as Android.

Sure, the company would be getting less grief from sloppy incompetent journalists, but it would have also delivered a much less functional product that was harder to use and easier to exploit. As it is, users have their choice whether they want Apple’s product or Androids’s, and choice is a good thing.


1 Ten Myth of Apple’s iPad: 1. It’s just a big iPod touch — RoughlyDrafted Magazine { 02.17.10 at 12:56 pm }

[…] iPad: 7. It needs cameras Ten Myths of Apple’s iPad: 8. It’s a curse for mobile developers Ten Myths of Apple’s iPad: 9. It can’t multitask . It really didn’t matter what Steve Jobs said, anymore than it didn’t really matter […]

2 Ten Myth of Apple’s iPad: 2. iPad needs Adobe Flash — RoughlyDrafted Magazine { 02.17.10 at 12:56 pm }

[…] iPad: 7. It needs cameras Ten Myths of Apple’s iPad: 8. It’s a curse for mobile developers Ten Myths of Apple’s iPad: 9. It can’t multitask .. Dear Adobe: 2. It’s a myth that the iPad needs […]

3 Ten Myths of Apple’s iPad: 5. It’s just a Tablet PC or Kindle — RoughlyDrafted Magazine { 02.17.10 at 12:56 pm }

[…] iPad: 7. It needs cameras Ten Myths of Apple’s iPad: 8. It’s a curse for mobile developers Ten Myths of Apple’s iPad: 9. It can’t multitask . Dear old school pundits: 5. It’s a myth the iPad is just a Tablet PC or Kindle […]

4 Ten Myths of Apple’s iPad: 8. It’s a curse for mobile developers — RoughlyDrafted Magazine { 02.17.10 at 12:57 pm }

[…] iPad: 7. It needs cameras Ten Myths of Apple’s iPad: 8. It’s a curse for mobile developers Ten Myths of Apple’s iPad: 9. It can’t multitask . Dear WSJ: 8. It’s a myth the iPad will “curse” developers. Yukari Iwtani Kane, who is […]

5 gus2000 { 02.17.10 at 1:24 pm }

I can’t tell you how many times I’ve had to [facepalm] because some n00b on teh internets proclaimed that the iPhone “can’t multitask because it isn’t multicore”. Huh? Comprehension fail.

I hope you’re correct about Mobile OSX 4.0 being less modal. Something I do frequently is to chat/Skype with someone while using the Web or some other app. Sure, the iPhone can make a call while I open another app, but there is no phone on the iPad.

Doesn’t really matter, though, since I will be getting an iPad on launch day regardless. :)

6 ulicar { 02.17.10 at 1:35 pm }

This reminds me of Android multi-touch capabilities. Apparently, Android is multi-touch phone, but it is not enabled, unless cracked. Does that mean it is multi-touch, or does it mean it is not? In my opinion, if the feature has been artificially disabled by the provider like in the case of the Android multi-touch is it is not multi-touch. If my car is electronically speed limited to 150 mph, does that mean my car is faster than 150 mph or does it mean it is not?

Apple does not provide multitasking for third party developers, even if artificially disabled, therefore it is not multitasking. Sorry. There might be reason that Apple wants us to have better experience, quite possible, but it is also possible that apple doesn’t want us running skype in the background. Who knows?

Anyway, OS maybe has everything needed, but it is not enabled unless cracked, so it is not multitasking. If you are hungry and the food is in the other room under the key that you don’t have access to, does that mean you are no longer hungry? Nope. It means you are still missing the food like iPhone OS is missing multitasking.

7 danieleran { 02.17.10 at 1:43 pm }

@ulicar: “multitasking” is a feature of the operating system, not the ability of the user to SEE or HEAR the results of more than one app at a time. The iPhone OS uses a multitasking kernel, it multitasks a number of services all the time, it just doesn’t support running third party apps as background processes. That is not the definition of multitasking at all, so using that word is either ignorant or an attempt to create confusion.

I don’t want to feed your trolling, I just want to clarify that you are either choosing to use the wrong word to create confusion, or you don’t understand the issues involved.

8 TheMacAdvocate { 02.17.10 at 1:44 pm }

You could have called this entry “I Don’t Think That Word Means What You Think It Means”.

9 Berend Schotanus { 02.17.10 at 2:09 pm }

Already at no 9 out of 10 iPad myths, it is amazing how much skepticism en hostility Apple meets about things that in the end appear to work extremely well.

Following this series (and previous ones) I did some thinking about where these feelings might come from. My guess is that at the bottom of it all Apple really has a different worldview that both make their products so good and is the reason for all this resistance. See:

10 davitron { 02.17.10 at 2:49 pm }

I would be very interested by a discussion about multisession.
It may not be necessary to have much background application.
But it may be useful to keep the data of an application in memory when switching to another one. Saving a state and reloading it takes a few second that are sometimes boring.
In one way, Apple forced the developper to design application that must constantly be able to save their context at any moment when the user pushs the home button.

This approach has a lot of virtue because every pratical application will take that in account by design.
This is what we can see on the iPad when every modification of an iWork document are immediatly saved.
And it works perfectly and very quickly for the mail.

I suspect that iPhone OS4 will improve this multisession issue by speeding up context saving and providing a real multisession mechanism.
This and a ressource sharing mechanism for documents would be a great adding.

11 HCE { 02.17.10 at 2:51 pm }

My biggest issue with the lack of third party app multitasking is the way in which the iPhone handles switches between GPS and phone calls. If I am being guided by the GPS and a phone call comes in, the call should go on in the background and the GPS should continue guiding me in the foreground. If I need to, for some reason, foreground the call, then the GPS program should continue running in the background, and not get killed. My beat-up old Garmin GPS can do this. It is ridiculous that the iPhone cannot. I hope iPhone OS 4.0 addresses this problem.


12 tsenecal { 02.17.10 at 3:02 pm }

Given the small screen real estate of an iPhone or an iPod touch, I can see why it just doesn’t make real sense to have 3rd party applications running at the same time. there just isn’t enough room for everything to been seen.

the iPad is a different animal, with 6 times the display area… literally, its display is as large as the second generation iBook.
so, without further rambling…

why I won’t own an iPad:

I was able to run a calculator and a word processor at the same time 25 years ago on my original Macintosh.

I would think that a 2010 iPad with 60+ times the horsepower would be able to do the same thing.

[Yeah but your original Macintosh didn’t multitask at all. And when the classic Mac OS did get the “MultiFinder” feature, it wasn’t real preemptive multitasking like the iPhone OS.

Perhaps what you should wish for is desk accessory widgets. You might also contemplate why the iPad didn’t demonstrate a freestanding calculator app. Perhaps Apple has already thought about that. – Dan]

13 donarb { 02.17.10 at 3:07 pm }

Another problem with allowing 3rd party apps to run in the background is prolonged memory leaking. The new Palm’s have been having so many problems with apps leaking (even from Palm themselves) that someone has now created an app that will reboot the phone on schedule.


14 zdp { 02.17.10 at 4:38 pm }

It’s interesting to me that Apple is being kicked in the nuts for each of these myth items, while I have read nothing but praises for the Windows Phone Series 7, which AFAIK does not allow 3rd party background processes OR have Flash on it.

I am excited to see what Apple comes up with…. As I have been learning the iPhone SDK, I have come to realize that Apple has not just thrown it together, but has taken a lot of time trying to make Apps easy to create and use.

15 John E { 02.17.10 at 5:13 pm }

i get Dan’s points. but there is one other big thing not addressed that actually i think is the most important of all to most users: switching back and forth between apps. which appears like multi-whatever but doesn’t really have to be.

right now, Apple makes you return to the home screen to switch apps every single time. but often you just want to bounce back and forth between two – like maps and yelp, or maps and google search, or wikipedia and google, my most common pairs. or a game you’re into and anything else you need momentarily. i’m sure everyone has situations like this often too. having to bother with the home screen every time is a pain. having to wait for a game app to reboot is a pain. and so on.

correct me if i am wrong, but all that is actually needed is to save the app’s RAM state when you want to go to another one, right? so you could go back to it and pick up exactly where you left off. that app is actually not “running” in the background in that case, is it? more like put to “sleep.” there just needs to be enough RAM …

all that would be needed then is some option to “go back to last app,” like clicking the home button three times. then you could bounce back and forth between two apps directly.

or is this all wrong somehow?

anyway, this is the one thing it would be great to see Apple fix, however.

16 ChuckO { 02.17.10 at 5:32 pm }

zdp 12, Great point. Sites like Engadget are falling all over themselves praising Windows phone 7 Series (holy toledo). Even Seth Weintraub at 9to5 Mac said it looks cool! The interface looks RETARDED! Sorry Sarah.

17 ulicar { 02.17.10 at 5:33 pm }

Well, if nobody but Apple is able to use OS “multitasking”, than it is not multitasking, now is it? I have Master of Technology. I know what I am talking about. I am not trying to confuse anyone, you are doing that, buy trying to sell the operating system which is obviously multitasking, but nobody can use it except Apple, as multitasking operating system.

If your car is limited to 150 mph does that mean it is faster than 150 mph? No, it means that the top speed is 150 mph, the same goes here. If nobody can use it, unless cracked, it is not multitasking. There you have it.

18 ijoyner { 02.17.10 at 5:41 pm }

Thanks for the article. I spent a lot of time a few weeks ago on sites like CNet trying to correct these people.

If iPhone/iPad is missing anything, it is garbage collection – not that the user gives a fig about that. But it would kill all memory leaks which arise because of programmer error. Why do programmers make errors? Because all the retain-release code is complicated and easy to make a mistake. It clutters the code with non-functional stuff, ie., does not contribute to the task at hand and is just overhead and bookkeeping.

I can understand with lack of memory (and possibly CPU cycles) resources on the iPhone why it has been left out, but I hope full Obj-C 2.0 is done on the iPhone/iPad sometime, especially as we just got this great new thing on Obj-C 2 on Mac. Frequently terminating apps on the iPhone certainly obviates the need for GC somewhat.

19 mikeg { 02.17.10 at 6:04 pm }

Great article as usual. I am not sure what you have planned for Myth 10, but there seems to be a number of articles coming out about inefficient bandwidth usage and how the iPhone and iPad will create havoc for the world’s 3G infrastructure (my words) and will result in the need to allocate additional spectrum to meet demands. I’d like to get your insight in the topic either as the final Myth installment or in a later RDM installment.

20 ijoyner { 02.17.10 at 6:08 pm }

Ulicar. Your food analogy breaks down. Food is a resource – like a battery (exactly like a battery). Your task is to make it last. If you let all the hungry people into the room at once, resource is quickly gone. If you control access everyone is happier for a lot longer – Hmmm capitalism and market economy really doesn’t work (well maybe)! That is Daniel’s point, it is controlled multitasking – you get most of the benefits (maybe lose a few), but don’t have the problems (resource depletion and security problems).

In fact, a most serious resource depletion would be lack of memory – once all those multitasking applications fill memory, the system would start thrashing and then your battery would be wasted just shoveling things in and out of memory with very little useful work being done – a very miserable user experience. Dealing with a system in this condition takes sophisticated monitoring and supervision. That is beyond most users. Apple want self-administering systems, systems that work well in a variety of conditions without user intervention. Windows as we know craves attention and this is a costly waste of time and resources.

When trade-offs are made you can easily make criticisms, but I think Apple mainly have it right – of course they will fine tune things as they go.

So do Apple make trade-offs instead of sticking to their principles? Well I leave you to think about it since I’m thinking about that myself. But I’ll say that in an environment of limited resources, you have to make compromises. In an environment where malicious people are trying to compromise your security and system, compromises must be made. Making life impossible or at least difficult for hackers usually means that the user must be inconvenienced as well, by at least having to type in passwords, etc.

21 ulicar { 02.17.10 at 7:08 pm }

@ijoyner you absolutely understand what I am talking about. The operating system does have CAPABILITIES to be multitasking, but those CAPABILITIES are limited to only Apple software for whatever reason. I accept your explanation of why it is setup like that, that is not topic of this discussion. The point stays, if you cannot get to the food, you will stay hungry, unless you break in, which is what jailbreakers are doing. That is all. We cannot say “we have as much food as we like”, when that food is not available to anyone but a selected few. That is my objection in the whole this “it is multitasking/it is not”. It is CAPABLE OF multitasking OK, but nobody except Apple can use that CAPABILITY. The rest will have as much food as Apple decides is OK. Therefore, it is not multitasking, is it?

22 ijoyner { 02.17.10 at 7:17 pm }

Mr Ulicar. I see your point, but the analogy is too simplistic. But if you develop applications to run in a preemptive (modern) multi-tasking OS, you are exactly being limited by the OS as to how much food you are being given.

Note multi-threading within applications is still available – it needs to be so the user can have a responsive app while doing things like downloading from the Web.

Start another app – all the non-GCed objects as well as threads go away, until you start up again and resume where you left off. In general there is no need for parts of a user app to continue while another app is running.

Other functionality is decided on a case-by-case basis, like continuing to play music, receiving notifications that require the attention of another app not running. That seems to cover exactly what is needed in small hand-held devices.

23 FreeRange { 02.17.10 at 7:18 pm }

@ ulicar – you may have a “masters of technology” but that obviously doesn’t make you the brightest bulb in the room, not does it stop you from being tone deaf. The iPhone has multi-tasking, is constantly doing multi_tasking, but does so within limits to protect the user and optimize performance. In fact, even the iPhone’s push notification service is multi-tasking. This is not a complicated concept. Your idiotic rant is just that. Stop trying to over-intellectualize as its making you look silly. BTW, I have a great mobile OS I’d like to sell you, Windows Mobile, or we have a new vaporware flavor for you but I can’t seem to remember its gazillion word name….

24 miloh { 02.17.10 at 7:44 pm }


“If I need to, for some reason, foreground the call, then the GPS program should continue running in the background, and not get killed.”

That would depend greatly upon the specific application. Unless something is lost by killing a program, there is no benefit to keeping it running in the background. In the case of the standard iPhone Maps application, I’m not aware of anything being lost by shutting it down. Whatever I was doing previously is restored when I restart it, and my position is updated via a new GPS reading. I don’t see what running it in the background would gain me.

Now for something like Google Latitude where one’s position is being constantly transmitted to a remote server, that’s a different matter. Terminating that would cause position updates to cease.

25 Donald { 02.17.10 at 8:22 pm }

@ ulicar
“Well, if nobody but Apple is able to use OS “multitasking”, than it is not multitasking, now is it?”

Actually the definition of multitasking has nothing to do with how many people can use it! Rather “multitasking” is concerned with the capability of having several things run at the same time.

In the same way that a six-lane “freeway” continues to be regarded as a “freeway” even if 3 of the lanes are deliberately blocked by the transportation department, a multitasking operating system is still “multitasking” even when it does not allow unlimited multitasking.

From a practical standpoint, however, I think most people will be more interested in knowing that the system allows them to “multitask” in certain identified activities (i.e., those where it’s most reasonable to be able to do so) than having multitasking permitted for every conceivable situation.

26 ijoyner { 02.18.10 at 12:22 am }

Donald. Your analogy of the freeway also breaks down like Ulicar’s. Of course a six lane highway with only one lane open is useless (or next to). These analogies don’t really relate to multitasking – the lanes actually relate to the number of processors, not the number of tasks, since the tasks must be single threaded onto a processor anyway (hence why Dan keeps saying the critics really don’t understand what they are talking about… I think anyway, correct me if I’m wrong).

What I have argued in other forums is that you should not start from the technology (ie., the requirement is multitasking), but analyze what the real user requirements are. This is true domain-driven design, not technology-driven design. So I actually agree with your conclusion. That is why Apple is so successful in this market space – they ask the question “Well what will users of this device really want to do?”

27 tonortall { 02.18.10 at 12:25 am }

I wonder who is being more evasive on the matter of multitasking. On the one hand, it is undeniable that the OS supports that behaviour: otherwise the telephony would not work, for a start. But in practical, user centric terms, this is a strained distinction. At the user experience level, multitasking, while present, is a crippled construct on the iPhone.

The “solutions” to overcome the lack of the facility for third party apps are poor. That Apple would offer the notification “solution” is at the very least a nod to the idea that users would like to have some kind of concurrency in their use of application. If the principal argument is to preserve battery life, then the notification “solution” is an absolute fail. I absolutely believe that “solution” in this context belongs between inverted commas.

There is no doubt that badly or maliciously written software is unwanted. Apple however do have their app store approval process which is designed to weed out the worst of it at the very least. I don’t understand why you equate the lack of third party apps being able to run at the same time to being some undetected malevolent beast. There is nothing to stop foreground apps from doing exactly the same things. I’m not going to wade through the SDK, but I think you are making a strained connection in this respect. I would hazard that the decision to have a single third party app running is far more a practical nod the choice of interface than any security bogeyman.

I am sorry I wade onto this site to try and provide a counterpoint to what is obviously an Apple cheerleading site, but in particular, I find this part in your series particularly grating. It appears to be a justification for a shortcoming rather than any critical analysis as to why, in user centric terms, multitasking is not present on the iPhone OS.

28 srihari { 02.18.10 at 12:50 am }

Excellent Article…Really highlighted a lot of issues on why Multitasking is not a vice adventure for the moment…But i am sure this will not stop apple to stop thinking about the ideas on how to go by a safe way to implement it……I am really looking forward to upload my Videos to youtube in the background and also some reading @ the same time….

29 Michael { 02.18.10 at 1:12 am }

Some people don’t understand the difference between computer multi-tasking and user multi-tasking. Yes, the iPhone does multi-task. No, it does not allow a user to multi-task outside of Apple’s core applications. It’s all a matter of perception.

Like other people, I also believe Apple may allow user multi-tasking in iPhone OS 4.0, but limit it in the following ways…

1. Users will have to explicitly request that an application remain open. Simply pressing the Home button will quit the application as it always has. I’d guess there will be a new system wide gesture that brings up a “task” view, could very much resemble switching between web pages in Mobile Safari.

2. Once in the background, the application will be limited to running a single thread, which must not have any UI calls. Possibly, the system will send the application an applicationWillLoseFocus message to allow the application to specify which thread to keep running or to create a new thread. If the application does not respond to the message, then it will just remain completely dormant. Just before the application is brought back into the foreground, it will receive an applicationWillGainFocus message, to allow the application to update its views based on any background processing.

3. This will only be available on 3GS and newer devices; trying to run more than one application on a device with only 128MB would be impractical. The number of open applications may also be limited to only a few at a time.

Another route Apple may go is to bring Dashboard to the iPhone OS. Allow users to run a limited set of widgets in the background.

30 Michael { 02.18.10 at 1:44 am }

@ tonortall

I agree, there is no facility for foreground applications to misbehave so we can assume that an application in the background would have the same restrictions. And I’m sure it was a design choice based on limited resources of mobile devices; memory, battery, screen size, etc.

However the Push Notification Service is a valuable advantage and battery life is just one thing that can benefit from it. If I have messages coming in from a dozen different services, I don’t need to have 12 different clients running with 12 different ports open. Instead, there’s just one process, listening to one port. That’s both a security and performance advantage. It also keeps the network chatter down, which can save battery life as well.

31 gctwnl { 02.18.10 at 2:00 am }

Excellent article. I think this is not so much an engineering over marketing triumph, but a user experience over engineering issue. I’ll repost something I wrote a while back on the AppleInsider forums:

People who think SJ is a ‘marketing guy’ misunderstand him completely. SJ is a ‘user experience guy’ and has often done things that fly in the face of marketing wisdom (with hits (iMac w/o floppy, expensive iPhone) and misses (NeXT restricted to higher ed, G4 Cube). And next to being ‘user experience’ driven he is also a ‘sales guy’. But his effectiveness at selling an idea/solution is hard to separate from its basis in ‘user experience’ which by and large also sells itself. You can see SJ making marketing mistakes, but even his market failures have been user experience triumphs (the NeXT was decennia ahead of the competition in user experience).

Gates is a rather basic nerd who is also a great marketing strategist. The success of Microsoft has been documented perfectly by him in his book “The Road Ahead”, where you can read how marketing and strategy is what made Microsoft great. He has no feeling for user experience (what SJ calls a lack of ‘taste’ on Microsoft’s side) and no true understanding of the limits of technology in that respect (think about the billions Microsoft spent on AI-like programs which brought nothing). In Microsoft’s defense, innovating when you depend so much on OEM’s is difficult, it is part of their position that true innovations in user experience are very difficult. Still, I think SJ has a far better feel for technology than BG, who has always impressed me as being a truly exceptional strategist while being a mediocre technologist.

Many pundits complain about technical iPad details, like the lack of a camera, or the wide bezel which they think is ugly. The wide bezel is however important for the user experience of holding the device in one hand and working it with another. And the camera in the top of the bezel would not be a perfect user experience (front facing, it would mean you are being displayed in a unflattering angle and if you turn the device your hand might be in the way, back facing it would be a rather unwieldy camera to handle). I expect different future solutions for the camera option (e.g. a front facing camera ‘behind’ the middle of the screen).

The iPad, as a first in a new category has many compromises in its design for the multiple aspects of user experience (e.g. battery life versus unlimited background apps). The question is not if there are compromises (there are) but if the end result offers a great user experience for enough types of users. From what I have seen, I think it will.

32 gctwnl { 02.18.10 at 2:01 am }

Summing up: It’s the user experience, stupid!

33 pronk { 02.18.10 at 2:08 am }

I’d say the problem here is not that people deliberately misunderstand what multitasking is to bash the iPhone, but that Daniel is having to take a very literal definition of it to make a point.

Yes, the iPhone can multitask in the sense it runs multiple tasks simultaneously. But to the vast majority of end users that is too limited and they do not “see” the multitasking. They cannot, for example, play a game, then take a call, then go back to that game where they left it – the app has to restart. They cannot have a map open, then flick to, say, a metro map in another app to check something, or maybe a restaurant review, and toggle between the two. This often leads to apps having to duplicate functionality to stop people having to quit out and restart, and inevitably leads to app bloat as a consequence.

All that said – I have an iPhone, I love it. The lack of being able to run third-party apps is occasionally irritating, but I don’t mind it. I don’t use pandora or IM clients, so that aspect certainly never bothers me. But it’s this lack of being able to run such third-party apps that most people understand as multitasking, or more accurately the ability to simultaneously run *any* apps the user chooses whether they’re third party or not, and no amount of insisting that one definition is adhered to will make that change. The iPhone doesn’t do that, and until it does most people will consider it cannot truly multitask.

Sorry, Daniel – you could have said “I just prefer it this way” for all the perfectly valid and good reasons of battery life, speed, safety and so on. But making it primarily into an argument about semantics makes it look like you’re scrabbling for reasons to dismiss criticism and those who make such criticisms for the sake of it.

34 ijoyner { 02.18.10 at 3:05 am }

Tonortall: “I wonder who is being more evasive on the matter of multitasking. On the one hand, it is undeniable that the OS supports that behaviour: otherwise the telephony would not work, for a start. But in practical, user centric terms, this is a strained distinction. At the user experience level, multitasking, while present, is a crippled construct on the iPhone.”

Well, we don’t need to use mindless adjectives such as “crippled” in a technical debate – hey I just used the “mindless” adjective myself – what recursive madness ;-)

In user-centric terms, is this a strained distinction? I think not. What happens in a multi-tasking desktop system? The user actually only interacts with one application at a time. If you switch to another application, the system carefully saves the stack state and switches the processor to run the new application. When the user swaps back, the original application’s state is restored. This is all done by stack manipulation, where top of stack elements may be mapped to real processor registers. (I’d love to give a lesson on stack architecture here and how it is the best for multi-tasking OSes, but suffice to say Burroughs was right, Hennessey and Patterson were wrong.)

The iPhone has a slight variation on this – when the user swaps to a different application, your application is informed and it must save its own state. Now that sounds onerous, until you realize that you have written the code to save the state anyway at application save and quit time. So a different application runs, until the user swaps back to yours. Your application restores its state. Another small difference is that while a desktop application has its state saved in main memory, and iPhone application has its state saved to flash memory. In a limited memory environment this is very desirable, because you don’t want a thrashing system (a system that crawls to a virtual halt, scuse the pun).

There is actually another advantage to this – if your application crashes (heavens forfend), you at least will most likely have a recent persistent version of the state. As already mentioned, this might also cure memory leaks in the absence of GC on the iPhone.

Thus, as far as the user is concerned the iPhone application switching is behaving exactly the same as a desktop and thus appears to be multitasking just the same at that level.

This is not making strained distinctions. This is not just playing with semantics.

Pronk: “Yes, the iPhone can multitask in the sense it runs multiple tasks simultaneously. But to the vast majority of end users that is too limited and they do not “see” the multitasking. They cannot, for example, play a game, then take a call, then go back to that game where they left it – the app has to restart.”

As I have just explained, the user can play a game, take a call and return to the game exactly where they left it. Sure the app restarts, but it restores state – at least it should do – if it doesn’t it is the fault of the app. This is in the app development guidelines – break them and do so at your own (or the user’s peril). As far as the user is concerned the magic has happened by a slightly different slight of hand, but like magic, the user does not see what has really happened, only sees the result – that is the magic of computing.

35 ulicar { 02.18.10 at 3:29 am }

@everyone No it doesn’t. For example I want to download something bigish and I would like to play some game while it is doing it. Can I do it? No. Why? Because OS will not let me. Why? It is not a multitasking except for very limited number of applications. It is capable of doing it, if you jailbreak it, then you can kick several processes and use some nice apps to manualy kill them if you like.

It is CAPABLE, but it is not. There is a huge difference.

36 mailjohannes { 02.18.10 at 3:35 am }

It is a clever solution to extend the API to background server apps (or daemons).
Extending the core facilities of the OS is the right way I think.

But another type of solution to the background app problem is possible.
Unix operating systems use ‘nice’ and ‘renice’ to kind of throttle the CPU bandwidth used per thread (or process). Nice and ‘renice’ isn’t working as well as it could – at least on all Unixes (including Linux) I know of – but it is possible to implement real CPU bandwidth throttling.
This is not a trivial kernel extension and it will take time to implement it.

With CPU bandwidth throttling it is easy to restrict all background apps to a maximum of (say) 10% CPU performance. This will guaranty enough cycles will be available for powerful foreground apps and system services, but it will also allow for third party background apps without performance degradation or user management.

Even Apple itself can use the enhanced kernel to achieve better (guaranteed) performance for its own apps and system services.

This kernel enhancement is not easy to do, even for Apple, but it would be a true long term solution to the performance problem in general and the third party background apps in particular.


37 tonortall { 02.18.10 at 3:47 am }

@ijoyner: from a comp sci point of view I am sure you are correct. All the talk of stacks and states is completely irrelevant, however, to the person on the other end of the finger pushing the buttons on the device.

One use-case in particular which would benefit from multitasking is GPS tracking – even this could ameliorated by the OS continuing to log GPS data for a certain period of time after an app using GPS is stopped. That way the app when restarted could potentially catch up. I log all my runs but I absolutely cannot take a call during a run if I wish to maintain an accurate log of my runs.

If you are familiar at all with any of the games that are offered for the iphone you would know that, in particular, the first person shooter types can take a considerable amount of time to load, even for 3gs. Add to that the restoration of state and the user experience is – well – sluggish. I don’t own many of these games myself but the saving of state is not something I have come across for this genre, at least not in the sense of restoring a ‘preempted’ state.

My reference to the notification paradigm is based on the fact I switched it off after two days because I was getting half day battery life as a result. This is my personal experience and I am sure others will chime in and call me on it, but I turned off push notification. We don’t know whether multitasking (again in the user-centric understanding of the term) is better or not, but as a “solution” it was less than optimal for me.

In sum – multitasking as a term is understood by the majority of people these days as the ability to run multiple applications of their choice simultaneously. I know that a purist view suggests otherwise – and this article pursued that line.

But really, people don’t care.

Either they don’t care because the whole concept of multitasking in either sense is meaningless to them , or they don’t care because accepting the definition offered in the article doesn’t provide a satisfactory answer as to why they can’t run pandora and surf the web at the same time.

38 ijoyner { 02.18.10 at 4:01 am }

Ulicar, that actually is a very good example of being able to download a big file in the background and go away and do something else.

I believe mailjohannes addresses this with a possible solution, but that is in the future. Perhaps at some stage Apple will provide an API in order for an application to fork off an independent process as a daemon – a small bit of code, not memory intensive, so the main application can quit memory and let another user intensive application begin. Current multi-tasking that leaves whole applications in memory will just grind anything with less than 1GB main memory into the dirt.

That is one solution. Another may be that Apple still does not want malicious daemons installed, so does not go this route. But they could implement their own download daemon that applications can access.

There are other solutions other than the troublesome desktop full-multitasking one. Updates are always coming and we can only guess, but I’d rather the security and guarantee that the system performs well, rather than gets into a thrashing situation. If the system thrashes neither your download or your game will go very fast and will just leave the user with a frustrating experience.

Most users can accept the fact they can’t do a download while playing a game, and just reorganize their priorities to match. But maybe this will be a short-term restriction. That is still better than thrashing – have you ever been in control of a system to try to clear the thrashing bottle neck? This kind of system tuning is way beyond the normal user, requires understanding of process swapping and priorities.

I could also ask, what are you going to do with the big download? Each iPhone app stores its files in its own sandbox. Other apps cannot access these files and it cannot access other apps files. Thus if you download something big, what is going to process it?

Now there are pros and cons of this. No doubt the anti-Apple shrills will beat up on the cons and fail to see any of the pros.

Sometimes Apple seem slow to come up with solutions, but they are taking the cautious route and in the end come up with really good solutions, even though they might be quite different to widespread industry beliefs. It is probably that slaughtering of beliefs that makes them so hated in some quarters.

39 ijoyner { 02.18.10 at 4:21 am }

Tonortall – the talk of stacks, etc is not irrelevant when I’m taking the time to explain to you how this stuff really works. It’s not a purist view at all. In fact, it’s trying to point out that Apple are being practical. Those advocating holding multiple applications in memory at the same time are actually being the purists and not being practical.

I particularly actually agree that it’s irrelevant to end users – that’s exactly the point I’m making! Applications are not actually running simultaneously on any system (except those with multi processors) – that is an illusion – they are actually taking small chunks (about 1/1000th of a second) of processor time. The stack switching is quicker than the eye.

The point of applications is that the user only interacts with one at a time. That is true also on any desktop system, Cocoa- or MFC-based.

The OS must manage the resources. In a small form factor, you can only get small memories. Apple roughly knows the memory profile of an average Cocoa application. It is obviously better to limit the iPhone to a single application at a time, or the memory resource becomes short and you get massive responsiveness problems.

It is interesting that you managed your battery resource by even turning off notifications. Apps running in the background would be even worse. So I think you are answering your own criticisms somewhat.

I also think you have a good example of being able to log GPS data while on the move and running something else – although this sounds like it could be quite dangerous. However, I think a case-by-case approach is better than using the sledgehammer of multi-tasking – that’s the Microsoft approach.

40 davitron { 02.18.10 at 4:37 am }

Nevertheless, it may be useful to enrich to current API in order to make easier and faster the saving and restoring of an application context.
I am always surprised how fast it is for mail or the Appstore comparing to other third party applications.
I am not an iPhone developper (yet) to know if it relies on private API and if the current public API is rich enough for the developpers to implement this efficiently.
By the way, even on desktop system, virtual memory can swap seamlessly data from RAM to disk. May be this behaviour could be possible for context switching on iPhone.

For background downloading, this is typically a functionnality that should be managed by an Apple service, provided system wide by an API, in a download queue.
This is done already done for AppStore downloading.

41 tonortall { 02.18.10 at 4:44 am }

Ijoyner – I do come from an IT background and did touch on OS design during my degree so I appreciate you taking the time to explain it to me – although it’s not necessary.

In the end, its not the lack of multiple simultaneous third party apps that irked me (there are, for the most part, adequate workarounds) – rather it was the reasoning for the lack of it that I found wanting.

As to background apps making things worse v. notifications: I don’t think anyone’s in a position to make a proclamation on that point as the comparison can’t really be made. Well, not with a vanilla iPhone OS, anyway. I think that conclusion should really be left open.

Anyways, bedtime my part of the world. I’ve enjoyed the discussion.

42 ijoyner { 02.18.10 at 5:08 am }

Davitron: “virtual memory can swap seamlessly data from RAM to disk.”

Well, yes and no. The application has no idea this is happening, and generally, the user won’t either – except when the system is stressed and thrashing. On a small memory like iPhone that is very likely. You also need a huge file on disk (on flash), which might just take up the rest of your available flash. Now I can’t say how the in-built virtual memory on Mac OS X works on iPhone, but I suspect the small amounts of memory and persistent storage make this very restricted and the user will start to notice performance degradation, which means it won’t be working seamlessly, but the user won’t know the cause of the degradation.

Actually, I do know that applications do receive low memory warnings and if they don’t clean up by freeing resources, they are terminated. So that gives a good clue that virtual memory is not really working on iPhone.

43 ijoyner { 02.18.10 at 5:22 am }

Hi tonortall. Thanks for the interesting discussion. It is also bed time here. Since you are an IT guy – I’ll speak slowly ;-) Sorry cheap shot and it is late so my humour is probably a bit off at this time of night, but so many IT people only know what they are taught on courses and then learn in IBM/Microsoft environments, that of course they get things wrong – not that that’s you of course.

Anyway, thanks for the appreciation, but I’m not just patronizing you with an explanation, but using it as a discussion for the millions of people that read Roughly Drafted to see, and I hope it’s interesting for them.

My comment on BG apps vs notifications is based on the (not unreasonable) assumption that a BG app will use many more processor cycles, whereas notifications should be very efficient WRT this. Must admit, I’m surprised they were chewing your battery though. I’m willing to be proved wrong.

Thanks for the discussion.

44 mailjohannes { 02.18.10 at 5:23 am }

I’m not too worried about memory resources with multiple (background) apps open. Virtual memory and speed of page-ins/outs, combined with a large enough working memory and backing store does the trick.
The current iPhone has (if I remember correctly) .5 GB working memory and 16 to 32GB backing store (flash drive).
If the working memory is 1 to 2 GB most problems would be solved. (You could compare this to PC’s of a few years back, and this was more than sufficient for most needs.)
Mac OS uses virtual memory extensively and as a consequence the iPhone OS is fully virtual memory capable.
With a somewhat larger working memory suspending a thread (application) – as some people suggested – is a really good option and this is easy to implement. The OS has the facilities to suspend a tread already (this is a necessity for a multithreading kernel), all thats left to do is linking the ‘home button’ to ‘thread suspend for the running application’.


45 Donald { 02.18.10 at 5:41 am }

“Your analogy of the freeway also breaks down like Ulicar’s.”

You may have misunderstood. The analogy was not intended to illustrate multitasking. It’s only purpose was to illustrate misuse of the word.

46 ChuckO { 02.18.10 at 8:30 am }

Can we sum it up like this:

Apple choose to allow only one 3rd party app to run at a time for these reasons.
1. Security reasons
2. battery life on highly mobile devices.
3. conserve processor resources for considerable background OS activity.
4. Usability concerns on touch screen devices.

47 marian_ { 02.18.10 at 10:06 am }

There’s another reason why users want multi-tasking between foreground apps: quick switch.
For example, I want to enter an address received in a SMS into the GPS application. I forget the address in the time that it takes the GPS application to load. And it takes sooooo long to load Navigon, that you would not want to exit it just to check an email or something.

Long live jailbreaking and Backgrounder.app

48 cy_starkman { 02.18.10 at 11:07 am }

I couldn’t keep reading all the comments, too many.

1) HCE I think mentioned Navigation/Phone switching. I totally agree, I recently did an extensive journey using the Maps app with a car kit and it wasn’t an issue of network security or battery. It was a serious issue with my own safety. Even simply having to fiddle with the phone just to relaunch Maps was dangerous. Changing songs in the iPod was another example, it sometimes launched the iPod pop up other times it did not, seemingly randomly, once again safety issues when going back to Maps.

2) App hopping, I too find this at least awkward if not sometimes annoying. Hang on, I’ll just close this and open Cal, right okay I close that and back to Mail. Oops, close Mail and get Cal again, right now back to Mail.

3) This one is at Daniel who hasn’t got all the facts and a few commenters who bemoan the lack of user experience multitasking 3rd party apps.

Well actually there is at least one 3rd party app that does run in the background. It’s called the Tom Tom Car Kit App, it’s free and it runs in the background (it actually claims this on the blurb) and provides services to other applications.

So actually Apple does allow 3rd party apps to run in the background already. There just has to be a bloody good reason. I suspect other accessory builders would be able to do the same.

Finally to all the “but you have to jailbreak it” mob, I suppose you are the same people who complain about the Mac OS being so dumbed down and that you are locked out and that Apple controls everything. LOL. It’s UNIX dudes, you can do whatever you want with it, if you know how. If you don’t it doesn’t expect you to. So… what are you really saying, that you are not really that savvy?

49 miloh { 02.18.10 at 12:14 pm }


“… I recently did an extensive journey using the Maps app with a car kit and it wasn’t an issue of network security or battery. It was a serious issue with my own safety. Even simply having to fiddle with the phone just to relaunch Maps was dangerous. Changing songs in the iPod was another example, it sometimes launched the iPod pop up other times it did not, seemingly randomly, once again safety issues when going back to Maps.”

“2) App hopping, I too find this at least awkward if not sometimes annoying. Hang on, I’ll just close this and open Cal, right okay I close that and back to Mail. Oops, close Mail and get Cal again, right now back to Mail.”

Could it not be argued that such scenarios are an indication of one trying to use the wrong tool for the job? I see this quite a bit in technology discussions, not just this one. It’s easier to blame the tool for being inadequate and demand it be changed than it is to blame oneself for choosing the tool and demanding they change. I’m not saying this is what occurred in your situations, I’m just throwing out an alternative view that few seem to ever consider.

50 adamk359 { 02.18.10 at 2:08 pm }

@ulicar – The iPhone OS does allow apps/music/podcasts to be downloaded while using another third party app. I’m downloading an update to an app right now and did a test to see if playing a game would affect the download. It did not as I played the game for 10 minutes and the update was successfully downloaded when I was done. I’m not entirely certain what you are referencing to…perhaps a third party app downloading while another third party app is running, but I’m not certain that there are any third party apps that can download anything unless through iTunes. However, as I understand it, that would simply pause/quit the app downloading and run iTunes in the background downloading said content or update and applying it to the paused app.

Think of it like this, if your running an app on OS X or even Windows…and an update is found by the app and you agree to download it, then the app is still functional and allows you to use it while the app downloads the update safely depositing it on the desktop or wherever you chose to have the update download to. There are some apps, however, that also insist on applying the update at the same time or after it has been downloaded, which would probably start messing with a lot of things if you continued to use the app while that task is running.

On the desktop/laptop experience, it makes perfect sense to run many apps at once. I am a graphic designer and recently found myself running 6 apps at once: Illustrator, Safari, Software Update, Keynote, Indesign and Photoshop. When apps take a lot of time to start up, its just best to activate them all at once and leave them running till you are through with them. I am a neat-freak with my Mac, so whenever I am done with something, Command Q it goes.

On my iPod Touch, though, this is much less of a necessity. I do like to scribble ideas on Brushes, but when I have to go check something else out really quick, I can hit the home button and come back to my art later. Brushes does save the current state of the artwork when you left it. Would I rather the artwork be up and ready when I get back to it without starting the app again? Maybe, but the fact that it saved my art at all is good enough for me. I just simply start the app again (which unlike any Adobe desktop software takes only a second or two) and select the piece I was working on in the app’s gallery and continue my brain dump.

Is it necessary to be running 20 apps at once in the background on a mobile environment? If so, kiss your battery goodbye. This is true for any mobile OS. A lot of it, I believe, has to do with how well the developers code their apps. With nothing else running in the background (wifi, location services or bluetooth), there are some apps and games that can still suck half life out of the battery with even just 20 minutes of use. With all of those services running in the background, the battery probably wouldn’t last more than 10 minutes.

This is a huge deal for mobile devices because they can’t always be connected to a power supply all the time, unlike a desktop or laptop. Try playing a 3D-intensive game on a laptop sans power adapter and it’ll be crying uncle in maybe 1 hour on a full charge…maybe 2 at best. When I do design work on the go and don’t have my power supply, I get about 3 hours out of my 2nd gen Macbook, which is usually more time than I need it for anyway, but if we had the ability to do all that on a mobile device with an even smaller battery…all bets are off.

If I could have the very same 6 apps that I mentioned above running on my iPod and be doing design work on it, the battery would be gone in 1 minute. Apple has the ability and the time to really test their apps and make sure they aren’t using up anymore resources than necessary…even when multiple Apple apps are running. However, third party app developers don’t have this luxury. Well they do, but I think a lot of them are just glad to get something out ASA and then patch it later when necessary.

The point here is, yes, it is capable of multitasking…but should we really be all that mad that Apple is trying to save our batteries from going through a full charge in 20 minutes? Maybe we should be more angry with developers who don’t code as cleanly as they should?

You must log in to post a comment.