localhost and development URLs left in a submitted build
localhost, private LAN addresses, development tunnels and non-production hostnames do not resolve on a reviewer’s device. An app pointed at one does not fail gracefully, it fails completely, and that is what the reviewer sees.
Why it matters
This is a blocker because there is no version of it that works. The reviewer opens the app, a request goes to an address that exists only on your network, and the app shows an error or an empty state.
It usually arrives through a configuration path rather than a hardcoded URL: a base URL chosen by a build flag, with the flag not set the way you expect in Release. That is why it survives testing, since the build you tested was the one with the flag right.
Tunnel hostnames are the modern version of the same thing, and they are worse because they resolve publicly but point at a machine that has since been switched off.
How to fix it
- Find the base URL the Release configuration actually uses, by reading the value that resolves for Release rather than the default in code.
- Point it at production, and make the production value the default rather than the exception.
- Remove any App Transport Security exception that existed to allow the development host, which is a separate check that tends to fail alongside this one.
- Install the archived build on a device that is not on your network and open it.
The guidelines behind it
Read from Apple’s App Review Guidelines as last updated October 16, 2026.
Worth knowing
Matches inside test targets are excluded.
What ReviewAhead checks
Development endpoints. Localhost, LAN and tunnel URLs do not resolve on a reviewer’s device.
- localhost and loopback addresses.
- Private LAN ranges.
- Known development tunnel hostnames.
- Non-production hostnames such as staging and dev subdomains.
Apple’s own documentation for this requirement: developer.apple.com. Where this page and Apple disagree, Apple is right and this page is a bug.