Oh no, now you've done it :) I'm an iOS dev full-time, so this is a favorite topic...
- Multitasking architecture is broken for many use cases. The biggest one is any sort of messaging application - your app doesn't actually execute any code when a notification comes in, so when your user reacts to the notification and launches your app, your app has to go and re-fetch much of the same data that the notification already carried. This comes across to the user as being slow and finicky.
- Basic UI paradigms are behind what the community is pushing. This isn't a lag behind competing OSes, but rather lagging behind itself. Apple used to be the flag-bearer for the state of the art of iOS UX, but the community has largely taken over to both good and bad results. See: pull to refresh, launch screens, side menus, etc. Apple can, and should, reclaim its position as being at the leading edge of its own platform.
- Lack of a proper inter-app communications channel. Intents on Android is very powerful, something like this is totally lacking in iOS.
- Lack of customizability when it comes to core functions. I cannot associate all mailto: links in the browser to GMail for example. I must use Apple's Mail. Ditto for Maps.
There are a bunch of others, but today is a rather busy day :P
As a user, I prefer knowing that if an app is in the background, unless it's VOIP or Satnav it's not doing anything. We've seen what happened when apps can do what they want - they will abuse system resources. As a developer, I can appreciate the need for limits on the notification system for the sake of scale.
Oh and and inter-app communications channel you're after is it? http://audiob.us
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.
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.
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.
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.
Obvious, but frustrates me everyday: inter-app communication. The whole OS feels like some odd riddle where no one is allowed to talk to one another and you still have to get things done.
Interapplication communication (i.e. intents). JIT-compiled javascript in hosted webviews. Bluetooth communication of many types, NFC of all types. WebGL support. That's just off the top of my head, I'm sure there's more, and these may not matter to you, but there is a functionality gap.
Ditto on the above lists. Similar to inter-app communication issue is some way to meaningfully work with documents and data outside of application silos, either to share documents between apps, or to get documents onto and off the device.
This is more of a hardware nit, but the iPhone is very annoying to hold in the hand. I expect Ive to step it up here and do something more like the curved edges of the Nexus 4, or even the less curved but still more comfortable HTC One.
