Reducing memory size to ensure backgrounding in iOS

Question

When developing an app that uses Bluetooth Low Energy, there comes a time when the iOS device loses connection to the peripheral. (Sometimes for hours.)

In order to reconnect to an existing peripheral, the app must constantly scan in the background at a specific rate throughout the day(s), even when the app is backgrounded.

The problem is, iOS will not guarantee that your app will not get killed, due to memory constraints, etc.

Information found in the iPhone OS Programming guide states that:

Apps that work with Bluetooth peripherals can ask to be woken up if the peripheral delivers an update when the app is suspended. This support is important for Bluetooth-le accessories that deliver data at regular intervals, such as a Bluetooth heart rate belt. When an app includes the UIBackgroundModes key with the bluetooth-central value in its Info.plist file, the Core Bluetooth framework keeps open any active sessions for the corresponding peripheral. In addition, new data arriving from the peripheral causes the system to wake up the app so that it can process the data. The system also wakes up the app to process accessory connection and disconnection notifications.

The problem does not arise when the phone is connected to a device and the application is background. It does happen, however, when the device is disconnected and the app is backgrounded. In this specific case, the phone is no longer connected to the peripheral, and therefore no longer getting notifications.

Many people have discussed this before, either on Stack Overflow or the Apple forums, and I believe one of the Apple developers has responded saying:

We're aware of this issue and are trying to come up with a solution. Currently, there is no workaround."

My question is, is there a way to at least improve your chances of not getting killed by iOS due to memory constraints?

For example, an instant messaging app (IMO) seems to run quite nicely in the background. After days and days of not being used, the app will wake up and display a gChat message.

I’m questioning things such as

• Strong pointers
• Overall memory size
• Reducing memory size when app is backgrounded or minimized
• Reducing frequency of background operation
• Etc.

Answer 1

Why do you need background execution even when the bluetooth hardware is disconnected? I don't think that you need to "rescan continuously" to reconnect again, if the hardware is "paired" with the iPhone/iPad, it will reconnect itself. Like a bluetooth headset. Or not?

AFAIK you have no chances to accomplish what you are asking for. A normal App is always suspended when the user go back to home. The app has approx. 5 secs of background time to stop timers, save state ecc ecc. There are special background modes that allows you to have more background time, and each of this mode (explained in the page you linked) has a different behavior.

About the bluetooth mode: The descripted behavior is not an issue, but it's by design:

• the app is suspended

• when the app is suspended, it can be killed by the OS to free ram (and there are no tricks to avoid this), but the system will wake up if needed.

• the app is then awaken every time a notification is received (awaken from suspended state or lauched from "previously-killed" state)

• the app has 10 seconds to do tasks (save informations, ecc ecc). Moreover, can request +10 mins. of background time for a particular task

• after the 10 secs (or 10 min) the app is suspended again

The example you wrote about the chat app is incorrect: chat apps usually doesn't use any background mode, simply they forward you messages using push notifications. When you open the app, the app connect to a server that stores all your messages and download it.

You can get "more uptime" using location background mode (routing app can work in background), or using a combination of significative location changes (the app is awaken) and the 10 minutes background time, but I think that Apple will reject an app that "abuse" this.

Shortly, you have to design your app to support this behavior.