manufacture data in scan/response is filtered after iOS 9

iBeacons must advertise as non-connectable using ADV_NONCONN_IND

This also makes them non-scannable, so iOS will not send a SCAN_REQ. Therefore will not receive any information contained in the SCAN_RSP

If you have an iBeacon device advertising out of spec, or a non-beacon peripheral advertising as an iBeacon, this is not a supported configuration and your results may not be what you expect.

Hi Gualtier,

Appreciate for the quick and clear response.

But I am a little confused and want to clarify one more thing.

In my test, if configure ibeacon ADV to connectable, ibeacon function still works fine with iOS 8 and 9.

And I double check some ibeacon vendor products, ex estimote, I can also see the ibeacon ADV with connectable flag.

It is a little conflict with your description "iBeacons must advertise as non-connectable using ADV_NONCONN_IND".

"iBeacons must advertise as non-connectable using ADV_NONCONN_IND" => this is what apple want user to follow or force user to follow?

In my test, when ADV is ibeacon and connectable, the manufacture type data in SCAN_RSP will be filtered at iOS 9 (ok at iOS 8) but service type data in SCAN_RSP can be retrieved correctly in iOS 9.

The data with manufacture type and service type in SCAN_RSP has different result in iOS 9.

That is why I want to double check it is a new rule or an unexpected side-effect to support manufacutre data concatenate.

iBeacons will work as advertised (pun not intended, but noted) when they are following the specs.

Otherwise the behaviour on the iOS side will be undefined, and can change from version to version, causing unexpected side-effects like the one you have seen.

Apple does not check or force whether any given proximity beacon is compliant with the specs. The spec is now free to access by anyone at https://developer.apple.com/ibeacon/

I suppose, in the end it all comes down to ones interpretation of the word "must".

Just fed up with vague comments. x_x

Apple should give developer distinct rule or guide of managing the BLE packet. Otherwise both manufacturer of beacon device and APP developer would suffer from painful maintenance while Apple changes iOS version without any notice.

It would be nice if you can comment on following question directly based on Apple's intended thought, since the spec is nothing more than a simple guide.

1. Is ADV_NONCONN_IND only suggested as type for iBeacon advertisement? What's about type of scannable but not connectable?

2. Is data in SCAN_RSP available from iOS callback while doing the scanning procedure to iBeacon devices (as the ADV packet is iBeacon format)?

3. What's the acceptable AD type PDU that iOS will pass it to callback? i.e. service data is tested as OK now on iOS9, but manufacturer specific data is not OK instead.