Thanks, Quinn. Network Extension would supply local transport only; it would not itself provide a location-simulation API. The proposed design is: Embed an NEPacketTunnelProvider in the iPhone app, controlled through NETunnelProviderManager with in-app Connect/Disconnect buttons and the standard iOS VPN-configuration consent prompt. Install only a host route to a fixed virtual IPv4 peer, excluding the default Internet route. The provider reads IPv4 TCP/UDP packets from packetFlow, swaps the source/destination addresses between two fixed virtual endpoints, and writes them back to packetFlow. This is local packet reflection, with no remote VPN server, external socket, DNS/proxy configuration, or packet logging. The containing app would use that local path to connect to developer services on the same iPhone, authenticate using an existing locally stored developer-pairing record, and send location-simulation commands through those developer services. The intent is to change the simulated system location consumed by other apps, not just a pin inside our own app or IP-based geolocation. The extension does not read or create pairing records, enable Developer Mode, or authorize access to those services. Those setup requirements are separate, and we have not established a supported setup-free onboarding path. The embedded extension is currently an unsigned prototype; signing and on-device behavior have not been validated. Our goal is one iPhone app without a separate VPN app or computer during normal use. Is this local packet-reflection design a supported use of NEPacketTunnelProvider on iOS? Could an App Store-distributed consumer app use it together with developer pairing and system-location simulation, or is that combination restricted to development/testing? If this is outside the supported/App Store use case, is there a supported public API/entitlement or another Apple team we should ask? We understand that forum guidance is not formal App Review approval.