iOS8 -Delay in returning correct currentReachabilityStatus

[Pradip-Parkhe]

When I turned internet off, currentReachabilityStatus method returns value NotReachable after 3-4 seconds. Device- iPhone 5c with iOS8.0 beta

[cheddercaveman]

I am noticing this as well on iOS8.0 beta 5 (Xcode beta 6). I have tested with an iPad 3, Air, and Mini and I am seeing the same delay as @Pradip-Parkhe

[TitouanVanBelle]

Same issue here. I'm noticing a ~5s delay when switching the airplane mode ON.

[krosullivan]

+1 Getting the same thing. Takes maybe 2/3 seconds for the isReachable bool to respond correctly. Using iPad 3 8.0..2

[AlBirdie]

Another +1 from me. Running iOS 8.1 on iPad Mini 2, and iPad 2.

[tonymillion]

Yeah, I think I've seen this.

Basically the call to SCNetworkReachabilityGetFlags is blocking the thread you are calling it on (this is an Apple function).

So theres a few solutions:

1. Leave it as it is
2. Use a cached copy of the reachabilityFlags which may end up being not current with the real-world connectivity
3. Implement a new asynchronous method that calls a block when SCNetworkReachabilityGetFlags returns.

Opinions?

[AlBirdie]

I'd vote for option 3. Not addressing the issue would be a real bummer as a rapid notification about a changed network status is what makes this project so valuable.

[Mazyod]

Wouldn't the cached approach be the most backward compatible? Or is the called block the same one we are registering in the first place?

[ZuzooVn]

Are there any solution to fix this problems with iOS 8?

Thank you

[TitouanVanBelle]

I'd go for 3. too

[tonymillion]

Just a FYI, when currentReachabilityStatus is called, Reachability tries to make a ICMP to the host you've specified. This obviously takes time to wait for a response to determine if the host can be reached.

If possible you can use the background notifier (either the block or NSNotification) instead of calling currentReachabilityStatus, simply store the status in a variable in your class and use that.

Ideally you should never have to call any of these functions on the Reachability class, as you should always try your network IO then, if it fails, queue it up (i.e. save it to an array of pending network IOs) and try again once the background reachability event fires (again either block or NSNotification).

Similarly you can listen for background network change events and trigger a UI refresh (and associated network IO) when the background notifier tells you its reachable. Indeed this is what I do in my apps, they never specifically call into the Reachability class, other than to start a notifier, then everything else is triggered based on the callback.

[leofto]

Is there a fix in progress?

[tonymillion]

Check the V4 branch - its asynchronous & uses block based callback for getting current reachable status:

https://github.com/tonymillion/Reachability/tree/v4dev

[abargh]

Still seeing the same problem (especially with loss of wifi connection) with the v4dev branch on iPhone 6 / iOS 8.3. Ran the iOSReachabilityTestArc project on the device. Backgrounded the app, turned off wifi and foregrounded the app again. A 3 - 4 second delay before the UI catches up. Any ideas?

[sunlive]

@tonymillion it seems to be regression from iOS7. Any updates on this? Can we expected this to be fixed in the future? Thanks

[zihang-wu]

IMPORTANT: Reachability must use DNS to resolve the host name before it can determine the Reachability of that host, and this may take time on certain network connections. Because of this, the API will return NotReachable until name resolution has completed. This delay may be visible in the interface on some networks.

[bkodres93]

Any word on when the asynchronous changes will make it into master, @tonymillion?

edit: or tagged and into the pod?

[smallg]

Any news for this issue?