Guideline 2.5.5
Guideline 2.5.5 - Software Requirements: App Fails on IPv6-Only Networks
Our Take
Apple is rejecting your app because it does not support IPv6-only networks. Since June 2016, Apple has required all apps to work on IPv6-only networks with DNS64/NAT64, which is the network configuration Apple uses during app review. If your app hard-codes IPv4 addresses, uses low-level IPv4-specific socket APIs, or connects to servers that don't support IPv6, it will fail during review. This rejection is particularly common for: (1) apps that hardcode IPv4 addresses (like 192.168.1.1 or 104.20.30.40) instead of using hostnames, (2) apps using low-level networking libraries that don't handle IPv6 (common in C/C++ libraries and game engines), (3) apps connecting to servers behind load balancers that don't support IPv6, and (4) apps using older SDKs that haven't been updated for IPv6 compatibility. The critical insight is that Apple's review network is IPv6-only with NAT64 translation. Your server doesn't need to support IPv6 directly -- the NAT64 gateway translates between IPv6 and IPv4. The problem is almost always on the client side, not the server side.
Resolution Guide
Set up an IPv6-only test network
On your Mac, go to System Settings > Sharing > Internet Sharing. Enable 'Create NAT64 Network.' Connect your test iPhone to this WiFi network. This replicates Apple's review environment.
Replace hardcoded IP addresses
Search your entire codebase (including third-party libraries) for IP address patterns: \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}. Replace them with hostnames.
Use high-level networking APIs
Replace any low-level socket code with URLSession, CFNetwork, or Network.framework. These handle IPv6 automatically. If you must use BSD sockets, use getaddrinfo() instead of inet_pton() or gethostbyname().
Check third-party SDKs
Older versions of networking libraries, game engines, and WebSocket libraries may not support IPv6. Update them or replace with IPv6-compatible alternatives.
Test WebSocket connections
WebSocket libraries are a common failure point. Ensure your WebSocket library resolves hostnames correctly and doesn't assume IPv4.
Verify on the NAT64 test network
Test every network request in your app on the NAT64 network you set up in step 1. Every request must succeed.
Prevention
Example Rejection Email
Consider Appealing
If you believe your app supports IPv6 and the failure was due to a temporary server issue, explain in the Resolution Center and request re-review. Include evidence that you've tested on an IPv6-only network.
Before & After
App connects to API using hardcoded IP: let url = URL(string: "http://104.20.30.40/api/v1/data")! and uses a C WebSocket library that calls inet_addr() directly
App connects using hostname: let url = URL(string: "https://api.myapp.com/api/v1/data")! and WebSocket library updated to v3.0 which uses getaddrinfo() for DNS resolution
What changed: Hostnames work with NAT64 translation; hardcoded IPv4 addresses do not. The fix is almost always replacing IPs with hostnames and using high-level APIs.
Community Solutions · 0
Sign in to share your solution.
More Guideline 2 (Performance) rejections
- Guideline 2.1 - App Completeness: App Crashes During Review
- Guideline 2.1 - App Completeness: App Requires External Hardware Not Provided for Review
- Guideline 2.1 - App Completeness: Crashes on Launch
- Guideline 2.1 - App Completeness: Demo Account Not Working
- Guideline 2.1 - App Completeness: IAP Products Not Found in Binary
- Guideline 2.1 - App Completeness: Missing App Icon