iOS Task Completion API abuse

As many of you are aware, iOS4 introduced several APIs that bring some degree of multitasking to iOS applications: one of them was originally meant to give an app the extra chance to finish some worthy tasks before getting suspended: it’s called “Task Completion API”.

Unfortunately this API has become a free ticket for up to 10 minutes of background execution that every app can get, even the ones that don’t need it.

This means some apps may ask for extra CPU time and remain in background execution for as long as 10 minutes (the limit set by the iOS).
The problem is that we have no quick way of telling wether this extra time is being used for the completion of a useful task or if it is being abused.

With the help of the “Instruments” application included with Xcode I’ve tried to analyze the behavior of a few common apps and noticed that Task Completion abuse actually happens with at least two very popular titles: “Whatsapp messenger” and “Facebook messenger”.

Instruments’ Activity Monitor shows how regular iOS apps like Twitter and Foursquare are suspended by the OS a few seconds after returning to the home screen.
Whatsapp and FB Messenger instead ask for extra background CPU time in order to wait for incoming chat messages. After the 10 minutes period expires the apps are suspended and therefore switch to the Push Notificaiton API to receive incoming messages.
While this behavior may seem harmless it is actually preventing the CPU from sleeping and drains a considerable amount of battery. In fact, even if the apps aren’t doing much work, their used CPU time keeps increasing at a slow albeit constant pace.

Yes it’s true that after 10 minutes these apps will be suspended anyway and the CPU may then sleep, but only if we aren’t using them in the meantime!
For example, say we send a chat message, lock the phone and wait for 9 minutes, then we send another message, lock the phone and wait for another 9 minutes and so on… Our messaging application will use the Task Completion API each time and therefore will never be suspended because it is brought back to the foreground before its 10 minutes extra time expires.

Suspended apps aren’t allocated any CPU time thereby increasing the chances the CPU has to go to its sleep state: in an ideal scenario, the 9 minutes between each chat message would have been all eligible for the CPU to sleep!

I think the developers of these applications should rethink about their design choices and avoid using the Task Comlpetion API because it doesn’t fit in this particular use case. The traditional Push Notification API should be always preferred instead.