App works on IPv6-only networks

Apple requires all iOS apps to work on IPv6-only networks and tests this during review using an IPv6 NAT64 hotspot. Hardcoded IPv4 addresses (e.g., 192.168.1.100 that leaked from a development config) break immediately on IPv6-only networks because those addresses cannot be reached. This is a direct rejection cause for iOS submissions. ISO 25010:2011 operational-readiness requires software to function in the range of environments it claims to support — IPv6-only networks are widespread in cellular carrier environments and Apple's own review lab.

Replace every hardcoded IPv4 address in production configuration with a hostname.

// src/config/api.ts
// Wrong — fails on IPv6-only networks:
export const API_URL = 'http://192.168.1.100:3000';

// Correct — DNS resolves to IPv4 or IPv6 as needed:
export const API_URL = process.env.EXPO_PUBLIC_API_URL ?? 'https://api.yourdomain.com';

To test IPv6 compatibility on macOS: go to System Settings > Sharing > Internet Sharing, share your Ethernet connection over Wi-Fi, enable "Enable IPv6" in the Wi-Fi options. Connect your test device to this hotspot and run the app. Any hardcoded IPv4 URL will fail immediately.

• ID: ipv6-compatible

• Severity: medium

• What to look for: Count all relevant instances and enumerate each. Search for hardcoded IPv4 addresses in source files: patterns like \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} in API base URLs, server configuration, or network code. Look for getaddrinfo calls with AF_INET only (IPv4), socket creation with AF_INET that excludes AF_INET6, or any hardcoded IP literals in network configuration. In React Native, check app.json, .env files (for local development IPs that may have leaked into production config), and any fetch() base URLs. Also look for third-party libraries with known IPv6 issues — check the library's issues tracker if you find unusual networking code.

• Pass criteria: No hardcoded IPv4 addresses in production API URLs. At least 1 implementation must be verified. All network connections use hostnames (which DNS resolves to IPv4 or IPv6 as appropriate). App does not explicitly force IPv4 socket connections.

• Fail criteria: Hardcoded IPv4 addresses (e.g., 192.168.1.100, 10.0.0.1) in production API configuration; socket code that explicitly uses AF_INET to the exclusion of IPv6.

• Skip (N/A) when: App is Android-only (Google Play does not require IPv6 compatibility, though it is still good practice).

• Detail on fail: "API base URL in src/config/api.ts contains hardcoded IPv4: 'http://192.168.1.5:3000'" or "Native iOS socket code uses AF_INET exclusively, failing on IPv6-only networks"

• Remediation: Apple requires all iOS apps to work on IPv6-only networks. Apple tests this during review using an IPv6-only Wi-Fi hotspot.

  1. Replace all hardcoded IP addresses in production config with hostnames:
     • Wrong: API_URL = 'http://192.168.1.100:3000'
     • Correct: API_URL = 'https://api.yourdomain.com'
  2. Use Apple's IPv6 testing setup: create an IPv6 NAT64 hotspot via macOS Internet Sharing to test
  3. Ensure all socket code uses getaddrinfo() for hostname resolution (not hard-coded AF_INET)
  4. Third-party SDKs that use raw sockets may have IPv6 issues — check their release notes

  Review the configuration in src/ or app/ directory for implementation patterns.