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/
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.
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
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.
I've performed Test for IPv6DNS64/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)
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.
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.
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()
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.
