No they don't, that's the point. The first multitasking you talk about is basically app hibernation, it gets a CPU priority of 0 (no CPU at all but stays in memory), the rest are OS services the application subscribes to, and then the OS manages the rest.
Apart from Task Completion (maybe) the application never runs. With some services (location, background streaming/music, local notifications) a callback may run (on a timer or all the time), but not the whole application, far from it.
> As far as I'm aware, this is very similar to the way that Android implements it.
Nope, the UI part is handled the same way (by freezing it on switch) but in android there are no OS services, instead a backgrounding application works as a server daemon (faceless) and the UI is a client communicating with the daemon. Faceless daemons don't get frozen, because you can't "switch off" from them.
No they don't, that's the point. The first multitasking you talk about is basically app hibernation, it gets a CPU priority of 0 (no CPU at all but stays in memory), the rest are OS services the application subscribes to, and then the OS manages the rest.
Apart from Task Completion (maybe) the application never runs. With some services (location, background streaming/music, local notifications) a callback may run (on a timer or all the time), but not the whole application, far from it.
> As far as I'm aware, this is very similar to the way that Android implements it.
Nope, the UI part is handled the same way (by freezing it on switch) but in android there are no OS services, instead a backgrounding application works as a server daemon (faceless) and the UI is a client communicating with the daemon. Faceless daemons don't get frozen, because you can't "switch off" from them.