iOS background scanning and connecting

[stinodes]

One of our projects requires us to implement some background-processing, including responding to messages sent by the BLE-peripheral and scanning / connecting to said peripherals.

Receiving the messages and responding to them when the app is in background-mode seems to be working just fine (great work on that!), but I have not gotten scanning to wake up the app. Neither have I been able to find any issue or piece of documentation explicitly describing that this behaviour is or is not supported.

On a side note; when scanning, I pass serviceUUIDs (as seems to be required in iOS, as far as my limited knowledge goes), and this does filter out unwanted discoveries when in the foreground as expected.

Additional info

Expected behaviour

After following the steps to allow background BLE-central tasks, the iOS app should be able to receive and act on messages, disconnects, etc...
When powering up a peripheral, as it starts advertising, the app should discover it.

Actual behaviour

The app does respond to monitored characteristic changes and disconnects, and handles these as expected.
The app does not appear to discover my freshly powered peripheral, even though serviceUUIDs are passed as scanOptions. (The same process works just fine when in the foreground.)
Discovery does take place as the app is woken up by the user, and is handled as expected.

Specs/Versions

Device: iPod Touch
iOS Version: 9.3.5
XCode Version: 8.3.3
react-native Version: 0.41.0
react-native-ble-plx Version: 0.6.4

[stinodes]

I've been playing around with it some more.
Now, my loglevel is set to verbose, and both from the native library and the react-native side I manage to get some feedback from any bluetooth actions I can do from the background (e.g. turning on or off, updating characteristics if connected)

Only the discovery of peripherals seems to not trigger anything (both natively and from JS).

[stinodes]

In our case, we were working with a Nordic chip. In the app, we scanned for peripherals that advertised the Nordic service uuid, but our devices apparently advertised multiple services. Adding the other one (that was placed in the advertisement packet before the nordic service's uuid), fixed the issue in our case.