# Guideline 2.5.5 - Software Requirements: App Fails on IPv6-Only Networks

**Guideline:** 2.5.5 · **Store:** Apple App Store · **Severity:** medium · **Fix difficulty:** medium · **Typical turnaround:** 2-8 hours

Canonical URL: https://appstorereject.com/rejections/apple/2/guideline-255-software-requirements-app-fails-on-ipv6-only-networks

## Description

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.

## Common variations

- App fails to load content on IPv6-only network
- App does not support IPv6 networking
- App uses hardcoded IPv4 addresses
- Networking features do not function on IPv6-only networks
- App fails to connect to server during review on IPv6 network

## Example rejection email

```
Guideline 2.5.5 - Performance - Software Requirements

Your app does not support IPv6 networking. Specifically, the app fails to load content when tested on an IPv6-only network.

All apps must support IPv6 networking as IPv6 is increasingly being deployed worldwide.

Next Steps:
Please ensure your app supports IPv6 networking. Use high-level networking APIs such as NSURLSession and CFNetwork, which natively handle IPv6 connectivity. Avoid hard-coding IP addresses and using low-level networking APIs that are IPv4-specific.

For more information, see Supporting IPv6 DNS64/NAT64 Networks.
```

## Resolution steps

## Quick Assessment
- **Risk level:** Medium
- **Resolution path:** Fix & Resubmit
- **Typical turnaround:** 2-8 hours

## The Fix

1. **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.

2. **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.

3. **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()`.

4. **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.

5. **Test WebSocket connections** -- WebSocket libraries are a common failure point. Ensure your WebSocket library resolves hostnames correctly and doesn't assume IPv4.

6. **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
- Never hardcode IP addresses -- always use hostnames
- Use high-level Apple networking APIs (URLSession, Network.framework)
- Set up IPv6 testing as part of your QA process
- Test on an IPv6-only network before every submission

## Appeal guidance

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 examples

**Before:** 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
**After:** 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
**Why it works:** Hostnames work with NAT64 translation; hardcoded IPv4 addresses do not. The fix is almost always replacing IPs with hostnames and using high-level APIs.

## Common questions

**Can you appeal a 2.5.5 rejection?**

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.

**How long does this typically take to fix?**

Typical turnaround is 2-8 hours (difficulty: medium). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-255-software-requirements-app-fails-on-ipv6-only-networks*