Is it possible for iOS to continue BLE scanning even when the app goes into the background?

Question

koba_0 OP

Created Apr ’25

Replies 3

Boosts 0

Participants 3

Nice to meet you, I'm currently trying to create an app like a data logger using BLE.

When a user uses the above app, they will probably put the app in the background and lock their iPhone if they want to collect data for a long period of time.

Therefore, the app I want to create needs to continue scanning for BLE even when it goes into the background.

The purpose is to continue to obtain data from the same device at precise time intervals for a long period of time (24 hours). In that case, can I use the above function to continue to read and record advertising data from the same device periodically (at intervals of 10 seconds, 1 minute, or 5 minutes) after the app goes into the background?

Any advice, no matter how small, is welcome. Please feel free to reply. Also, if you have the same question in this forum and it has already been answered, I would appreciate it if you could let me know.

Answered by ssmith_c in 836778022

I'd advise against this, but it depends on exactly what your requirements are.

BLE connections are low power because the radio can turn when there is no data to transfer. A "connection" implies that the receiver and transmitter are tightly synchronized, but this synchronization falls apart if you push the connection interval out to 5 minutes. Usually, connection intervals are in the tens or hundreds of milliseconds range.

Most types of connections aren't going to be maintained in the background - your app is competing with others for antenna time and energy from the battery.

Radio connections are unreliable. You can't expect every transmission to arrive at the receiver intact, so using the phone to log data is likely to be disappointing, unless either:

a. you don't care about the occasional missing sample, or

b. you buffer samples on the logging device and upload historic data in a batch

Lastly, advertising isn't a great way to log data with any temporal precision. The advertising device is usually something with a real time OS and nothing better to do, so it can send advertising packets at regular intervals. The scanning device, however, doesn't know when those advertising packets are being broadcast, so it will generally turn on its receiver at irregular intervals. Even if it were to keep its receiver on permanently, it doesn't know what channel to listen to (advertisements cycles through three different advertising channels). On top of that, you can't fit much data in a regular advertising packet.

Extended advertising in BLE 5 allows for more efficient advertising of larger packets, but I don't know how much support for extended advertising is built into iOS and the various phone models.

If I were trying to make a data logger, I'd log on the device and have an explicit, user-driven data download procedure from a foreground app.

If you're more interested in status than logging, advertising might be an option. If your data requirements are low, and timing isn't critical - e.g. if you're monitoring temperature every 10 minutes, you might be able to leverage iBeacon technology.

Boost

Answer 1

ssmith_c OP

Apr ’25

Accepted Answer

I'd advise against this, but it depends on exactly what your requirements are.

BLE connections are low power because the radio can turn when there is no data to transfer. A "connection" implies that the receiver and transmitter are tightly synchronized, but this synchronization falls apart if you push the connection interval out to 5 minutes. Usually, connection intervals are in the tens or hundreds of milliseconds range.

Most types of connections aren't going to be maintained in the background - your app is competing with others for antenna time and energy from the battery.

Radio connections are unreliable. You can't expect every transmission to arrive at the receiver intact, so using the phone to log data is likely to be disappointing, unless either:

a. you don't care about the occasional missing sample, or

b. you buffer samples on the logging device and upload historic data in a batch

Lastly, advertising isn't a great way to log data with any temporal precision. The advertising device is usually something with a real time OS and nothing better to do, so it can send advertising packets at regular intervals. The scanning device, however, doesn't know when those advertising packets are being broadcast, so it will generally turn on its receiver at irregular intervals. Even if it were to keep its receiver on permanently, it doesn't know what channel to listen to (advertisements cycles through three different advertising channels). On top of that, you can't fit much data in a regular advertising packet.

Extended advertising in BLE 5 allows for more efficient advertising of larger packets, but I don't know how much support for extended advertising is built into iOS and the various phone models.

If I were trying to make a data logger, I'd log on the device and have an explicit, user-driven data download procedure from a foreground app.

If you're more interested in status than logging, advertising might be an option. If your data requirements are low, and timing isn't critical - e.g. if you're monitoring temperature every 10 minutes, you might be able to leverage iBeacon technology.

1

Answer 2

koba_0 OP

Apr ’25

Thank you for your reply, ssmith_c. Let me ask the question again to better understand.

The requirements are as follows: ・A graph app to see changes in data ・measured data is about 2 bytes. ・measurement time is more than 24 hours. ・I want to obtain samples as finely as possible.

Let me ask again, taking the above into consideration. ①Is iBeacon possible even if the app is in the background?

＞If I were trying to make a data logger, I'd log on the device... ②Does "log on the device" mean a connection via GATT communication? Also, does this refer to "b.", which ssmith_c answered?

0

Answer 3

Engineer OP

Apple

Apr ’25

@ssmith_c gave you good advice. But let me clarify the limitations here.

While you can continue to scan in the background, you can only do that until the accessory is discovered. The purpose of discovery is so the app can connect to the accessory. Once you get the didDiscoverPeripheral() callback and don't take any action (like connecting), you will not receive any further callbacks.

In summary, you cannot continuously scan to read continually changing data in the advertisement packets when in the background. When in the background you will only receive one didDiscover() callback per peripheral per scan.

So, to continuously receive changing data from an accessory what you need to do is to connect to it, and then subscribe to a notifying characteristic (if the accessory presents one), and get updates that way. I believe that's what @ssmith_c meant by "Log on to the device"

As for using iBeacon technology instead. This will be an off-label use of iBeacons, which is technically a CoreLocation API, not a CoreBluetooth one. While you may figure out a roundabout way to do that, I would not be able to bet that it will work the way you think it would.

So, the proper way of doing this is to connect to the accessory and read the data from it.

Argun Tekant /  DTS Engineer / Core Technologies

1