Issue with iOS 10

[andersborgabiro]

This might not have directly to do with the plugin, but is probably rather due a change in the iBeacon behavior in iOS.

Anyway, it detects only a few of the "pings", making my app think the beacon is gone. This despite having a 10-second timer for that. The beacons are set to broadcast each second at 0 dBm.

This is consistent for iOS 10 and is not device dependent: iPhone 5 and iPhone 6 behave exactly the same. With 9.3.5 it worked fine though.

Anyone knows why this is so, and whether there's any workaround?

Update 1: From a pure BLE standpoint the phone receives packets every second, but from a beacon standpoint, those packets are only rarely reflected in didRangeBeaconsInRegion.

Update 2: If I uninstalled all iBeacon-detecting apps, rebooted, and then installed only one such app, it seems to work fine.

[codingjam]

I have not noticed the issue that you are describing. Ranging seems to work fine for me on ios 10, but I am facing a different issue with after updating to ios 10. The enter/exit region events do not always trigger. I am noticing a strange behavior, sometimes they work and sometimes they don't. It was all working perfectly fine until I updated to ios 10. For some beacons Exit Region event is never triggered even when I turn off the beacon for a long time, when I urn it back on it directly starts ranging. Something has changed in iBeacon behavior in IOS 10 which is causing this strange behavior.

[andersborgabiro]

To summarize my issue: if more than one app is ranging the same region (in my case UUIDs with wildcard major/minor) iOS 10 will drop most events. I'm no longer relying on enter/exit region, but I've seen the same thing as you have.

[sKuD51]

I confirm codingjam said, Enter / Exit region event doesn't work on iOS10, I have sames troubles.
andersborgabiro : this probleme is really strange, I didn't tests-it. What you mean is : I can't have more than one app ranging for the same beacon in same times ?

[andersborgabiro]

That seems to be the case. I'll do some more testing to verify. With only one app it's back to normal. There was a 10.0.2 today that I will upgrade to first.

[andersborgabiro]

After upgrading and removing all beacon-active apps (the ones I had control over) and rebooting and then reinstalling only one of the apps: The same low frequency behavior as I previously indicated for multiple apps, so that theory was not the correct one. I don't know what I did previously to make it work.

[sKuD51]

Ok thanks for return.

[andersborgabiro]

Further testing indicates it's possible to get back to correct behavior, but I haven't found a pattern. It's at least not because many wildcard regions are monitored and ranged. I'll await reports from users, as most users will not install more than one beacon-enabled app anyway.

[tomtomau]

I have absolutely no experience in this plugin, but you might be experiencing this:

http://stackoverflow.com/questions/39638067/swift2-3-code-for-beacon-detection

[sKuD51]

@tomtomau thanks for this "solution" . It's really incredible ...

[andersborgabiro]

Yup, this seems to be it.

[gnazarkin]

Experiencing the same issue. Is there a solution to permanently solve the didEnter and didExit events?

[andersborgabiro]

The problem is in iOS 10, so Apple has to do something.

[tomtomau]

I had read some suggestions on StackOverflow that iOS is system-wide limited to polling for 30 beacons in CoreLocation. I had the Estimote app installed on my phone amongst a few other beacon apps.

By uninstalling these apps and rebooting my iPhone on iOS10 beta 2 (consistent with @andersborgabiro advice) I've had some improved successes with beacons, but I'm experiencing some dropouts from time to time when the beacon is right next to the device. At this stage, I haven't worked out if this is beacon related or device related though.

[andersborgabiro]

Supposedly that limitation doesn't exist when ranging, which is what I use, still having this problem. I use region enter/exit too, mainly for verification, but they work independently. The "sometimes works, sometimes not" behavior I've also seen.

[codingjam]

I wonder if this issue is related to ios 10? #259 Did someone experience this issue with iOS 10?

[andersborgabiro]

It could be related, but it happens when the app is running too. I wish Peter would provide a comment.

[codingjam]

I was able to get monitoring to work on ios after the app is killed. So, it probably is not an iOS 10 issue, but I don't know why it started working suddenly #259

[andersborgabiro]

I'm experiencing the same, and then some other time it doesn't work, so it might very well still be a problem with iOS.

Did you change anything in your code? Did you upgrade to a later plugin or Cordova core?

[codingjam]

No, I didn't change anything. It just doesn't work every time.

[andersborgabiro]

It seems to work better with 1.10.1.

[parkej60]

What we've found is this issue has to do with the RSSI thresholds set within the iOS Framework that trigger the didEnter & didExit region events. The beacons we were using were throwing out a very low RSSI that was very rarely exceeding the didEnter threshold. We swapped out the beacon for one that had a very high RSSI and we we're no longer seeing the issue.

[andersborgabiro]

Very high = 0 dBm or thereabouts?

[littlemercury]

@andersborgabiro Not sure if this is still an issue for you, but I was able to overcome the problem by resetting the delegate before ranging. Probably not the most practical solution as I'm not monitoring any regions, just actively ranging when a user loads a particular page, and then stopping when the page is exited, but it solved the problem.

[andersborgabiro]

I changed the code to not rely on enter/exit region as a trigger for ranging, and ranging is not affected.

But if more than one app listens to the same region, only one app seems to get didDetermineStateForRegion calls. This is consistent for iOS. It surely doesn't have anything specific to do with this plugin.

[petermetz]

Hi All, thanks for all the information on this. Unfortunately I can't see any way the plugin could provide a fix for this issue as it seems to be something in lower levels in iOS.

Of course we could put in some of the workarounds you mentioned, like the periodic resetting of the delegate, but these kind of changes tend to create more questions than solutions, because all later bugs will have to be triaged against that certain angle as well: "Is this new bug caused by that shady workaround we did to solve that other bug?".

If anybody has any suggestions (with deterministic ways to test/reproduce/verify) then please make it known here and we can pick up the discussion again.