Central talking to one custom peripheral, CoreBluetooth state restoration enabled. Behavior I understand: iOS kills the app for memory pressure, peripheral does something, restoration relaunches into the background. Documented, and I have watched it work. Behavior I do not: I force-quit from the app switcher. The device had been unplugged and off for about a week. Plugged it back in and within a minute it had fresh data that only my app could have sent. So the app ran, and I never opened it.
Everything I have read says force-quit is a hard opt-out until the user launches again. The only theory I have is that this is not the same event class as what I tested before. Earlier tests were all notifications from an already-connected peripheral. This time there was a connect request outstanding from before the force-quit, and it completed when the device came back. Possibly a pending connection completing is handled differently than traffic on a live link.
I do not have instrumentation on this yet, so I cannot say whether it relaunched or was still resident, and I cannot rule out that the phone rebooted sometime during the week. Adding logging before I try to reproduce.
Has anyone characterized this properly? Specifically whether a connectPeripheral pending from before a force-quit survives, and whether its completion can trigger relaunch. The docs do not draw that distinction.
