I have some questions about the changes that the latest IOS doesn't act (scanning or monitoring) for our custom beacon devices.
Since about 2015, We has provided some 'location based service' by using our custom iBeacon devices.
However We've just realized that the latest IOS devices doesn't work with our custom iBeacon devices. but also realized It could still work with the other normal iBeacon devices.
So, I've dig this issues for a while and finally I got the answer. It's because the one byte of Ibeacon advertsing packet payload.
the followings are the differences about manufacturer data part between a normal Ibeacon and our custom beacon.
- normal Ibeacon
0xFF 0x4C00 0x02 0x15 0x736E75685F70656F706C655F74656331 0xEA61 0x03EB 0xC5
- our custom Ibeacon
0xFF 0x4C00 0x02 0x15 0x736E75685F70656F706C655F74656331 0xEA61 0x03EB 0xC5 0xDA
Yes, I know. after many of searches and research, Now I've understood the byte (meaning the length of following payload) should be changed as '0x16'.
But It is certainly something that has worked well not so long ago.
Anyway, The introduction was so long, but this is the one question what I'd like to ask about.
I need to know exactly which version of IOS this change came from. (I've tried but I couldn't find any thing about this on the official documents.) I need to expaing to my customers what's going on. for that, I need the information that exactly which version of IOS It didn't work from.
Thanks in advance. Regards.
Just to clarify, there has not been any changes to the iBeacon specification, or how the packets are interpreted.
What has changed in iOS 18 is, some invalid advertising payloads that happened to work (like having an extra byte at the end) before, are now more strictly parsed and iBeacon packets that do not follow the specifications fully may be rejected.
While we have relaxed the strict checking a bit in iOS 18.2 (not sure if it would apply to your in-compliant packets, so you may want to test), my suggestion would be to follow the specs exactly, and do not assume that just because a little difference works now, does not mean it will continue to work tomorrow.
Specifically to your comment about what that extra byte was - I don't know what you mean by "following payload", but there is no "following payload" for iBeacon advertisements. Every advertisement packet should be a single ADV_NONCONN repeating continually. Perhaps your custom beacon devices are doing things differently, which may be fine for now, but keep in mind that anything that is not according to specifications run the risk of suddenly stop working as things get fixed.
Argun Tekant / DTS Engineer / Core Technologies