New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AlamoFire full IPv6 support #1228

Closed
racer1988 opened this Issue May 6, 2016 · 47 comments

Comments

Projects
None yet
@racer1988

racer1988 commented May 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cnoon

cnoon May 8, 2016

Member

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.

Member

cnoon commented May 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cnoon
Member

cnoon commented May 8, 2016

@dgatwood

This comment has been minimized.

Show comment
Hide comment
@dgatwood

dgatwood May 9, 2016

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 commented May 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@racer1988

racer1988 May 9, 2016

@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 commented May 9, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@cnoon

cnoon May 9, 2016

Member

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

Member

cnoon commented May 9, 2016

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

@racer1988

This comment has been minimized.

Show comment
Hide comment
@racer1988

racer1988 May 9, 2016

AND LOL! 😫

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

racer1988 commented May 9, 2016

AND LOL! 😫

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

@AnthonyMDev

This comment has been minimized.

Show comment
Hide comment
@AnthonyMDev

AnthonyMDev May 10, 2016

Contributor

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

Contributor

AnthonyMDev commented May 10, 2016

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

@cnoon

This comment has been minimized.

Show comment
Hide comment
@cnoon

cnoon May 10, 2016

Member

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.

Member

cnoon commented May 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cezheng

cezheng May 14, 2016

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 commented May 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cnoon

cnoon May 22, 2016

Member

Pretty sure you posted on the wrong project @cezheng.

Member

cnoon commented May 22, 2016

Pretty sure you posted on the wrong project @cezheng.

@cezheng

This comment has been minimized.

Show comment
Hide comment
@cezheng

cezheng May 22, 2016

@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 commented May 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@cezheng

cezheng May 22, 2016

@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 commented May 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@dooofy

dooofy May 22, 2016

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 commented May 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cnoon

cnoon May 22, 2016

Member

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

Member

cnoon commented May 22, 2016

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

@cnoon

This comment has been minimized.

Show comment
Hide comment
@cnoon

cnoon May 22, 2016

Member

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.

Member

cnoon commented May 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cezheng

cezheng May 23, 2016

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 commented May 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dgatwood

dgatwood May 23, 2016

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 commented May 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cnoon

cnoon Jun 13, 2016

Member

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. 🍻

Member

cnoon commented Jun 13, 2016

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 cnoon closed this Jun 13, 2016

@cnoon cnoon removed the help wanted label Jun 13, 2016

@robertofrontado

This comment has been minimized.

Show comment
Hide comment
@robertofrontado

robertofrontado Jul 29, 2016

@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 commented Jul 29, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@cezheng

cezheng Jul 30, 2016

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 commented Jul 30, 2016

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 comment has been minimized.

Show comment
Hide comment
@robertofrontado

robertofrontado Jul 30, 2016

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 commented Jul 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cnoon

cnoon Jul 31, 2016

Member

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.

Member

cnoon commented Jul 31, 2016

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

This comment has been minimized.

Show comment
Hide comment
@robertofrontado

robertofrontado commented Aug 1, 2016

Thanks man

@ANSCoder

This comment has been minimized.

Show comment
Hide comment
@ANSCoder

ANSCoder Aug 14, 2016

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 commented Aug 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@nikita-leonov

nikita-leonov Aug 26, 2016

@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 commented Aug 26, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@nikita-leonov

nikita-leonov Aug 26, 2016

@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 commented Aug 26, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@nikita-leonov

nikita-leonov Aug 26, 2016

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 commented Aug 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cezheng

cezheng Aug 26, 2016

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 commented Aug 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@cezheng

cezheng Aug 26, 2016

"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 commented Aug 26, 2016

"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

This comment has been minimized.

Show comment
Hide comment
@kcharwood

kcharwood Aug 26, 2016

Contributor

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.

Contributor

kcharwood commented Aug 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ANSCoder

ANSCoder Aug 31, 2016

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

ANSCoder commented Aug 31, 2016

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

@nikita-leonov

This comment has been minimized.

Show comment
Hide comment
@nikita-leonov

nikita-leonov Aug 31, 2016

@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 commented Aug 31, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Yacone

Yacone Sep 15, 2016

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

Yacone commented Sep 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@nikita-leonov

nikita-leonov Sep 15, 2016

@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 commented Sep 15, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Yacone

Yacone Sep 15, 2016

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

Yacone commented Sep 15, 2016

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

@niennonno

This comment has been minimized.

Show comment
Hide comment
@niennonno

niennonno Sep 30, 2016

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 commented Sep 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Yacone

Yacone Sep 30, 2016

@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 commented Sep 30, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@NemOry

NemOry Sep 30, 2016

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 commented Sep 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@AnthonyMDev

AnthonyMDev Sep 30, 2016

Contributor

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.

Contributor

AnthonyMDev commented Sep 30, 2016

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

This comment has been minimized.

Show comment
Hide comment
@hellmund

hellmund Oct 9, 2016

@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 commented Oct 9, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@adrimarti

adrimarti Oct 11, 2016

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

adrimarti commented Oct 11, 2016

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

@niennonno

This comment has been minimized.

Show comment
Hide comment
@niennonno

niennonno Oct 12, 2016

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

niennonno commented Oct 12, 2016

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

@kcharwood

This comment has been minimized.

Show comment
Hide comment
@kcharwood

kcharwood Oct 12, 2016

Contributor

@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.

Contributor

kcharwood commented Oct 12, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@hellmund

hellmund Oct 12, 2016

@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 commented Oct 12, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@jshier

jshier Oct 12, 2016

Contributor

@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.

Contributor

jshier commented Oct 12, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@niennonno

niennonno Oct 13, 2016

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

niennonno commented Oct 13, 2016

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

@hellmund

This comment has been minimized.

Show comment
Hide comment
@hellmund

hellmund Oct 13, 2016

@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 commented Oct 13, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment