AlamoFire full IPv6 support

[racer1988]

Hello,

Due to http://9to5mac.com/2016/05/04/apple-will-require-ios-app-store-apps-to-support-ipv6-only-networks-from-june-1/

I am opening this for raising a small issue, but also to ask a question.

Is alamofire fully supporting IPv6?
referencing the doc from Apple
https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW1

I haven't found any hardcoded IP address or reference to low level api apart those:

NetworkReachabilityManager.swift
is using IPv4 only:
AF_INET
and
sockaddr_in

Apple suggest to support also IPv6 counterparts:
https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW12

If your code handles IPv4 types, make sure the IPv6 equivalents are handled too.

IPv4
IPv6
AF_INET
AF_INET6
PF_INET
PF_INET6
struct in_addr
struct in_addr6
struct sockaddr_in
struct sockaddr_in6
kDNSServiceProtocol_IPv4
kDNSServiceProtocol_IPv6

Thanks

[cnoon]

Your concerns here are perfectly valid @racer1988. The problem is that Apple isn't clear on whether apps supporting iOS 8 are going to be held to these same rules. If you check out #1086, you'll see that the reachability APIs don't work correctly on iOS 8 with IPv6. Therefore, I rolled back to the IPv4 APIs for iOS 8. I can certainly undo that change, but that will break reachability for anyone running on iOS 8.

An alternative approach would be to only make the NetworkReachabilityManager available to iOS 9 and above, but I'd rather not do that.

I'm going to leave this issue open for now. Maybe the community can help us decide on what the best solution is here.

[cnoon]

Your concerns here are perfectly valid @racer1988. The problem is that Apple isn't clear on whether apps supporting iOS 8 are going to be held to these same rules. If you check out #1086, you'll see that the reachability APIs don't work correctly on iOS 8 with IPv6. Therefore, I rolled back to the IPv4 APIs for iOS 8. I can certainly undo that change, but that will break reachability for anyone running on iOS 8.

An alternative approach would be to only make the NetworkReachabilityManager available to iOS 9 and above, but I'd rather not do that.

I'm going to leave this issue open for now. Maybe the community can help us decide on what the best solution is here.

[cnoon]

cc @kcharwood, @jshier, @kylef, @AnthonyMDev.

[cnoon]

cc @kcharwood, @jshier, @kylef, @AnthonyMDev.

[dgatwood]

iOS 8 didn't have NAT64 support, so any iOS 8 device on an IPv6-only network would be hopelessly crippled. Based on that, I'm pretty sure that as long as your code uses the IPv4 APIs only when actually running on iOS 8 and earlier (i.e. run-time checks, not build-time checks), you should be fine.

[dgatwood]

iOS 8 didn't have NAT64 support, so any iOS 8 device on an IPv6-only network would be hopelessly crippled. Based on that, I'm pretty sure that as long as your code uses the IPv4 APIs only when actually running on iOS 8 and earlier (i.e. run-time checks, not build-time checks), you should be fine.

[racer1988]

@cnoon @dgatwood Thanks :D

if the issue is < iOS 9 why not putting the IPv6 code wrapped in

if #available(iOS 9, *)

and in a else the IPv4 support for all other iOS versions?

[racer1988]

@cnoon @dgatwood Thanks :D

if the issue is < iOS 9 why not putting the IPv6 code wrapped in

if #available(iOS 9, *)

and in a else the IPv4 support for all other iOS versions?

[cnoon]

That's exactly what we do now @racer1988 in the NetworkReachabilityManager.

[cnoon]

That's exactly what we do now @racer1988 in the NetworkReachabilityManager.

[racer1988]

AND LOL! 😫

I did a grep and didn't see it :D

[racer1988]

AND LOL! 😫

I did a grep and didn't see it :D

[AnthonyMDev]

So if we are already checking for iOS 9, then this isn't an issue, right?

[AnthonyMDev]

So if we are already checking for iOS 9, then this isn't an issue, right?

[cnoon]

Unfortunately, it's just a running theory right now @AnthonyMDev...we don't have a definitive answer yet. I tend to agree with @dgatwood, but I'd much rather be certain.

[cnoon]

Unfortunately, it's just a running theory right now @AnthonyMDev...we don't have a definitive answer yet. I tend to agree with @dgatwood, but I'd much rather be certain.

[cezheng]

The current implementation of Alamofire's Reachability just uses sockaddr_in6 on iOS 9 or later. Will this cause any problem if the device happens to be connecting to a IPv4-only network?

However in the README of the Reachability sample, it says

Reachability fully supports IPv6. More specifically, each of the APIs handles IPv6 in the following way:

...

_reachabilityForInternetConnection: This monitors the address 0.0.0.0, which reachability treats as a special token that causes it to actually monitor the general routing status of the device, both IPv4 and IPv6._

and the implementation actually uses sockaddr_in

+ (instancetype)reachabilityForInternetConnection {
    struct sockaddr_in zeroAddress;
    bzero(&zeroAddress, sizeof(zeroAddress));
    zeroAddress.sin_len = sizeof(zeroAddress);
    zeroAddress.sin_family = AF_INET;
    return [self reachabilityWithAddress: (const struct sockaddr *) &zeroAddress];
}

[cezheng]

The current implementation of Alamofire's Reachability just uses sockaddr_in6 on iOS 9 or later. Will this cause any problem if the device happens to be connecting to a IPv4-only network?

However in the README of the Reachability sample, it says

Reachability fully supports IPv6. More specifically, each of the APIs handles IPv6 in the following way:

...

_reachabilityForInternetConnection: This monitors the address 0.0.0.0, which reachability treats as a special token that causes it to actually monitor the general routing status of the device, both IPv4 and IPv6._

and the implementation actually uses sockaddr_in

+ (instancetype)reachabilityForInternetConnection {
    struct sockaddr_in zeroAddress;
    bzero(&zeroAddress, sizeof(zeroAddress));
    zeroAddress.sin_len = sizeof(zeroAddress);
    zeroAddress.sin_family = AF_INET;
    return [self reachabilityWithAddress: (const struct sockaddr *) &zeroAddress];
}

[cnoon]

Pretty sure you posted on the wrong project @cezheng.

[cnoon]

Pretty sure you posted on the wrong project @cezheng.

[cezheng]

@cnoon
Why would you say that?
https://github.com/Alamofire/Alamofire/blob/master/Source/NetworkReachabilityManager.swift#L125

I just think the implementation of Alamofire's Reachability might be problematic on IPv4 only network

[cezheng]

@cnoon
Why would you say that?
https://github.com/Alamofire/Alamofire/blob/master/Source/NetworkReachabilityManager.swift#L125

I just think the implementation of Alamofire's Reachability might be problematic on IPv4 only network

[cezheng]

@cnoon
Would you explain why Alamofire need to use sockaddr_in6 for iOS 9 or later, while apple's official sample of Reachability claims that 0.0.0.0 is treated as a special token?

Also, there is a similar issue in AFNetworking, since it has pretty much the same implementation for Reachability: AFNetworking/AFNetworking#3498 (comment)

You may refer to the discussion at the bottom

[cezheng]

@cnoon
Would you explain why Alamofire need to use sockaddr_in6 for iOS 9 or later, while apple's official sample of Reachability claims that 0.0.0.0 is treated as a special token?

Also, there is a similar issue in AFNetworking, since it has pretty much the same implementation for Reachability: AFNetworking/AFNetworking#3498 (comment)

You may refer to the discussion at the bottom

[dooofy]

I agree. Why should we adopt a potentially problematic implementation, while we already have a apple-verified implementation(which is exactly the same as Alamofire's old implementaation)? I'd rather trust apple's official sample.

[dooofy]

I agree. Why should we adopt a potentially problematic implementation, while we already have a apple-verified implementation(which is exactly the same as Alamofire's old implementaation)? I'd rather trust apple's official sample.

[cnoon]

Ah, I misunderstood your original post @cezheng. I didn't realize you were posting a code sample from the Reachability project.

[cnoon]

Ah, I misunderstood your original post @cezheng. I didn't realize you were posting a code sample from the Reachability project.

[cnoon]

Thanks for posting all the documentation info @cezheng. That sample code was actually updated by Apple right after this ticket was opened. We need to re-evaluate our implementation based on the new sample code and description provided by Apple. Seems like there are a few opportunities for us to improve our logic.

[cnoon]

Thanks for posting all the documentation info @cezheng. That sample code was actually updated by Apple right after this ticket was opened. We need to re-evaluate our implementation based on the new sample code and description provided by Apple. Seems like there are a few opportunities for us to improve our logic.

[cezheng]

Thanks, I got it.

And also I guess the original IPv6 support change was kind of like a miscomprehension of apple's guideline.

If your code handles IPv4 types, make sure the IPv6 equivalents are handled too.

doesn't necessarirly mean that we should handle IPv6 types only, which is the current status for iOS >= 9.

[cezheng]

Thanks, I got it.

And also I guess the original IPv6 support change was kind of like a miscomprehension of apple's guideline.

If your code handles IPv4 types, make sure the IPv6 equivalents are handled too.

doesn't necessarirly mean that we should handle IPv6 types only, which is the current status for iOS >= 9.

[dgatwood]

Yikes. Most devices are still on IPv4-only networks, so yes, it definitely needs to support both.

Sent from my iPhone

On May 22, 2016, at 11:44 PM, Ce Zheng notifications@github.com wrote:

Thanks, I got it.

And also I guess the original IPv6 support change was kind of like a miscomprehension of apple's guideline.

If your code handles IPv4 types, make sure the IPv6 equivalents are handled too.

doesn't necessarirly mean that we should handle IPv6 types only, which is the current status for iOS >= 9.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[dgatwood]

Yikes. Most devices are still on IPv4-only networks, so yes, it definitely needs to support both.

Sent from my iPhone

On May 22, 2016, at 11:44 PM, Ce Zheng notifications@github.com wrote:

Thanks, I got it.

And also I guess the original IPv6 support change was kind of like a miscomprehension of apple's guideline.

If your code handles IPv4 types, make sure the IPv6 equivalents are handled too.

doesn't necessarirly mean that we should handle IPv6 types only, which is the current status for iOS >= 9.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[cnoon]

I've just opened #1308 which should bring Alamofire inline with Apple's recommendations when it comes to Reachability. I'm going to close this issue out. Please direct all future comments to #1308. Thanks for everyone's help getting to the bottom of this. We really appreciate everyone helping out here!

Cheers. 🍻

[cnoon]

I've just opened #1308 which should bring Alamofire inline with Apple's recommendations when it comes to Reachability. I'm going to close this issue out. Please direct all future comments to #1308. Thanks for everyone's help getting to the bottom of this. We really appreciate everyone helping out here!

Cheers. 🍻

[robertofrontado]

@cnoon Hey man I've a question,

I know this issue is closed but, the current version of Alamofire (v3.4.1) supports IPv6-only networks? Because Apple is rejecting my application saying that the HTTPs requests are failing.

Any idea? I'm running out of time and don't know what else could be the problem :S

[robertofrontado]

@cnoon Hey man I've a question,

I know this issue is closed but, the current version of Alamofire (v3.4.1) supports IPv6-only networks? Because Apple is rejecting my application saying that the HTTPs requests are failing.

Any idea? I'm running out of time and don't know what else could be the problem :S

[cezheng]

Because Apple is rejecting my application saying that the HTTPs requests are failing.

This issue is only related to Reachability which is just an optional feature, and it does not seem to be related to the failing HTTPS requests. Did apple provide any more details?

[cezheng]

Because Apple is rejecting my application saying that the HTTPs requests are failing.

This issue is only related to Reachability which is just an optional feature, and it does not seem to be related to the failing HTTPS requests. Did apple provide any more details?

[robertofrontado]

This is what they told me

We discovered one or more bugs in your app when reviewed on iPad and iPhone running iOS 9.3.2 on Wi-Fi connected to an IPv6 network.

Specifically, your app returns an error message when we sign in using Facebook and or when attempting to register.

Any idea?

Edit: The error could be in the server?

[robertofrontado]

This is what they told me

We discovered one or more bugs in your app when reviewed on iPad and iPhone running iOS 9.3.2 on Wi-Fi connected to an IPv6 network.

Specifically, your app returns an error message when we sign in using Facebook and or when attempting to register.

Any idea?

Edit: The error could be in the server?

[cnoon]

My guess is that this has something to do with the Facebook calls. Alamofire 3.4.1 should be fully IPv6 compliant. We have multiple apps in the AppStore right now built with that exact version.

[cnoon]

My guess is that this has something to do with the Facebook calls. Alamofire 3.4.1 should be fully IPv6 compliant. We have multiple apps in the AppStore right now built with that exact version.

[robertofrontado]

Thanks man

[robertofrontado]

Thanks man

[ANSCoder]

Same thing happened again i also did changes in Alamofire NetworkReachabilityManager as per @cnoon for IPv6 network but today again Apple rejected my app with the same issue.

Your app still still crashes on iPad and iPhone running iOS 9.3.4 connected to an IPv6 network when we:

This occurred when your app was used:

• Offline
• On Wi-Fi

[ANSCoder]

Same thing happened again i also did changes in Alamofire NetworkReachabilityManager as per @cnoon for IPv6 network but today again Apple rejected my app with the same issue.

Your app still still crashes on iPad and iPhone running iOS 9.3.4 connected to an IPv6 network when we:

This occurred when your app was used:

• Offline
• On Wi-Fi

[nikita-leonov]

@cnoon we got application rejected by Apple for IPV6 reason. We are using 3.4.1 and we are iOS 9.0 app now. What would be you recommend set of actions?

[nikita-leonov]

@cnoon we got application rejected by Apple for IPV6 reason. We are using 3.4.1 and we are iOS 9.0 app now. What would be you recommend set of actions?

[nikita-leonov]

@cnoon it also worth to mention that previous version with 3.4.1 passed apple review, so likely they just do not this checks often. I assume this is how multiple apps passed into App Store.

[nikita-leonov]

@cnoon it also worth to mention that previous version with 3.4.1 passed apple review, so likely they just do not this checks often. I assume this is how multiple apps passed into App Store.

[nikita-leonov]

It seems that current approach works only because of mixed networks. IPV6 only network will not handle current Network Reachability approach. Apple explicitly mentioned this in their documentation regarding 0.0.0.0 calls. Check "Connect without Preflight" section — https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW25

[nikita-leonov]

It seems that current approach works only because of mixed networks. IPV6 only network will not handle current Network Reachability approach. Apple explicitly mentioned this in their documentation regarding 0.0.0.0 calls. Check "Connect without Preflight" section — https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW25

[cezheng]

it also worth to mention that previous version with 3.4.1 passed apple review, so likely they just do not this checks often. I assume this is how multiple apps passed into App Store.

@nikita-leonov If that's the case, you should check what changes you added in your rejected version. Current implementation is exactly the same as apple's updated version of Reachability Sample, where Apple explicitly stated

reachabilityForInternetConnection: This monitors the address 0.0.0.0, which reachability treats as a special token that causes it to actually monitor the general routing status of the device, both IPv4 and IPv6.

[cezheng]

it also worth to mention that previous version with 3.4.1 passed apple review, so likely they just do not this checks often. I assume this is how multiple apps passed into App Store.

@nikita-leonov If that's the case, you should check what changes you added in your rejected version. Current implementation is exactly the same as apple's updated version of Reachability Sample, where Apple explicitly stated

reachabilityForInternetConnection: This monitors the address 0.0.0.0, which reachability treats as a special token that causes it to actually monitor the general routing status of the device, both IPv4 and IPv6.

[cezheng]

"Connect without Preflight" section only says it is not recommended to rely on preflight. Alamofire's ReachabilityManager is just an optional feature. If you are not using it then it has no impact on Alamofire's other functionalities.

[cezheng]

"Connect without Preflight" section only says it is not recommended to rely on preflight. Alamofire's ReachabilityManager is just an optional feature. If you are not using it then it has no impact on Alamofire's other functionalities.

[kcharwood]

I reviewed this code with the Eskimo at WWDC and he said it was also good. He also explained that there are all kinds of nuances with connecting to IPV6 networks that could cause a failure.

He said testing the with fake IPV6 network on your mac is NOT a good test. You need to be on a true IPV6 network. I've seen a client where we got rejected for IPV6 and could not repro the problem, but on the WWDC true IPV6 network it was easily reproducible. We tracked it down to it being a problem with one of our API servers that didn't play nice with a direct IPV6 connection. It had nothing to do with our code.

[kcharwood]

I reviewed this code with the Eskimo at WWDC and he said it was also good. He also explained that there are all kinds of nuances with connecting to IPV6 networks that could cause a failure.

He said testing the with fake IPV6 network on your mac is NOT a good test. You need to be on a true IPV6 network. I've seen a client where we got rejected for IPV6 and could not repro the problem, but on the WWDC true IPV6 network it was easily reproducible. We tracked it down to it being a problem with one of our API servers that didn't play nice with a direct IPV6 connection. It had nothing to do with our code.

[ANSCoder]

@cnoon Thanks for the suggestion successfully approve my app 20 days before.

[ANSCoder]

@cnoon Thanks for the suggestion successfully approve my app 20 days before.

[nikita-leonov]

@kcharwood it was likely some network disturbance that confused apple. We got our application approved afterward with close to nothing changes in a networking code.

As for IPV6 support, I do agree that it is not only frontend problem, but also something that backend team should work on as well. We investigated our backend setup and found a couple of potential problems that need to be addressed to support IPV6 better.

[nikita-leonov]

@kcharwood it was likely some network disturbance that confused apple. We got our application approved afterward with close to nothing changes in a networking code.

As for IPV6 support, I do agree that it is not only frontend problem, but also something that backend team should work on as well. We investigated our backend setup and found a couple of potential problems that need to be addressed to support IPV6 better.

[Yacone]

@nikita-leonov Hi nikita, we are having exactly the same problem. What have you changed in your network code ?
Thank you in advance

[Yacone]

@nikita-leonov Hi nikita, we are having exactly the same problem. What have you changed in your network code ?
Thank you in advance

[nikita-leonov]

@YacineVC nothing facepalm it could be that it was some other interference on an Apple side while they were doing a test, as the result they decided that our app is not IPV6 complaint. As @kcharwood mentioned it seems that existing reachability code with 0.0.0.0 is ok from an Apple standpoint.

[nikita-leonov]

@YacineVC nothing facepalm it could be that it was some other interference on an Apple side while they were doing a test, as the result they decided that our app is not IPV6 complaint. As @kcharwood mentioned it seems that existing reachability code with 0.0.0.0 is ok from an Apple standpoint.

[Yacone]

@nikita-leonov Thank you for your reactivity ! We will see with our backend and Apple
Finger crossed

[Yacone]

@nikita-leonov Thank you for your reactivity ! We will see with our backend and Apple
Finger crossed

[niennonno]

I know this issue is marked closed but we faced the same issue when we are submitting an update to our app. We have Alamofire 3.4 running and iOS version is 8.0+ . our app got accepted once but now the update submission keeps getting rejected from Apple. Our servers can handle both IPv6 and IPv4 but unfortunately we don't have an IPv6 network to test out our app with.

Do I have to change something in my NetworkReachabilityManager.swift file, like AF_INET to AF_INET6 or something? Really desperate for the answer here.

[niennonno]

I know this issue is marked closed but we faced the same issue when we are submitting an update to our app. We have Alamofire 3.4 running and iOS version is 8.0+ . our app got accepted once but now the update submission keeps getting rejected from Apple. Our servers can handle both IPv6 and IPv4 but unfortunately we don't have an IPv6 network to test out our app with.

Do I have to change something in my NetworkReachabilityManager.swift file, like AF_INET to AF_INET6 or something? Really desperate for the answer here.

[Yacone]

@niennonno After our reject we asked a review to the App Review Submission Community.
It has been accepted afterwards.
As @nikita-leonov said, the problem may come from there testing infrastructure.

[Yacone]

@niennonno After our reject we asked a review to the App Review Submission Community.
It has been accepted afterwards.
As @nikita-leonov said, the problem may come from there testing infrastructure.

[NemOry]

I also got my app rejected yesterday due to "NOT SUPPORTING IPV6". I only use AlamoFire and AWS IOS SDK for communicating to APIs.

[NemOry]

I also got my app rejected yesterday due to "NOT SUPPORTING IPV6". I only use AlamoFire and AWS IOS SDK for communicating to APIs.

[AnthonyMDev]

As @cnoon has stated, this library has full IPV6 support. This is very likely not an issue with Alamofire and is rather due to IPV6 compatibility issues with your server, a third-party service you are using, or possibly, as @YacineVC suggested, an error in Apple's testing infrastructure.

[AnthonyMDev]

As @cnoon has stated, this library has full IPV6 support. This is very likely not an issue with Alamofire and is rather due to IPV6 compatibility issues with your server, a third-party service you are using, or possibly, as @YacineVC suggested, an error in Apple's testing infrastructure.

[hellmund]

@cnoon I can confirm from our recent Apple submission, that the reachability check fails in IPv6-only networks as @nikita-leonov described. In our case that was actually the reason for getting rejected by Apple, because we were relying on that functionality as preflight check. Once we removed the reachability check (that was the only change) and re-submitted, we passed review.

It's a bit tricky, as the failing cannot be reproduced in a mixed environment mit DNS64/NAT64 networks. But it will fail in the IPv6-only network which Apple is using (at least for spot tests) when submitting iOS apps for review.

I'd suggest to either remove the reachability check completely as implemented at the moment - and/or make it more clear to users of Alamofire that the reachability check must not be used for preflight check but only for diagnostic purposes on IPv4 or mixed networks AFTER identifying a connectivity issue, as suggested by Apple: https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW25
Otherwise there is a high chance that quite a few more developers are encountering this pitfall.

[hellmund]

@cnoon I can confirm from our recent Apple submission, that the reachability check fails in IPv6-only networks as @nikita-leonov described. In our case that was actually the reason for getting rejected by Apple, because we were relying on that functionality as preflight check. Once we removed the reachability check (that was the only change) and re-submitted, we passed review.

It's a bit tricky, as the failing cannot be reproduced in a mixed environment mit DNS64/NAT64 networks. But it will fail in the IPv6-only network which Apple is using (at least for spot tests) when submitting iOS apps for review.

I'd suggest to either remove the reachability check completely as implemented at the moment - and/or make it more clear to users of Alamofire that the reachability check must not be used for preflight check but only for diagnostic purposes on IPv4 or mixed networks AFTER identifying a connectivity issue, as suggested by Apple: https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW25
Otherwise there is a high chance that quite a few more developers are encountering this pitfall.

[adrimarti]

How can I remove the reachability check?
I am getting my app rejected by Apple cause of this issue.

[adrimarti]

How can I remove the reachability check?
I am getting my app rejected by Apple cause of this issue.

[niennonno]

@hellmund can you help as to how to remove this check?

[niennonno]

@hellmund can you help as to how to remove this check?

[kcharwood]

@hellmund Yes you should definitely not be using reachability has a pre-flight check.

It may be best to open up a dev forum discussion and get Quinn involved. I chatted with him about this at WWDC, and there is just a lot of confusion here.

[kcharwood]

@hellmund Yes you should definitely not be using reachability has a pre-flight check.

It may be best to open up a dev forum discussion and get Quinn involved. I chatted with him about this at WWDC, and there is just a lot of confusion here.

[hellmund]

@niennonno @adrimarti We simply ended up removing the call to NetworkReachabilityManager and its "isReachable" check from our app's loading sequence. Now we are only checking ourselves if the loading sequence exceeds a certain threshold number of seconds. If so, we display a dialog to the users, giving them the option to restart the loading process.

[hellmund]

@niennonno @adrimarti We simply ended up removing the call to NetworkReachabilityManager and its "isReachable" check from our app's loading sequence. Now we are only checking ourselves if the loading sequence exceeds a certain threshold number of seconds. If so, we display a dialog to the users, giving them the option to restart the loading process.

[jshier]

@hellmund You should also confirm that your backend is accessible through a pure IPv6 network, as we see that a lot, as many backends still require an IPv6to4 bridge for connectivity. Otherwise, recommended best practice is to allow requests to fail and then check reachability to determine your next steps.

[jshier]

@hellmund You should also confirm that your backend is accessible through a pure IPv6 network, as we see that a lot, as many backends still require an IPv6to4 bridge for connectivity. Otherwise, recommended best practice is to allow requests to fail and then check reachability to determine your next steps.

[niennonno]

@hellmund not able to find any call to the manager on my side. Can you please help out?

[niennonno]

@hellmund not able to find any call to the manager on my side. Can you please help out?

[hellmund]

@niennonno Then it's a different problem in your case, which I can't help much with I'm afraid. If you have a chance to set up a IPv6-only network for testing (not just DNS64/NAT64), that should help you to narrow down where the issue is with your app.

[hellmund]

@niennonno Then it's a different problem in your case, which I can't help much with I'm afraid. If you have a chance to set up a IPv6-only network for testing (not just DNS64/NAT64), that should help you to narrow down where the issue is with your app.