I am trying to add a feature to my HomeKit app so it is able to observe HomeKit database changes, particularly when there is a change of the value of particular characteristics, while it is in the background. The use case here is to be able to notify users through local notifications when sensors change state (such as a door sensor opening/closing) even if the app is not in the foreground. Better still, I would like the OS to open my app from a terminated state upon state change, but I understand that may not be possible. Traditionally this is accomplished by using Background Modes, though there is not a background mode particular to HomeKit. There is a background mode for "External accessory communication", which upon reading further into it is devices that abide by the EA framework. Apple's documentation on this states "To prevent namespace conflicts, protocol names are specified as reverse-DNS strings of the form com.apple.myProtocol", but the purpose of HomeKit is to provide a common protocol that all MFi HomeKit accessories communicate on. I guess what I'm getting at here is what am I missing? I don't know what value to supply for the UISupportedExternalAccessoryProtocols key in the info.plist file for HomeKit accessories, or if this is even the right way of going about it.
More interesting still, I have noticed that either my app for XCode is caching state changes of those characteristics while the device is connected to debugger (which apple explicitly states in the Observing HomeKit Database Changes guide that "changes are not batched when your app is in the background", although this particular section of the guide is referencing observing changes made by HMHomeManager such as adding rooms, not changes of values of characteristics. When the app is running and in the foreground, the accessory (...didUpdateValueFor) delegate is called when the value of a characteristic is changed. When the app is running in the background (Application does not run in background set to NO in info.plist and debugger stays attached) when the value of the characteristic changes, the delegate is not called. The particular finding of interest is that when the app is brought into the foreground again, the accessory (...didUpateValueFor) delegate is called the number of times that the value of the characteristic changed while it was running in the background.
My findings are leading me to the same mixed conclusion I've had regarding if it is possible for an app built on the HomeKit framework to surface local notifications while running in the background when the value of characteristics changes. Any help or guidance on this is greatly appreciated!
