Why the iPad and the iPhone don't support multitasking | Hacker News Reader

Why the iPad and the iPhone don't support multitasking

blog.rlove.org

74 pointspWneD62 comments

> "Both the iPad and iPhone, as mobile devices, have limited memory (256MB in the current incarnations) and no hard drive. No hard drive means no swap file."

He loses me here. My iPhone has a 32GB SSD hard drive. Sounds like a perfect medium for swap space to me...

Yeah, that's poor wording.

The techie in me was aghast at the idea of Apple shipping iPhones with a full Unixy kernel but with no swap (and minimal background processing -- and for that matter, I wondered why its Objective-C runtime didn't support garbage collection) until I actually laid hands on one and realized how fluid things can be when they don't stutter and stop randomly while swapping in parts of the foreground program.

Such jerkiness gives a feel of "computeriness" to the user when running desktop OSes, breaking the feeling of fluid interactivity that one gets with a "real-world" object. It also causes a lot of user anxiety and even errors: it becomes a normal part of the experience to click on an item and then have a second or two of wondering whether the app "heard" you or not. Often followed by more clicks, which end up being misinterpreted when the app finally gets to run again, and now the user's mental model is completely out of sync with the system's state.

In the physical world, you never flick a real switch on a panel and then it actually moves a second or two later!

"In the physical world, you never flick a real switch on a panel and then it actually moves a second or two later!"

I know some old lights which do that.

I didn't mean the resulting action might not take a moment, I meant the actual movement of the switch.

The jerkiness and stuttering has always been a PC/DOS/Windows issue. Not a computeriness issue, unless you only have computer experience

It was in the 80's that PCs couldn't even scroll a line of text without making odd stops at times, it was in the 90's when I was surprised to still keep seeing the phenomenon, and it's these days that I can still see a modern Windows screensaver stutter for no reason. Or just some mouse click taking a few seconds "to deliver".

The reason I (and so many other people) so adored the Amiga still late in the 90's is that anything like that was completely unheard of. The computer was just so snappy. Everything happened pretty much immediately. I remember that around 1995 or so there was a web page that had 256 GIF animations playing on it simultaneously. My bare Amiga could run them all smoothly despite me even doing something else in another window. My friend's Pentium pretty much choked on the very same page.

Linux desktop is nothing compared to Amiga. BeOS was close but died as well. I want a completely 100% responsive, stutter-free multitasking desktop/ipad/phone because I know it's possible. I don't want to settle for too slow latency or live with the false claim that to be snappy you can only run one application at a time.

Swapping has been demonstrated to be seriously detrimental to the life expectancy of solid state drives.

Has it? Everything I've read that is not just speculation has concluded that you'd have to constantly write a great deal of data to wear out an SSD, even with a swap partition (or file).

http://serverfault.com/questions/23720/should-you-disable-pa...

SSD drives have substantially longer life than embedded flash drives since they are SLC, meaning each bit is represented by one cell. Embedded flash devices are MLC, meaning each cell represents multiple bits. Your drive's life expectancy goes down dramatically with each bit you try stuff into a single cell.

Are you sure? I thought most non-enterprise SSDs are MLC.

But what's the life expectancy of smartphones and the likes? I wonder if flash storage in them could die so quickly - even before such a device itself would become obsolete.

If it's correct that at least Palm's webOS and Maemo dare to swap on flash storages, we shall see soon...

would anyone care to predict what the memory specs of an iphone-like will be in 5 years?

Obviously you've never used an Amiga.

No swap file + no virtual memory + lots of stuff pre-cached onto RAM disk = snappiest user experience ever.

It scares me to think that I now days open, without blinking, some JPG that would eat up all the memory available in that poor Amiga.

But, ah...

  lea bbye,a0
  move.l (a0),$80
  trap #0
  rts

(to take it back on-topic)

Older Palm Treos (up to Treo 600 if I'm not mistaken) had everything in RAM and I remember upgrading to a newer, supposedly better Treo - and everything but the lag was...

The N900 has swap, and I think that's why it becomes completely unresponsive from time to time.

His tweet seemed to indicate that this is a bad idea:

http://twitter.com/rlove/statuses/11609100128

What I'd like to know is why this is a bad idea...

Perfect? Sounds awful to me. Few things will use up a SSD's wear cycles faster than active swap, and I doubt Apple wants to go out and buy good SSD's with many write cycles. That would eat into profits.

(they can cut corners in data storage requirements right now because the drives are written-to/read-from much less often than on a PC, so both longevity and speed are much smaller concerns)

> My iPhone has a 32GB SSD hard drive

Embedded engineer here: Solid State Drives do lots of things GREAT. However "being a drive which swap is used on" is not one of them. That's because swap memory is written very often compared to any other portion of the drive. This quickly wears out the drive in that location (and all flash has a limited number of writes, and SSD is a flash technology).

There are specific drivers for doing swap on flash devices. But it isn't easy to do well without compromising usable life of the device.

IF you're interested in doing virtual memory in an app: http://www.alexcurylo.com/blog/2009/05/14/tip-iphone-virtual... is a way to do it, there is a hacked iphone app that also enables it too (don't have a URL offhand).

I dis-recommend doing so.

Apple says they do not support multitasking because it is a hamper to stability and a drain on battery life. That clearly isn’t true—the iPad has plenty of processing power and battery capacity. Rumor is that Apple is going to add multitasking in a future OS release. This rumor likely is true. Is Apple somehow going to make background applications not consume any battery? Of course not. These excuses are straw men.

Actually this argument is a straw man. Apple can't make background processes run for free contrary to the laws of thermodynamics. However they can limit the resources they can use through the right API. (Register functions with realtime constraints, and request a "level of service.")

Saving the state of an application and terminating it isn't multitasking... you can already do that on the iPhone, and indeed well written iPhone apps will be restored to exactly the state you left them.

I care about multitasking for things which actually need to do stuff in the background, like Pandora or IM clients.

So the android solution is for apps to serialize their state when they are about to be terminated? That's exactly what iPhone apps are expected to do! What we are really talking about here is backgrounding, which is really only appropriate for a small class of apps. Push solves a lot of these cases. The audience for backgrounding without push is mostly power users, and they can jailbreak for that.

I have mult-tasking because I jailbroke.

Just as he says, Skype keeps getting killed when it's in the background so I can't depend on it for getting calls.

Of course there is the official Apple solution.

http://technologyexpert.blogspot.com/2010/03/wozniak-carries...

The only issue I take here is the iPhone is supposed to not need an instruction manual, everything is supposed to be intuitive. Adding multitasking like the Android means every user becomes an accountant keeping track of what's running and what should be killed. Activity or task managers are most definitely not intuitive. Most apps don't have any business running in the background, saving and resuming states seems to work in most cases especially with smart use of push notifications.

I've really only seen a couple compelling use cases and that is Pandora (basically music running in the background for the uninitiated) and the YC Wakemate app. Anyone have any others that couldn't be solved with push?

The big issue is that it imposes a high mental cost for switching between applications. If you're browsing on Mobile Safari and you want to look up something in another app, you generally wont, because by the time you get back to Safari you may have lost the page you were visiting and in any case the startup times can be pretty atrocious.

On the Pre, which has the best multi-tasking implementation I've seen, these sorts of tasks are a no-brainer. You know that your previous applications is just a couple of swipes away, so you're never afraid to leave it.

Constantly shutting down and restarting applications may be good for performance and battery life, but the user experience is hampered.

Well the developer can implement a great experience but the problem is the onus is on them, the OS doesn't do anything to save/resume the state. Some apps, Tweetie for instance, does a great job resuming, others dump you at the front gate and make you watch splash intros which is terrible. So I guess my vote is for built-in support for saving state.

Which is why Safari IS actually multitasking. You can leave it, launch another app, go back to it and be right back where you are. Sometimes Safari doesn't quit and you're back in a millisecond. Other times the OS closes the browser in the background, and you will have to wait a few seconds while Safari reloads the page you were visiting.

It's surprising how few people realize that the built-in apps (Mail, iPod, SMS etc) run perfectly in the background. The lack of multitasking is limited to 3rd party apps, which helps explain why most iPhone users never complain too much about the lack of real multitasking.

But Safari being multitasking only solves the "browsing -> other -> back to browsing" case, right? "Something else -> Safari -> back to the first something else" needs the something else to be multitasking enabled or good at storing its state.

Trying to predict what the users will and won't ever need to switch to and from and back to again is a crap shoot in general. Sure one can get it right much of the time, but why not just suck it up and make the overall solution better so there aren't those cases where one guesses wrong.

From the outside, this feels like a bizarre, "accept no criticisms of an Apple product as valid" kind of thing. Stuff like Browser Duo and mini apps make it clear that the longer Apple doesn't solve this in general, the more other developers will put together "do x and y at the same time" applications. Does it really seem better to have these kludges than a general solution?

"something else" -> "web browsing" -> back is handled by the application wrapping the Safari web browser using the included browser control in the API.

Good point. I was just doing an inversion in the example to simplify the argument mechanics a bit.

But doesn't that wrapping rely on something else's developers realizing that the user might want to go off to the browser and back? What if it wasn't Safari in the middle but any one (or three) of the numerous other programs the user might want to take a side trip through. It gets back to the crap shoot of trying to guess every multi-application use case that will be wanted. All this to defend not putting together the general solution which is entirely doable to begin with.

That's a strawman. Android users don't need to keep track of what's running and what should be killed at all. The OS keeps track of it all.

Android actually has a pretty damn clever model where normally Activities are killed whenever they're not visible (similar to the iPhone model). However, and application can register service processes that run in the background to do things like play music, check for updates (email, IM, etc).

The difference between the Android and the iPhone model is actually pretty small. The main difference is that on the iPhone, only certain Apple provided apps can do things like play music in the background, get background notifications, etc. In Android, third party applications can also be written to do those things.

But in the most common case of apps that don't do things in the background, the application lifecycle of iPhone apps and Android apps is actually quite similar.

I would be more than happy with no multitasking at all with one exception: sms.

And I'm pretty sure that if I include another two apps (safari and mail) on my exception list most people would be okay without multitasking.

I don't need a window manager, I need to focus on the app I'm using and the ability to reply (or send) sms and mails and check something on the web without quitting the current app.

There are a range of applications, including highly useful ones, that simply needs multi-tasking. Anything that is time based (think calendars, alarm clocks, etc...) really need multi-tasking to work correctly. A host of location aware applications really need multi-tasking to work effectively.

I get Apples position. The iPhone is the spiritual successor to the PalmOS. It looks, feels, and works very similarly to it. Even early finger-based applications first made their appearance on the Palm (here's looking at you SnapperMail with your fat finger mode). The Palm had thousands of apps and solved a ton of problems without multi-tasking. So I get it... you can build a really useful device without it.

Yet there is so much more you can do with a well thought-out system like Android has. As Android gets more traction (and thus more developer interest) I think your going to see more and more separation between the quality of the apps available on the devices. There are simply going to be killer applications that force Apples hand to stay competitive.

Very few apps need completely open ended multitasking. Most apps need very specific capabilities. An API for registering time limited functions with timing, location, and other services would take care of 90% of the needs out there.

I think you've just made enjo's point for him. You said "Most apps need very specific capabilities. An API for registering time limited functions with timing, location, and other services would take care of 90% of the needs out there." That IS almost exactly the very well thought-out system that Android provides and that enjo was talking about.

We know from SDK snooping that Apple is working on third party multi-tasking so it's kind of a moot point. The only question is how they're going to do it. I think it's good to acknowledge that a mobile device with limited battery/resources has to multi-task differently than a traditional computer running an OS designed 20-30+ years ago.

This guy is just wrong: Apple OS has turned off multitasking for 3rd party apps to maintain battery life.

It fully supports it. This is a control situation, where Apple has decided "We want our devices to have good battery life more than we want to allow multitasking".

Source?

Do you hear music in the background while doing other things?

Do you see your mail being checked while doing other things?

Do you get background notifications while doing other things?

Do you get appstore apps downloaded while doing other things?

The iphone is fundamentally built on a mach kernel, which supports multitasking. Taking it out, when they already needed to use it for multitasking for the above tasks, is a silly idea.

Here is a rundown of other parts of the iPhoneOS kernel: http://www.roughlydrafted.com/2007/07/13/iphone-os-x-archite...

Best thing about those excuses are:

Every other mobile OS supports multitasking and all the smartphones i know have similar battery life. Symbian, Windows, Android, all have multitasking and yet people try to convince me that it, "not needed", "not possible", "makes the device unstable", "drains battery too much" which is just not true. My Android phone lasts at least as long as an iphone and i use multitasking all the day. It's just that the OS was truly made for this and it does it quite well.

If I leave an app running in the background that keeps the net connection open on my Nexus One, the battery goes from 100 to 0 in about 5 hours.

I'd bet that app was poorly written and doing something else in the background. An app that is just listening for data from an open connection should be using roughly zero CPU. But we'll try science; I've signed into AIM on my Nexus One and left it running in the background. The battery is at 81% now, I'll report back in an hour.

If you keep a connection open it drains battery life because the chip can't power down.

Sort of. In tumult's case he's got a connection that's actively downloading data and playing music. I would assume that'd keep the radio chipset (either wifi or cell, whichever he's using) and the CPU both from being able to switch to a lower power standby mode.

However, you can have an open but idle connection open in the background with only minimal battery drain. That's how pretty much every kind of push notification or IM system works, even on cell phones.

77% after an hour.

Sign in with the connection currently using WiFi instead of GPRS/3G, and it will keep the WiFi hardware on, which is what kills it. There is no way for a normal user to know that they need to open new, persistent connections over a connection type that uses the cellular modem instead of the WiFi. And Android defaults to using WiFi for new connections if the WiFi hardware is powered on and connected to a network.

The best way to save battery on an Android phone is to turn off WiFi unless you need it at some point during the day. iPhone will stop attempting to do push notifications and the background Apple apps will disconnect if the only available connection is WiFi.

I'd also like to point out that "I bet the app was poorly written" is exactly the situation Apple is currently avoiding until they are confident they have a reasonable technical solution to it.

I was signed in using WiFi, and I normally have WiFi enabled all the time and get over 24 hours of battery life. Maybe some wireless chipsets suck too much power, but it doesn't appear to be a problem on the N1.

Maybe we're doing something different, but I cannot get my Nexus One to stay alive for longer than 5 hours with an active net connection. It if it's a low-traffic connection (calm IRC channels, occasional email polling) it will last a day (same with my G1) but streaming radio, etc will leave it dead in a long afternoon.

Ah.. Streaming radio. By active net connection I thought you meant email polling, IM, etc.

Playing streaming video will kill the battery pretty decently, but IMHO that seems fair. Your keeping the radio pretty busy, the audio hardware, the cpu, etc.

I'd actually like to hear from an iPhone user whether they can run Pandora or Last.fm for 5 hours straight without killing their battery either.

I'm an iPhone user as well, and it also kills the iPhone. the point was that on iPhone, 3rd party apps are not given the opportunity to do this without the user being aware (because it's in the foreground.) i've had a runaway android app kill my phone after it screwed up and started devouring resources in the background while it was in my pocket.

The user would have to be aware of streaming audio. Also, as stated elsewhere in this thread, apps don't normally run in the background on Android either. I'm curious what app you believe killed your battery life in the background? That sounds... unusual.

Apps normally run in the background all the time in Android. I know which app it was (meebo) because I can view the stats afterwards. Also, to help alleviate some of your confusion, we are talking about background processes, not just streaming audio.

Apps only run in the background if they specifically register a background service. Usually this is when you click a button in the apps preferences like "update in background", etc.

Read this: http://geekfor.me/faq/you-shouldnt-be-using-a-task-killer-wi...

Wow, thanks for this point. Just reminded me to turn off the android phone I was using but had stuck in the drawer.

I'd bet that app was poorly written and doing something else in the background. An app that is just listening for data from an open connection should be using roughly zero CPU.

It would be too much work to vet every app for good concurrent programming. It's a much better idea to disallow it and add an API with resource controls later. This is the only way to protect users from resource hog apps.

Well, i have atleast running: Facebook, twitter, rss aggregation, gmail and k-9mail imap idle, gtalk plus weather and my phone is at around 30% end of a normal day with a few calls and around 2hrs rss reading on my way to/from work. Only one day battery life is quite sad compared to featurephones but i'd say it's normal for the smartphone of today. Oh, and i have gps/wifi turned on that day. Android 2.1 admittedly has some big improvements around that, as on my G1 wifi/gps made a much bigger difference. According to the battery stats the display is draining by far the most power anyway.

My iphone runs ~2.5 days without a charge...

Android is just now getting reasonable battery life with 2.x when heavy multitasking is in use. Many people need to have process cleaning apps to have zippy performance without rebooting the phone every few days. (And the fact not all android phones are upgradeable to 2.x is an issue meaning many still have crappy multitasking battery life).

And in practice, its still wrong. The 3rd party repos have an app called Backgrounding that does precisely that... And no sdlowdown on most apps.

It's very handy. Sometimes you want to have Safari start loading a slow-to-load page, put it in the background and do something else. Pandora radio is another oft cited example.

I jailbroke just so I could run Pandora and Slacker in the background. (Though an updating weather icon and having a background image are nice too.)

I'm not sure how Pocket Tunes Radio is able to play in the background, but they've found some Apple-sanctioned solution that works for MP3 and AAC+ streams. Or I can use Safari to start an MP3 stream and it will background just fine.

I'm sure Apple could just make a policy decision to let some apps they approve run in the background.

Reply on news.ycombinator.com