Hello, I would like to consult Apple’s technical team regarding how different iBeacon Bluetooth advertising packet configurations impact iOS app background wake-up performance. My specific questions are outlined below: We have two available iBeacon advertising configuration schemes: Scheme 1: Encapsulate the non-connectable iBeacon advertising payload and connectable Bluetooth advertising payload into a single advertising packet for transmission. Scheme 2: Split the two types of advertising payloads above into two separate independent advertising packets and broadcast them respectively. Could you please clarify which packet format enables iOS apps to detect and recognize iBeacon devices more reliably and easily, thereby triggering app background wake-up more effectively? I would appreciate it if you could explain the differences, advantages and disadvantages of these two schemes under iOS’s Bluetooth scanning and app wake-up mechanisms, as well as provide your official recommendations. Thank you very much for your assistance.
The simple answer is "NO!" but let me elaborate on that. Whether you can get a successful result or not will depend on why are you doing all this.
Could you please clarify which packet format enables iOS apps to detect and recognize iBeacon devices more reliably and easily
If you want your iOS app to detect and recognize iBeacon devices reliably you need to follow the iBeacon specifications fully. Including following the calibration procedure to add a correct Measured Power data field.
Anything else, every bit of deviation from the specifications will be less reliable, and any juggling you are planning to do, in order to make the iBeacon devices behave for anything other than what they are designed for, will be much more difficult - with questionable results.
To make this clear: the iBeacon specification describes devices which are meant to be used as is with the CoreLocation framework, to alert your app (or a user directly) when they are in the proximity of a device. Any other use case is not supported - if you can make it work, great, but if you spend time and resources to try getting it work, and it does not, there isn't much we can do to help other than pointing you at the specs.
As to your two suggested schemes:
Scheme 1: Encapsulate the non-connectable iBeacon advertising payload and connectable Bluetooth advertising payload into a single advertising packet for transmission
Don't understand how exactly you are planning to combine these packets. If you are encapsulating iBeacon into a regular BLE advertising packet, that is no longer an iBeacon. The CoreLocation APIs won't work with that. Now you will have some custom BLE advertisement, and if you are able to squeeze in some "beacon" information into the advertisement and able to decode that information yourself, I suppose you could do that. But this is no longer an iBeacon and your app won't be woken up using the CLMonitor or Region Monitoring APIs.
Scheme 2: Split the two types of advertising payloads above into two separate independent advertising packets and broadcast them respectively.
This, you can do, but for this to work you must do one of the following :
- use two separate radios to advertise each
- use a chipset that can switch its bluetooth address between two advertising packets
- use BLE 5 advertising sets. Advertising Sets allow you to identify yourself as two completely different devices, which can have separate payloads
When you advertise totally different payloads from the same Bluetooth address within milliseconds of each other, you could possibly break our dedupe filters. This is going to possibly break something and end up with undefined behavior (not to mention increase the battery drain on the users' devices). When you run into the issue where the advertisements are not being handled as expected, we will likely throw our hands up and ask you to fix that behavior.
So, it comes down to why you are doing this. The most common reason we see developers try to use such tricks is to engage the app wake-up behavior of iBeacon APIs while having the full functionality of CoreBluetooth APIs. If that's your main goal, I can tell you that the CoreBluetooth State Restoration works more strongly if you use AccessorySetupKit
If you want our recommendations: use every API and specification for its intended purposes, and do anything else at your own risk
Argun Tekant / WWDR Engineering / Core Technologies
