You're right. There's no way that allowing apps to spawn as many processes as they want, running for as long as they want, is a good idea.

But there is a middle ground. Like already mentioned, if you register for location updates you can do a small amount of processing when your device moves and the OS wakes up a (very small) portion of your app to respond to it. If your app runs for too long here it will simply be killed.

Apple has created a very small number of cases where an app is even allowed to do this, which puts a huge cap on what people can do with it. The IM case is the most egregious: I can get a push notification saying "Bob messaged you: Let's meet up at..."

You tap on the notification, your app opens. It has to load from a cold start. Then it has to go to the server and fetch Bob's message to you, even though your notification obviously already had it. All in all, it's 10-15 seconds before you're actually reading the message, which is unacceptable.

You can put a payload into your push notification (as long as you're not going over 256 bytes). The developer guide says that notifications should not be a way to send data to your app, but what they mean by that is that it should not be the only way that your app gets data. You can use a custom payload to "cheat" with the UI (much like how Apple's blank UI splash screens are meant to make the UI look faster), and present the user with at least some new data while the app loads all of the up-to-date data in the background.

Yup. Freaking google voice does this and it can takes minutes to load the text message if you have poor signal.

Audiobus only works because Apple's multitasking rules specifically allow audio apps to work in the background. It's not limited to just VOIP apps; for example, I use Dropvox all the time to record while my phone is locked. Not saying Audiobus isn't cool, but it's really not even close to equivalent to Android's intent system, and it doesn't solve the same problem.

Make it a notification setting then, you can already decide what type (if any) of notifications may appear on an app-by-app basis. It's just ridiculous that there's a notification of a new message sent to the device and then the message is not immediately available in the app.

Background services work just fine on Android. It's very handy to know that my shared to-do list syncs automatically (thus it's up to date when I actually open the app, even if I don't have signal at the time), or that my photos get synced to Dropbox without me having to open Dropbox.

Apps can register for notifications of significant location changes, and this wakes them up and lets them do some processing in the background. Allowing apps to temporarily wake up upon receiving a notification doesn't seem any worse than that.