My money's on some sort of limited form of multitasking, where apps can launch background processes or something like that.
This is one way in which I can tell apart people that like Apple products (ie, me) and fanboys (ie, those who think Apple products are perfection)
You don't seem to acknowledge that there are tradeoffs involved. Apple's competitors have chosen to offer multitasking at the expense of performance (responsiveness, battery life, etc.). Apple's strategy so far has been to not take that performance hit. It seems like they may be shifting now to investing far more than their competitors into their software development to ensure that their multitasking won't cause an unacceptable performance hit.
It's a design choice. I've done embedded devices that run on limited power situations for years. Multi-tasking sucks battery life out because the processor is constantly waking up to do work.
If you've used the G1, you will see quickly what multitasking does to batteries. You as a technical person understand this is a tradeoff. Grandma, or Apple Fanboi #5, doesn't understand this, so they destroy their battery life when playing pandora while doing everything else.
I wouldn't be upset if it was a setting in the device, such as notifications are currently, but if it's something apps can turn on without choice from the user, true concurrency can tank the battery use time whether people want to use it or not.
These are common issues with past mobile smartphone platforms like WinMo.
Apple is smart enough to know that giving people fewer choices is sometimes a better idea than giving them the power to fuck it up royally. When Apple does implement multitasking, you can bet it will probably be done right.
Does that make me a fanboy? Maybe, but you're being dishonest if you think the average user knows or even cares about how much memory is available in their smartphone.
And those reasons will magically disappear if they offer multitasking some day? Or will the fanboy crowds switch to "well Apple didn't want to do it until they could build a better version of multitasking, and now they have for <insert esoteric implementation reason>."
I'm not a fanboy, just a fan of good software implementation, and Apple has had a pretty good track record so far.
And you responded with pretty much exactly what I said, pretending to be a rabid fanboy.
Hilarious!!! HN doesn't usually see much humor at all, it's nice to see some, particularly with such a sophisticated wit!
Kudos!
To be perfectly honest, I can only think of two use cases for (third-party application) multitasking on a device like the iPhone:
1. App 1 in background streams/plays music while I use App 2 to do something else.
2. IM client in background popping up messages as they come in.
On a device with the form factor and use cases of a typical "smart" phone I just can't think of any other reasonable case where I'd even want, let alone need, multitasking.
So count me among the group who'll be happy if something shows up which actually makes multitasking on a device like the iPhone useful, but who don't particularly miss it at the moment because there just isn't that much it'd be good for.
I will certainly understand if iPhone/iPad multitasking arrives with some fairly severe limitations placed on the developers of background apps. Right now there's zero ability in that area so anything, even if severely limited, will still be an infinite improvement (depending on how you like to imagine your divide by zero operations playing out. ;)
So now the user has two things to keep in mind as far as silencing: which times it is programmed to do so automatically (all of which the user must be a bit suspicious of already - as you said, to be extra-sure the user would want to manually override even at those locations during times that it's really important for the ringer to be off) and which times they still have to manually override it. So we've got extra mental burden and anxiety for the user, partially or wholly overriding the savings of not having to worry about silencing in some circumstances. We're only trusting the system for those times where we'd really like it to work but it doesn't have to be guaranteed, so there's some lurking uneasiness during those times.
And the user has to program it. And I'd think it's very likely to be a significant battery drain since it's needing to turn on the GPS quite often to be useful. Etc etc.
Anyway, it's a super-cool sounding feature when just considered as a bullet-point, but it just strikes me as a "techno cool" feature (kind of like speech recognition and "Minority Report" interfaces) that I doubt I'll ever see widely used. I'm sure there are a few specific circumstances where it's really handy and I'm happy for those who enjoy it, but I have nearly no interest in it compared to a trusty manual switch and I think I'm speaking for the vast majority of users there. Could certainly be wrong.
However, one of them accounts for something like 90% of all the use cases I've ever seen proposed, in any forum, anywhere, for third-party multitasking on the iPhone, and really just boils down to one word: "Pandora". I've said elsewhere and will say again that Apple could probably placate a huge number of people simply by giving Pandora and no other third-party application an exception to the multitasking policy.
But in a larger sense I'm extremely skeptical of the claim that there are many "awesome use-cases that nobody has thought of yet", simply because of the two fundamental problems: form factor and resources.
First, the form factor problem: a mobile phone's screen can only be so large before the device stops fitting in a pocket, which means you get a certain amount of total UI real-estate, and that's it. Unfortunately, it's a pretty tiny slice of real-estate, which means that the traditional multitasking interfaces -- multiple windows, or multiple panes within a larger container -- don't work. You just don't have room on that screen for four or five applications and clear delineations between their screen areas to all be displayed simultaneously; you really don't even have room for two, because even if you cram all your stuff into that space you're still going to run right into Fitts' Law and have something that's unusable.
This means you get only one realistic UI option, which is that every application runs "full-screen". This may not mean using 100% of the screen area, but the size problem means you need to use so much space that there really isn't room for much else to fit alongside it. As a result, all the cool kids in the mobile OS field (iPhone OS, Android and WebOS) are doing the "fullscreen app" paradigm.
And then there's the resource problem, which has been discussed endlessly but not in particularly constructive ways. Every application that's running needs to have code and data resident, and a huge number of them want a network connection too. This means every additional application eats up more memory (a scarce resource on a phone-sized device) and power from running one of the device's radios (ditto -- and note that even if the app someone's interacting with at the moment doesn't need a network connection, odds are that some other running app does, so you don't even get a break when the user's not directly interacting with a network-using app).
This is a resource-management problem, and whatever solution is used for it will inevitably cascade back up into the UI. WebOS uses a card metaphor to cycle between applications, but launch a bunch of applications and the UI goes from responsive to... well, not responsive. Which suggests that, nice as the metaphor might be, it doesn't really work.
The other option, which is the one pretty much everybody else is going with these days, is to have a monitoring process serialize the state of and then terminate one or more applications when resources start running low. This also has the advantage of fitting nicely with the already-necessary fullscreen-app UI because from a UI perspective there's no interaction difference between "Leave App A running, but move App B to the front" and "Save App A's state, terminate it and launch App B". If you don't believe this, note that it's exactly what Android does when it runs low on resources; unless you're watching a process monitor you have no reliable way, as a user, to tell what it actually did when you hopped from App A to App B.
This is also indistinguishable from what the iPhone already does; any decent application already saves state on normal termination, so the fact that the application isn't really running anymore is only noticeable if it was meant to keep doing something in the background (like play music or pop notifications in response to events).
Which means that basic, built-in constraints of running on a mobile-phone-sized device, all by themselves, drastically limit the opportunities for meaningful multitasking. Because of the form-factor problem you can only ever have one application doing actual user interaction at a time, while all others have to sit in the background and do whatever they do without displaying interface (other than notifications) or requiring any serious interaction from the user (basically, you can pop "this thing happened" or "would you like to do X? Yes/No", and not a whole lot else because you don't have room for more UI without stealing full-screen focus, which is, again, indistinguishable from a serialize-and-terminate-and-launch).
Which brings us back, basically, to "play music while some other app is being used", and "pop up notifications". That's not exactly a rich playground of possible use cases; music is, well, music, and notifications are basically only worthwhile to do when:
1. Event X happens (e.g., IM or SMS received).
2. Clock reaches Time X (alarm, reminder).
3. Device arrives at Location X. This offers the largest number of possibilities, but there are still only so many pseudo-geocaching games, walking tours and social-network things you can do without flooding the app market with a bunch of essentially-duplicate applications.
So... yeah, there's really only the two use cases for multitasking: music, and notifications (which I tend to lump under "IM" since that's the one people would probably use the most).
As a side note, what's best for enabling this is not actually full multitasking (in the "every app stays completely resident running all its stuff" sense), but something much more like daemons which periodically wake up and do things.
These apps would at least have a modicum of usefulness, unlike the plethora of movie quote soundboard apps.
But then again there are all kinds of multitasking devices on the market, so nothing is really stopping the innovation of new use-cases. So I guess we do totally agree. I'm not so much worried about multitasking on the iPhone, since you're right that it's only currently preventing the (arguably) limited set of use-cases you describe.
In other words, exactly the way Android already does it? :-)