90

Our update has been rejected twice today for ipv6 network connectivity issues. Our networking code has not changed between the previous release and this current release.

The app only makes https network requests to api.metooapp.io, which is correctly configured for ipv6 [0] and runs behind route53 on AWS. There are no hard-coded IP addresses in the code.

I am unable to reproduce this issue, even after following the steps to create an ipv6 network at [1] which is the link that was provided in the rejection notice. It looks like I'm not the only one experiencing this issue, either [2].

Cœur
  • 37,241
  • 25
  • 195
  • 267
Sean Thielen
  • 1,396
  • 1
  • 11
  • 15
  • Are you using `AFNetworking` (if so, what version)? `Reachability`? ThirdParty Libraries? – Brandon Jun 05 '16 at 02:52
  • Alamofire 3.4.0 and [Reachability.swift](https://github.com/ashleymills/Reachability.swift), but the way I'm using Reachability is just for optional background tasks. My main issue is that I'm unable to reproduce this, even after following Apple's instructions. – Sean Thielen Jun 05 '16 at 03:02
  • Add your networking code too in the question – Piyush Patil Jun 05 '16 at 14:49
  • @error2007s The networking code is [Alamofire](https://github.com/Alamofire/Alamofire) – Sean Thielen Jun 05 '16 at 18:03
  • @SeanThielen I'm facing the same issue (I'm using Alamofire v3.4.1) have you solved this issue? The problem is in the server? – Roberto Frontado Jul 30 '16 at 11:26
  • @RobertoFrontado Yes, I can confirm that the problem was with my server having an AAAA record pointing to a server that was incorrectly configured for ipv6 traffic and did not have anything to do with Alamofire. Did you try checking your DNS settings at http://ready.chair6.net/ ? – Sean Thielen Jul 30 '16 at 21:03
  • @SeanThielen Okok, Yes check out this [link](https://drive.google.com/open?id=0ByceFcHrHDr9Nm9malRhVDVWc2c). Do you see anything wrong? – Roberto Frontado Jul 31 '16 at 08:35
  • yes I am using Reachability and I've got the same Rejection . Is that Because of that????? – JAck Aug 19 '16 at 13:34
  • I have got the same rejection issue but i have tested my app on local ipv6 network then it is working fine. Please suggest it. – Sankalap Yaduraj Singh Oct 07 '16 at 06:18
  • Same Here I tested that too. In my local ipv6 network. And it is working, but appstore rejects it – JAck Oct 18 '16 at 12:59
  • Faced the same issue but figured out my application crashed because i did not handle the rejection of permissions well, with the help of this http://stackoverflow.com/a/41462025/4944007 I figured it out – Ismail Iqbal Feb 28 '17 at 13:58
  • 1
    did you buy the latest Apple IPv6 dongle? – anders Apr 18 '17 at 13:48
  • check this answer . https://stackoverflow.com/a/38500762/4910767 – Badal Shah Jun 27 '17 at 03:55

13 Answers13

38

After quite a bit of stress, I can confirm that the issue was a problem with our backend not being correctly configured for IPv6. Apparently, AWS doesn't support IPv6, nor IPv6-only DNS through Route53. I ended up moving all the internet facing bits of the backend away from AWS for the time being.

I wanted to leave this up because I think there are probably going to be others who find themselves with similar problems as people start submitting updates past the IPv6-only restriction. The best tool I found for testing server/dns readiness has been: http://ready.chair6.net/

Sean Thielen
  • 1,396
  • 1
  • 11
  • 15
  • 2
    Can you tell me if the cause of the App Store rejection was your servers not supporting IPv6 traffic? I have 3 rejections in a row now from Apple but my code has not changed from previous versions. I am using Xamarin iOS and updated their Connectivity plugin to the latest version as well because they had issues with IPv6. I'm getting desperate! I can't replicate the crash on my iOS devices here (even on a NAT64 IPV6 network through my Mac Internet sharing). – Jon Jul 27 '16 at 22:04
  • this reject is caused in your server, your server not support ipv6. Mangist – Pablo Ruan Aug 30 '16 at 11:57
  • Hi @Sean Thielan, I have tested our server with http://ready.chair6.net/ and it fails for the IPV6 network connectivity, But the app was working fine with the same server which we have tested by creating NAT64 network (for IPV6 network) on our iPhone 5S device with 10.0.2 OS version, Can you guide for the below, Do we need to resubmit the app to app store or contact with the apple technical support. Or else do we need to configure our Server to support the IPV6 network? – Venkatesh Oct 06 '16 at 08:31
  • Hi @Venkatesh did you find a solution for this issue because I am stuck with Apple rejection to in the same case ? – Mohamed Fadl Allah Oct 17 '16 at 09:35
  • hello Sean. I tested my APIs. It fails these three tests .. DNS (IPv6 NS) DNS (MX Record) DNS (Glue).. Result for those three are WARN. is that issue that apple is rejecting my app.?? It's is necessory to pass domain all the tests.. on http://ready.chair6.net/????? – JAck Oct 18 '16 at 13:02
  • Guys, I am on same page. Mine is rejected for three times with same reason. As i checked in NAT64 network and its working fine. If any one get approve then please let us know. Thanks, – Nirmalsinh Rathod Nov 18 '16 at 11:35
  • It seems like later in 2016 Route 53 rolled out support for IPV6: https://aws.amazon.com/about-aws/whats-new/2016/10/amazon-route-53-now-supports-dns-queries-over-ipv6-networks/ – pietrorea Oct 16 '17 at 13:55
11

Please note that Supporting IPv6-only Networks and IPv6 and App Review link can be very helpful in determining what's the problem with apple rejections. In this specific case the articles clearly state that you can setup the DNS64/NAT64 test network but that "This test network is not exactly the same as the network used by App Review", that's why everything can work in the test environment and still have the app rejected.

Moreover:

The App Review network, like the networks deployed by service providers, does support IPv6-to-IPv6 connectivity. Thus, if your server supports IPv6, your app will talk to it directly, without going through the NAT64 translator. This is, in general, a good thing, but it can trip you up if your server claims to support IPv6 but that IPv6 support is broken. For example, if: the DNS name is incorrect the DNS is correct but the server is not listening on IPv6 the server is listening on IPv6 but fails when a request comes in over IPv6

So if your backend server has support for IPv6 the apple test network will use it, and it is what has been wrong in this case.

I add this as a reference and starting point for other users that experience the same problem

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
lucianoenrico
  • 1,486
  • 1
  • 13
  • 21
10

We ran into this same problem, and it turned out while we had setup an AAAA record for IPv6, since we didn't actually have IPv6 support (we're also using Route53), it borked everything. Removing the AAAA record fixed the issue.

I've filed a radar about the discrepancy between the documentation for testing and the setup App Review is using - we were only able to diagnose it because our CTO was at WWDC and was able to connect to their network, which is not exactly a situation we can reproduce regularly.

DesignatedNerd
  • 2,514
  • 1
  • 23
  • 46
  • Interesting. I had Route53 configured the same way, with the AAAA record aliased to an ELB. Maybe in the next minor version I'll try it back on AWS, but without the AAAA record. The results section of your radar accurately mirrors my own experiences. At one point I factory reset a router, a macbook, and an iPhone in order to completely make sure it wasn't some absurd caching problem. I would continue to investigate but I'm just happy the update went through and I hope to never think about it again. – Sean Thielen Jun 15 '16 at 05:31
  • Did you get any response from Apple to your radar? – Kaiserludi Oct 05 '16 at 17:44
  • 1
    @Kaiserludi not officially, though I have seen that within the dev forums if you look for some posts from Quinn The Eskimo, he's been updating them with a lot more information to help you debug. This one seems particularly helpful: https://forums.developer.apple.com/message/147579#147579 – DesignatedNerd Oct 06 '16 at 18:15
  • Thanks a lot. That link is indeed very informative. – Kaiserludi Oct 06 '16 at 18:42
6

We ran into similar situation. Our app was rejected due to connectivity problems in IPv6 networks. Also our servers are using AWS.

I've performed Test for IPv6 DNS64/NAT64 without any issue on my side, and we decide to submit an appeal to this rejection.

We explained that the test on our side was finished with success and that we are using AWS infrastructure.

After two more days the app was again reviewed and accepted

MP23
  • 1,763
  • 20
  • 25
5

we met the same problem。 Our App has been rejected serval times for ipv6 reason . But We have been test in the ipv6 network which configed as APPLE's Offical Document: https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW1

Ern Zhang
  • 51
  • 1
  • 6
    Have you found a solution to this? I cannot get my app review accepted by Apple and I'm out of ideas – Jon Jul 27 '16 at 22:05
5

Our app is rejected the first time, we setup the local test environment based on apple document and find our curl lib is too old without enable ipv6 by default. So we build latest curl lib and it works. But it's rejected again because same reason. I check a lot information, find someone had same experience, just complaint to Apple reviewer to say your app works well in test environment and ask them to provide an engineer to help if they insist there is some error. Apple review team approved our app in the weekend when they saw our complaints.

As I know there are 2 issues you need check. Do you hard code ip address in your app? Do you setup your AAAA record for your server domain to show it supports ipv6, but your server doesn't listen to ipv6. If yes, just remove that AAAA record in your domain settings from your domain provider site.

ramon.liu
  • 186
  • 3
  • 5
3

Reachability library must support IPv6 network settings. So use this Reachability class.

https://developer.apple.com/library/content/samplecode/Reachability/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007324

SerkanHocam
  • 536
  • 6
  • 18
2

This is 2nd time i have encountered this issue after 6 month. Previously it was in Objective-C project using AFNetworking and i used this solution and it worked on one go. Now same happened with Alamofire. Guys this solution is worked for me 2 times and i found this question is coming first in google so i am posting the answer.

Search in the workspace for AF_INET and change it to AF_INET6 anywhere you found. I think it must be inside the AFNetworking library or Alamofire library if you are using it. Its in the NetworkReachabilityManager class.

I found this answer from the below source.

https://stackoverflow.com/a/38196337/4030971

EDIT: - 24th June -

This helped me so many times but there is a strange solution to this problem also. In our recent project we have applied this solution but still apple rejected the application. Then we made a video which was showing that the app is running fine with connected to a NAT64 network created on a Mac from wifi sharing option. We appealed for review with the video and they approved the application. So if you are done with all your options, try this one too.

Mahesh Agrawal
  • 3,348
  • 20
  • 34
2

You can check your API in below website, is your API iPV6 configure or not!

http://ipv6-test.com/validate.php

Anand Nanavaty
  • 554
  • 4
  • 13
1

I've performed Test for IPv6 DNS64/NAT64 without any issue as prescribed by Apple documentation

however, we are unable to reproduce the issue (Crash). We successful install app in our devices without crashes.

  • We took a video of this total testing process (which includes showing connectivity, downloading from testflight, NAT64 network connection , app operations)
  • and appeal for rejection with the video file

Finally, app store APPROVED my app

Phani Sai
  • 1,215
  • 19
  • 33
0

I ran into the same app rejection when using the Facebook SDK. If you are using the Facebook SDK for login, it is incredibly important to logout the user when ending a session. Otherwise you will face similar app rejections in the future. I have included the code below to help those who may be experiencing similar issues.

let loginManager = FBSDKLoginManager()
loginManager.logOut()
Adam Cooper
  • 867
  • 1
  • 6
  • 23
0

I solved the problem by sending them a video, showing that my app works on ipv6.

  1. Setup ipv6 with your macOS
  2. Video tape that you are connected to the shared ipv6 network and prove that your app works on that environment.
Steve Ham
  • 3,067
  • 1
  • 29
  • 36
  • I tried the video route. It showed them me setting up my Mac as an IPV6 wifi, connecting my phone to it and running my app without problem. I've just got another rejection from them, saying "Thank you for your reply. During our review, we found that your app still launches to a white screen, even while being tested on multiple devices". Then follows advice on how to test with IPV6 networks; these are the same steps that I'd showed them me going through in my video. Overall, the response looked like it might be automated. How to deal with a real person from Apple Review Team? – ChillyPenguin Feb 13 '18 at 23:51
  • Perhaps devprograms@apple.com. – Steve Ham Feb 15 '18 at 03:45
0

my app is rejected two times on app store. They give a error to twitter login on iphone having os 11.4. The main issue we have because of callback url of twitter, which is not set on developer account of twitter. when i set callback url on developer account of twitter. It solves my issue. When we dont set callback url on developer accountof twitter that time twitter login is successfull when device having twitter app. but in case of absence of twitter app on device gives forbidden error 403.

So Setting callback url overcomes my problem and app is accepted.

Thank you

Protocol
  • 1,696
  • 13
  • 30