Reviewer cannot connect to server that app's using

App & System Services General
Torita OP
Created Mar ’23
Replies 3
Boosts 0
Views 1.4k
Participants 4

Hello, Recently, I try to submit a new update version of my app and it keeps being rejected by Apple's reviewer.

The reviewers got error message of Error: cannot connect to server. We hold a server for data and my app connects to the server to get required data. My testers didn't run into errors when testing our app with Testflight.

I doubt there is network issue from Apple reviewers to my server but I can't how to resolve it. I have a test RESTful API but Apple reviewers refused to do a connection test that is out of app. https://kato332.ddns.net/public/Auth/debug

I also sent an appeal but still being said rejection was valid.

I've been rejected over 10 times. However, I passed a review of a version just before this one two days before. I didn't modify any codes about connections. It's weird. I wonder if anyone has same experience and the way to resolve it. Thank you.

Answered by DTS Engineer in 748339022

This is a weird one. When I’m on my home network I’m able to resolve your host name:

% host kato332.ddns.net
kato332.ddns.net has address 35.197.102.232
kato332.ddns.net has IPv6 address 2600:1900:4040:120f::

However, on Apple’s internal network I’m not:

% host kato332.ddns.net
kato332.ddns.net has address 17.168.114.134
Host kato332.ddns.net not found: 2(SERVFAIL)

I suspect that this is because you’re using dynamic DNS.

Now, you could try arguing this out with App Review but my advice is that you switch to a more traditional DNS name. The thing about mysterious networking problems that only show up in App Review is that… well… they don’t only show up in App Review. As far as corporate networks are concerned, App Review’s network is very open. Any widely deployed app will find itself running on networks that are much weirder. The best way to avoid problems like this is to use a vanilla network setup, which means:

  • HTTPS

  • Over port 443

  • To a fixed DNS name

  • With a server whose TLS certificate is system-trusted

That setup should work in App Review but, more critically, it’ll also work in a wide variety of other wacky corporate networks.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Replies  3
Boosts  0
Views  1.4k
Participants  4
enodev OP
Mar ’23 
 € curl -vvv  https://kato332.ddns.net/public/Auth/debug
*   Trying 35.197.102.232:443...
* Connected to kato332.ddns.net (35.197.102.232) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* [CONN-0-0][CF-SSL] (304) (OUT), TLS handshake, Client hello (1):
* [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, Server hello (2):
* [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, Unknown (8):
* [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, Certificate (11):
* [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, CERT verify (15):
* [CONN-0-0][CF-SSL] (304) (IN), TLS handshake, Finished (20):
* [CONN-0-0][CF-SSL] (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=kato332.ddns.net
*  start date: Jan 31 04:52:33 2023 GMT
*  expire date: May  1 04:52:32 2023 GMT
*  subjectAltName: host "kato332.ddns.net" matched cert's "kato332.ddns.net"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
> GET /public/Auth/debug HTTP/1.1
> Host: kato332.ddns.net
> User-Agent: curl/7.87.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 17 Mar 2023 18:14:55 GMT
< Server: Apache/2.4.41 (Ubuntu)
< Cache-control: no-store, max-age=0, no-cache
< Debugbar-Time: 1679076895
< Debugbar-Link: https://kato332.ddns.net/index.php/?debugbar_time=1679076895
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: Origin, Content-Type, Accept, Authorization, X-Request-With
< Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS
< Access-Control-Allow-Credentials: true
< Content-Length: 15
< Content-Type: application/json; charset=UTF-8
< 
* Connection #0 to host kato332.ddns.net left intact
{"status":"OK"}%
0
matheymatei OP
Mar ’23

Maybe you are facing the same issue as these guys:

https://developer.apple.com/forums/thread/725134

P.S Your Debug API returns "Status OK" for me.

Hope you resolve your issue. Let us know how it went,

Thanks!

0
DTS Engineer OP
Apple
Mar ’23
Accepted Answer

This is a weird one. When I’m on my home network I’m able to resolve your host name:

% host kato332.ddns.net
kato332.ddns.net has address 35.197.102.232
kato332.ddns.net has IPv6 address 2600:1900:4040:120f::

However, on Apple’s internal network I’m not:

% host kato332.ddns.net
kato332.ddns.net has address 17.168.114.134
Host kato332.ddns.net not found: 2(SERVFAIL)

I suspect that this is because you’re using dynamic DNS.

Now, you could try arguing this out with App Review but my advice is that you switch to a more traditional DNS name. The thing about mysterious networking problems that only show up in App Review is that… well… they don’t only show up in App Review. As far as corporate networks are concerned, App Review’s network is very open. Any widely deployed app will find itself running on networks that are much weirder. The best way to avoid problems like this is to use a vanilla network setup, which means:

  • HTTPS

  • Over port 443

  • To a fixed DNS name

  • With a server whose TLS certificate is system-trusted

That setup should work in App Review but, more critically, it’ll also work in a wide variety of other wacky corporate networks.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0
Reviewer cannot connect to server that app's using
First post date Last post date
 
 
Q