iOS Core Bluetooth state Preservation and Restoration issues

When you click home button to send app to background, it it suspended, and can handle Bluetooth delegates and run in background for 10s, this feature could be realize by " add bluetooth central in background mode in info.plist", and do not use State Preservation & Restoration.

If your app is terminated by IOS, due to memory pressure, it can't handle bluetooth delegates anymore. In this case, if you used State Preservation & Restoration, your app can be relaunched to background to run again, also for only 10s. After 10s, it would move to suspended state.Only in this situation, CBCentralManager's willRestoreState can be triggered.

You can add code

[kill(getpid(), SIGKILL);]

to a button action, when you click the button, your app will be terminated by IOS just like killed by memory pressure, and then "willRestoreState" will be triggered.

Good luck.

First, note that state preservation of view controllers has nothing to do with restoration of Core Bluetooth managers.

Important: Restoration doesn't work for scanning, static characteristics and generally any use cases that do not generate connection related events.

Now the steps:

1. Make sure any of the following on the tested app:
   • peripheral manager is advertising
   • peripheral manager has connected centrals
   • central is trying to connect to a peripheral
   • central is connected to some peripheral
2. Use this app to kill your app: https://github.com/ddaddy/BackgroundKill (kudos to ddaddy, give a star on the repo)
   1. Switch to the killer app
   2. Start the killing process and wait until it is terminated by the system
   3. You app is now killed
3. Do some connection event
   • (Tested peripheral) subscribe to characteristics on the peripheral
   • (Tested peripheral) start read requests on dynamic characteristics
   • (Tested central) make the connection request succeed
   • (Tested central) update subscribed characteristics on the peripheral

Depending on what you want to test, consider the applicable points in the list. Use logging in your tested app and watch the logs in the organizer to see what happens over time.

I was able to get this working with scanning in the background (along with connecting and transmitting data). There are important difference between how your app was terminated and if iOS will preserve and restore your Core Bluetooth Manager.

Adding "App communicates using CoreBluetooth" to "Required background modes" in Info.plist covers most situations. Your central manager will continue to work in the background — either when the user presses the home button or locks the phone (or both). However you will never get the "willRestoreState" delegate call in these scenarios as your central manager is still being handled by your application (it's still in memory).

Preservation and restoration only comes into effect in one scenario — your app was terminated by iOS due to memory constraints. The easiest way to force this for testing it to load 3-4 memory intensive games while your app is in the background. If you review the device console, you're waiting for this message:

"Apr  4 13:16:47 Michaels-iPhone SpringBoard[58] <Warning>: Application 'UIKitApplication:com.oculeve.TearBud[0x6df4]' was killed by jetsam.”

iOS will take over you central manager at this point. If it was scanning, it will continue scanning, if it was connect to a peripheral, it will continue to be connected. In the event that you receive a central manager delegate call (didDiscoverPeripheral, didUpdateValueForCharacteristic) iOS will launch your application again in the background. At this point you will get the willRestoreState delegate call. At this point your app is back in memory and will work as describe above. Note that you need may need to do some restoration in willRestoreState if you were connected to a device. This is all covered in the WWDC 2013 Core Bluetooth video demo.

The kicker seems to be that restoration/preservation does not work if you manually close the app from the system tray (swiping up on your app). I'm assuming Apple's reasoning for that is in this case the user is explicitly closing the app and all Bluetooth communication should cease. This is also true is the user restarts their phone. I'm assuming this is because a restart is basically equal to swiping up to close all the apps in the system tray. If you get to this point, you can only reconnect once the user opens your application again.

Something to point out is that just because your app is in the system tray doesn't mean it's in memory.

Why Apple doesn't just tell you this in the documentation is beyond me.