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

iPhone 2.0 SDK: The No Multitasking Myth

200803130018-1
Daniel Eran Dilger
Certain pundits have developed a rash of malignant concerns about iPhone 2.0′s SDK. The first issue they’re scratching at is the iPhone’s apparent inability to run multiple applications at once. The suggestion is that the iPhone is a multitasking impaired appliance just like the original Mac or the Palm Pilot, and unlike the supposed multitasking powerhouse that is Windows CE, which powers Windows Mobile devices. That’s wrong, here’s why.

Auf Deutsch: iPhone 2.0 SDK: Der „kann kein Multitasking“ Mythos
Übersetzung: digital express


The iPhone is Unix.
The first clue into discovering how the iPhone works is a look at its core OS. The iPhone runs Apple’s same kernel as Mac OS X: a hybrid of Mach and BSD that hosts a standard Unix subsystem. It supports multiple concurrent processes and multiple users.

At this point, it’s useful to point out that the Palm OS was also built on top of a multitasking kernel, but Palm only licensed it for use from Kadak as a single-tasking environment. That made the Palm OS very much like the classic Mac OS from the mid 80s: to launch a second application, the first had to be shutdown.

Apple doesn’t face the same problem with the iPhone; it owns the iPhone’s kernel and faces no other external technical limitations to prevent multitasking. The ability of the iPhone to answer a call, pull up the Maps app while the call is in progress, and then follow a link to a web page before ending the call was demonstrated in one of its first advertisements.

The iPhone rings when browsing the web, music plays in the background while performing other tasks, and can check emails periodically in the background. It can clearly multitask. So why does Apple state in the SDK docs that “only one iPhone application can run at a time?” For starters, it is useful to point out that the iPhone does not suffer the same architectural problems as the Classic Macs or Palm Pilot.

iPhone OS X Architecture: the BSD Unix Userland
The Egregious Incompetence of Palm

Multitasking Macs before Unix.
The original Mac didn’t have the resources to run multiple applications at once. The first Mac users quickly found that running one application at a time was indeed a serious limitation. In 1985, Andy Hertzfeld developed a utility called Switcher that allowed users to pause the running application and start a new one. By 1987, Apple released MultiFinder, which allowed Macs to display multiple concurrent applications and rapidly move between them.

However, the Classic Macs weren’t doing Unix-style preemptive multitasking, where the operating system strictly manages the processing resources given to each running application. Instead, the system relied upon applications cooperating to take turns on the processor; if an application fell into a loop, it could cause the whole machine to stall.

That doesn’t happen in Unix because processes aren’t trusted to cooperate; they are explicitly managed by the kernel. If they stop working, they are bypassed and can be purged from the system. The only process that can freeze the system is the kernel itself, which is why all software in the kernel has to be extremely stable. That’s also why Apple discourages developers from writing kernel extensions unless they are really necessary.

Folklore.org: Macintosh Stories: Switcher

Just Because You Can, Doesn’t Mean You Should.
The iPhone has the same Unix ‘kernel in command’ architecture. However, just because the system can run multiple concurrent applications doesn’t mean it’s a good idea to allow developers to load up all the processes they care to run in the background

In Mac OS X, opening lots of concurrent applications isn’t usually a problem. If the system runs out of RAM, it can page inactive applications onto the hard drive using Virtual Memory, where they can hibernate until they are called to activity again.

The iPhone has the same virtual memory system, but doesn’t have gigabytes of RAM or a hard drive to use as a Virtual Memory swap space. Instead, it has 128MB of RAM, of which something like 11MB appears to be used for VRAM and 19MB looks to be used by system overhead, leaving around 76MB reported by sysctl as user memory.

By limiting the amount of background processes running, the iPhone’s OS X can offer more of that available RAM to the foreground application, along with a less distracted processor. The iPhone is not a general purpose computer; it is primarily a phone, browser, and iPod. Due to the restrictions imposed by the SDK, it will also be a credible gaming platform and pack the power to run significant productivity applications, all without giving up the ability to be a responsive phone, browser, and iPod. Other devices can’t make that claim.

furbo.org · What the iPhone specs don’t tell you
The Microkernel Myth

The Problem With Background Processes.
While the iPhone has around twice as much RAM as the typical smartphone, 76MB is easy to eat up if you have lots of background processes running. In addition to RAM, those processes will also consume the processor power available for media playback, WebKit rendering, telephone audio and radio signal processing, VoIP data encryption, and processes listening for push email, incoming calls, SMS messages, or configuration information, all of which are critical features that users won’t be happy about if they aren’t all working flawlessly.

In addition to taking up bandwidth important to the core operations of the phone, extra background processes will help keep the processor consumed, which means it will be running hotter and eating up more energy at all times, resulting in a shorter battery life and perhaps a shorter device life as well.

Apple has a responsibility to iPhone users to develop guidelines that ensure that the system continues to work as expected, doesn’t overheat, and doesn’t plunge in battery life as new applications are installed. Not allowing third party developers to install background processes is part of that plan. It would be irresponsible for Apple to kick open the floodgates for developers and then blame users for not understanding how to manage their own process allocation within the iPhone’s thermal envelope and resource constraints.

iPhone OS X Architecture: the Mach Kernel and RAM

iPhone OS X Architecture: the Mach Kernel and RAM

The Problem with Foreground Multiprocessing.
In addition to the processes running in the background, there’s also an issue of running multiple applications in the foreground. Of course, the iPhone does appear to run multiple foreground applications at once. While on the phone, you can return to the home screen and launch in and out of other apps. During the entire call, a green strip appears at the top of the screen to act as a quick hyperlink back to the call progress screen.

iTunes will also play audio while other apps are running (although this will anecdotally make it more likely for Safari to crash while it navigates between web pages). At any time, the Home button can be double clicked to bring up an iPod playback controller screen overlay.

In both examples, the shared, concurrent UI presented is rather limited. This is no accident. Not having any other applications running concurrently not only gives the active app and critical background processes more resources, as noted above, but also greatly simplifies the UI for the user.

The persistent phone call is unique in that the iPhone is primarily a phone; the iPod features are also a key element of the device. However, if every application could reserve a spot at the processor table, there frequently wouldn’t ever be anywhere to sit. Even worse, the iPhone’s display isn’t really big enough for apps to share. Of course it could, but thank Apple for knowing better than to crush applets into the same screen with an interface inappropriate to a handheld mobile device.

Rocket Launching.
The idea that the iPhone should let apps decide what they’re going to do when asked to leave, rather than setting an enforced system policy, might sound good but isn’t well thought out. Apple’s decision is to do with third party apps exactly what it does to Safari: when the user hits the Home button, the system saves the currently running application’s data, quits the app, and presents the Springboard menu of apps. When the app is next launched again, it starts up from where it left off.

Because the launch time is so rapid, there’s really no difference for users between trying to leave an application running in virtual memory and simply quitting and then relaunching it again later when needed again instead. The technical difference is that quitting apps results in better use of resources, including better battery life. Users will notice that.

That’s why Apple decrees in its SDK: “Only one iPhone application can run at a time, and third-party applications never run in the background. This means that when users switch to another application, answer the phone, or check their email, the application they were using quits.

Invent, Suggest, Panic!
Non-engineering savvy blogs such as the ironically named BoyGenius Report have joined arms to sign up petitions demanding equal rights for third parties’ applications to run in the background and not have to quit when users switch between apps. Sounds good, but do they know what they’re talking about?

Zach Epstein spelled out his fears of the potential doom of “no true multitasking” on the iPhone by citing developer Robert Balousek as saying, “If you are running an application such as AOL Instant Messenger on your iPhone, every time you receive a call or browse away from the application you would be signed out, you would lose any unread messages, and your conversations would end.”

However as Christopher Cox noted, “the author of this article is exagerating big time [...] the app will be able to suspend and save current data when something interrupts it. When you go back, your old messages will still be there. [...] the AIM server doesn’t actually disconnect you unless your program sends a disconnect signal or you are not connected within a specific timeout. This means it can pick right back up where it left off when you come back to the application (and you don’t initiate a re-connect). The only disadvantage this brings from the norm are if you want to stay on AIM 24/7 in the background or other daemons. This will not be a show stopper for most people.”

iPhone SDK Honeymoon Over – No Background Processes?! | The Boy Genius Report

What Would Happen If Apple Didn’t Know Any Better.
While it’s comforting to know that iPhone SDK panic related to multitasking is overblown and ill informed, is it still possible that the iPhone might be much better off without Apple’s engineered limitations? There’s no need to speculate. We already can get a clear picture of how disastrous things would be if the iPhone were engineered by a committee primarily interested in pleasant sounding buzzwords; that picture is delivered by Microsoft in WinCE.

Microsoft conceived of WinCE as offering a multitasking architecture like Unix, but despite giving it a paged virtual memory architecture, it still only supports 32 concurrent processes and each is limited to its own 32MB virtual address space. This is supposed to be addressed in WinCE 6.0, which should be available in a couple years. Until then, multitasking in WinCE is fundamentally flawed. Of course, it gets worse than that.

In addition to Microsoft’s architectural limitations that stymie developers from making efficient use of its multitasking features, WinCE proves that the general idea of having no limitations on third party background processes and concurrently running applications on a handheld device is a bad idea for a number of reasons. The first relates to the resource issues I already raised. In the words of WinCE Enthusiast Chris De Herrera:

There are times when having multiple applications running at once causes the foreground application to slow down noticeably. This slowdown is due to the amount of time that the operating system is spending servicing background applications. In these instances, I recommend that users consider performing a soft reset.

Like kill on the road,
Windows has failed to respond.
Control! Alt! Delete!

But there’s another reason why running multiple applications together on a mobile is stupid: there’s no room to see them at the same time. Without the screen real estate, there’s not enough pixels to support a desktop style arrangement of multiple overlapping windows as introduced by the Lisa, with close boxes and title bars to switch between the windows.

That reality hasn’t stopped Microsoft from trying to crush its clone of the Mac desktop UI into tiny screens since the late 90s, but it did result in making those efforts unsalable. WinCE devices are plagued with complexity to the point that it’s hard to get anything done with them. They crash frequently and have abysmal battery life. The iPhone is so plainly simple that it’s easy to pick it up and start using productively without any training. It just works. If Apple had tried to force in the same Dock and menu bar and Finder desktop and floating windows from Mac OS X, the iPhone would have been tragically unusable as well.

The Spectacular Failure of WinCE and Windows Mobile

The Spectacular Failure of WinCE and Windows Mobile

Less is More; More with Less.
So while the iPhone has a better multitasking kernel than WinCE, its engineers knew better than to deliver a system like Microsoft’s, which could seemingly do everything on paper, but in reality could do nothing very well and subsequently couldn’t sell either. Instead, the engineered limitations of the iPhone 2.0 SDK will make the device more useful to users.

Even before the new software’s availability, the existing iPhone is already outselling Windows Mobile phones in the US with a 27% share of the market and a whopping 71% share of all mobile web traffic.

And just as with the desktop PC, Microsoft will find it impossible to back away from its legacy of complexity to offer anything remotely similar to Apple’s iPhone in WinCE, because existing Windows Mobile applications all assume the right to hog the processor in the background and keep Windows Smartphones running slow, inefficiently, and awkwardly complex enough to only appeal to the most devoted of Windows Enthusiasts.

When they complain that the iPhone doesn’t share the same problems, it should now be more clear why practical simplicity is such a difficult concept for them to understand.

Apple’s iPhone vs Smartphone Software Makers

Apple’s iPhone vs Smartphone Software Makers

More on the iPhone 2.0 SDK

iPhone 2.0 SDK: The No Multitasking Myth
iPhone 2.0 SDK: Java on the iPhone?
iPhone 2.0 SDK: How Signed Certificates Work
iPhone 2.0 SDK: Video Games to Rival Nintendo DS, Sony PSP
iPhone 2.0 SDK: Readers Write on Certificate Signing

I really like to hear from readers. Comment in the Forum or email me with your ideas.

Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast! Submit to Reddit or Slashdot, or consider making a small donation supporting this site. Thanks!

Technorati Tags: , , , ,

  • http://johnsessays.blogspot.com John Muir

    #100?

    Is RDM the new Crazy Apple Rumors?

    No, no. Don’t even think about it!

  • Scott

    So why must I be a damn programmer to use the damn phone? I know absolutely nothing about what your dreamt out applications will do with my iPhone. This is the reason why I want Apple to police the whole damn thing so that my phone works as I expect it to work. Of primary concern to me are security, battery life and performance.

    Here is a good idea: If you cannot make you vapor app work with the current restrictions maybe its time you give up. Your app is probably some boring piece of vapor only fit to run in some junk phones running Windoze.

    Thanks SJ; these restrictions will filter out a lot of spaghetti, and upside down coded apps from amateurs! The true creatives will develop for the iPhone with or without the restrictions!

  • countach

    All the people saying to “code around” the restrictions are the same people who were saying how smart Steve Jobs was for not allowing native apps on the phone, and that programmers should just work around it by writing web apps. If you can’t make your vapor app work as a web app, you should just “give up”.

    Well sure, we can “give up”, but it means you either won’t get that app, or you’ll get an app that has an extremely brain damaged user experience, similar to being a web app. Aka, no asynchronous notifications, and you must sit there staring at the screen until it completes some activity that you could have let complete in the background while you move onto another task. May as well go back to web apps.

  • starkruzr

    Scott, let’s travel to a magical land where these restrictions on iPhone applications no longer exist. Thought experiment, right? No restrictions on background apps.

    How does this make your experience on YOUR phone worse, when you don’t want any of these applications? All you have to do is not install them.

    To be more practical about it, Apple could simply implement two levels of security on the iPhone: the one they have now, with approved applications, and something else that amounts to jailbreak, where the only tech support option they’ll support is “restore your phone to factory standards.” This would result in a minimal expenditure of extra effort on their part and everyone would be able to have their proverbial cake and eat it too.

  • http://www.roughlydrafted.com danieleran

    @ countach: “All the people saying to “code around” the restrictions are the same people who were saying how smart Steve Jobs was for not allowing native apps on the phone, and that programmers should just work around it by writing web apps. If you can’t make your vapor app work as a web app, you should just “give up”.”

    I know of no one who advocated that Jobs was “smart” for not allowing native apps. I would imagine I’ve written among the most of about iPhone development issues without repeating the same old saw about how disastrously uninformed and stupid Apple was not to release the SDK before anyone had the iPhone.

    What I wrote was not that Jobs was God and that all should bow to Apple, but that Apple had good reason for maintaing control over the iPhone development environment, and failing to do it properly from the start would result in the same clusterfck as Palm, Windows Mobile and other junk mobile platforms.

    What Apple is doing with signed code is what Rim, Symbian, and other platforms are attempting to do. Apple is also paying more attention to mobile performance issues, so rather than running a few apps poorly right from the start, the iPhone will have a wide and deep software selection that works well. Sophistication can be added later; problems can’t be solved so easily once they’ve been allowed to explode and cause widespread, complex issues.

    @ starkruzr: “How does [No restrictions on background apps] make your experience on YOUR phone worse, when you don’t want any of these applications? All you have to do is not install them.”

    The same way that no restrictions on malware makes using Windows worse for everyone, or that no restrictions makes Palm/Windows Mobile software largely worthless.

    Suggesting that Apple should maintain safe and unsafe environments for iPhone users is like saying the US should run two sets of airport security: none and whatever exists now, and then let the market decide which people want to use.

    However, your recommendation that Apple implement two levels of security on the iPhone is already in place: everyone using the iPhone as Apple directs will get a workable phone, and those who hack the phone to use undocumented APIs, run things in the background, and load plugins and unsigned apps will be able to complain that Apple is persecuting them when their stuff stops working or fails to find official support.

    And the wags will devour every bit of it as proof that Apple is evil and that that the road to Nirvana is paved with romantic chaos that corporations should somehow remove any risk from for users.

  • casadapinga

    Lets talk about the SDK like it’s entire purpose was to make money for the people using it to create something special. We can talk about idealogical point of views about how Google is allowing the vast majority of developers create and sell their applications the way they want it. The problem is they have the following in unknowns:

    1. Will the device be touch sensetive ?
    2. Will it have buttons ?
    3. What is the screen resolution ?
    4. Will it have custom hardware functionality ?

    More problems In selling it :

    1. How do I market it to the wide audience ?
    2. How do I make sure I accurately convey the possible problems with my program and updates ?
    3. How do I deal with promotions and making sure people know I have a special deal ?

    Problems with Performance :

    1. Only geeks would know how to go to tasks and kill it.
    2. How do you deal with expectations of bad battery, response and usability of the whole device in general ? Whose responsibility is it finally, the user’s for installing programs or the developer for writing a program that is CPU or network intensive or the mobile provider who allowed you to install it in the first place.
    3. The delusion that operators will allow you to do anything and abuse the system.

    Bullshit is what I call on that. Anyone who believes in the success of society based on pandering of developers is just out of their mind. Open source has it’s purpose and has it’s place.

    I will wage a bet that developers selling their applications on the iPhone will sell 10 times as much as those on the google platform. Nobody buys software because it is open source, they buy it because it fulfills a need, does what they want and is easy to find. When google allows that and understands what it means to market to consumers will they get it. You might think that they do know because of their success in the search arena but they have had no financially successful venture other then what they are known for in pandering to consumers and making money. If you are a developer then neither are you. If you want personal satisfaction and want to feel good, continue developing for the google platform just don’t expect a big reward.

  • demallien

    @starkruzr
    “How does this make your experience on YOUR phone worse, when you don’t want any of these applications? All you have to do is not install them.”

    Well, how is Scott, a hypothetical no-nothing-about-technology consumer, supposed to evaluate whether software is going to kill his system? What you are suggesting is that Scott, not being able to accurately determine the tradeoffs of various apps/performance, should simply not install any apps if he wants to be safe.

    OR, he could use an iPhone, where Apple’s rules will ensure that ALL applications give him a good experience. I suspect that Scott would much rather the second option.

    You see, take away the Apple gatekeeping, and the utility of the iPhone will actually drop for people like our hypothetical Scott, because they won’t be able to trust 3rd party apps.

    On the other hand, if you’re a real star alpha-geek, you can always just jailbreak your phone, and put whatever sofware you like on it. The current Apple solution lets both groups get whatthey want. The only people that are missing out are people that want to write commercial apps that break Apple’s rules. hardly a great loss.

  • starkruzr

    Daniel,

    “The same way that no restrictions on malware makes using Windows worse for everyone, or that no restrictions makes Palm/Windows Mobile software largely worthless.”

    Except it doesn’t. The reasons Palm and WM are terrible is because of design (or lack thereof), not because they allow background applications. WM is a terrible user experience because after 10 years it is STILL an attempt to squish a desktop PC UI onto a tiny screen. Even the non-touchscreen “Smartphone” version of the software hasn’t changed that. It doesn’t even look like WM7 or 8 will address the deficiencies of the UI. The kernel, as many of us probably know, is actually a really well-built piece of software, but the system suffers because of its terrible UI.

    I don’t know anyone, and have never even heard any stories, about problems with malware on WM. What I HAVE heard about (and experienced myself) is tons of crappy software owing to Microsoft’s restrictive software development practices. Is this sounding familiar yet, kids? You absolutely NEED Visual Studio in order to develop any kind of real software on the WM platform, and it costs hundreds of dollars. Sure, you can download the *compilers* for free, but you can’t see what you’re doing, and that’s a much bigger problem on WM than it is on Mobile OS X.

    “Suggesting that Apple should maintain safe and unsafe environments for iPhone users is like saying the US should run two sets of airport security: none and whatever exists now, and then let the market decide which people want to use.”

    Actually, Dan, that’s a terrible analogy, and I know you’re smarter than to think it’s actually a good one, so why did you bother with it? Airport security exists to protect travelers from *DEATH by other party*. Mobile OS X software restrictions exist to protect users from *themselves* and protect Apple’s revenue stream. That was a nice try, though.

    casadapinga,

    “We can talk about idealogical point of views about how Google is allowing the vast majority of developers create and sell their applications the way they want it. The problem is they have the following in unknowns:

    1. Will the device be touch sensetive ?
    2. Will it have buttons ?
    3. What is the screen resolution ?
    4. Will it have custom hardware functionality ?”

    What are you even saying? Why is any of this a problem? You write software for hardware with the capabilities you need. If a device is physically incapable of the software, the installation process says so. This is not difficult and is a solved problem in the Windows Mobile world.

    “More problems In selling it :

    1. How do I market it to the wide audience ?
    2. How do I make sure I accurately convey the possible problems with my program and updates ?
    3. How do I deal with promotions and making sure people know I have a special deal ?”

    Uh. The same way you market any software? The same way you do ANYTHING with any software? Why are you painting these problems as if they are a) new b) unsolved?

    “Problems with Performance :

    1. Only geeks would know how to go to tasks and kill it.
    2. How do you deal with expectations of bad battery, response and usability of the whole device in general ? Whose responsibility is it finally, the user’s for installing programs or the developer for writing a program that is CPU or network intensive or the mobile provider who allowed you to install it in the first place.
    3. The delusion that operators will allow you to do anything and abuse the system.”

    1. Wrong, and unnecessary. It is entirely possible to do foreground-plus sort of software model and make it clear to the user that running more things in the background will slow the device down. You “task swap” by closing one app and opening another, and you “stop” background processes by uninstalling them. Maybe some of them can have “on off” switches. It doesn’t matter; either way this is an easy problem to fix.
    2. Even the least tech-savvy are capable of realizing “after I installed Widget.app, my battery life went down like crazy.” This is simple, simple stuff that can be (and is) put in help files.
    3. AHHHH! HERE’S THE RUB, ISN’T IT! :) Finally we admit that the American cell phone cartel is fundamentally anti-consumer and anti-user in general. Their agenda is to milk the customer by any means possible, because they have no real regulation and are able to do any damn thing they please despite running a network which was partially paid for by tax dollars and upon which life or death situations depend.

    Here’s my counter-bet for you, friend: I will wage a bet that software on Android will be 10 times more USEFUL than software on the iPhone, and that there will be much more free (and Free) software available for Android than there is for the iPhone. Why? It’s already extant: look at the software available for jailbroken iPhones right now. Most of that is ported free OS X and *NIX software, and it’s all tremendously useful.

    One thing is for certain: the next few months after Android is released will be verrrrry interesting.

  • gus2000

    Nobody praised Apple for their iPhone web craplets (I certainly did not). But I do understand why Apple wanted to proceed slowly. I respect that they were willing to admit this. And I love that the iPhone shipped with 95% of the features I wanted with 5% of the hassle. No 3rd-party crap needed!

    That’s not to say that there isn’t a market. Heck, there might be a killer app that none of us have thought of yet. But I did jailbreak my phone and load up every app in sight, and was ambivalent. I look forward to seeing the community creativity poured into this platform, I’m simply not chomping at the bit for it.

  • Pingback: iPhone SDK: How Signed Certificates Work — RoughlyDrafted Magazine()

  • Pingback: Apple’s iPhone vs Smartphone Software Makers — RoughlyDrafted Magazine()

  • http://sociableapps.blogspot.com/ mc77

    iPhone platform can’t be compared to Android, because currently there aren’t any phones with Android OS. It doesn’t matter what apps are technically feasible with Android, if the carrier refuses to let users install them. Don’t be fooled by Google’s promises of openess. Just take a look at OpenSocial, each instance of OpenSocial is only as good as the underlying Social Network allows it to be.

  • http://demaagd.com Jeff56

    This article really doesn’t address the hardware. What we know of as preemptive multitasking on a computer with a Unix or NT kernel doesn’t appear to be possible on the ARM platforms because that type of feature requires hardware that doesn’t seem to be there. It looks like it’s a cooperative multitasking system at best, even if it is Unix-based. I’m not saying the other handheld platforms do have this sort of feature either, but I think that’s part of why Apple isn’t allowing devs to do multitasking.

  • starkruzr

    @Jeff56: If you’re referring to the MMU, you’ve got bad information. The ARM11 in the iPhone has an MMU and there are other OSes running on similar chips (including Debian Linux!) that do pre-emptive multitasking. It is not a hardware limitation. The main limitation of the ARM family of chips (most of them, anyway) is that they lack a floating-point unit. This is made up for, of course, on jailbroken iPhones with the armfp library.

  • Pingback: iPhone 2.0 SDK: The No Multitasking Myth » General » Apple, iphone()

  • countach

    And of course, you don’t need an MMU to preemptively multitask. Even the crappy 8086 chip could preemptively multitask.

  • pecos.bill

    Very well written.

    I also agree with another commenter that at some point Apple might open up task specific threads such as an AIM listener. Those would be required to be vetted by Apple before release. I would presume those will run as child processes to a babysitter task that could throttle them as needed. To my knowledge, such a thing does not exist in Mac OS X, and coupled with the huge effort to get the SDK, wasn’t even considered.

    Unless AIM currently supports some flavor of message queuing, I’m not sure what would happen with the messages when the AIM client isn’t running. Currently, AIM doesn’t allow queuing messages while users are offline.

  • Pingback: eraser’s blog » Blog Archive » iPhone 2.0 SDK: The No Multitasking Myth()

  • Pingback: Mobile EEE PC, UMPC, and Internet Tablets vs the iPhone — RoughlyDrafted Magazine()

  • Pingback: Interesting Launch to the New iphone - Page 9 - Nokia N95Users()

  • Pingback: Why Apple Plays God with the iPhone SDK — RoughlyDrafted Magazine()

  • Pingback: Why I will not be getting an iPhone : The Brits Blog()

  • Pingback: Push To The Background: Will "iPhone 3.0" FINALLY Support True Multitasking? | iPhone 3G Tricks()

  • Pingback: 2 anos depois, conseguimos definir o que é o iPhone? « Indistinguível da Magia()

  • Pingback: The big 3.0: How iPhone will shift peripheral devices — RoughlyDrafted Magazine()

  • Pingback: The Palm Pre/iPhone Multitasking Myth — RoughlyDrafted Magazine()