[potatolicious]

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.

[rmrfrmrf]

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.

[epochwolf]

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