Hello,
Feedback Assistant report: FB24876147.
I develop a Unity-based iOS app. Some customers in mainland China report losing Internet access after an app update, while most installations continue working.
We have received similar reports since at least iOS 16, across several years and multiple app releases. Earlier iOS versions are uncertain, and we cannot confirm that all historical occurrences share the same cause. Updates without networking-code changes can be followed by failures. A later update sometimes restores connectivity, but not consistently.
Customer-reported recovery attempts:
- The app's wireless-data permissions appear enabled in Settings.
- Switching the app's network permission to another setting and back did not help users who reported trying it.
- Reset Network Settings also did not help users who reported trying it.
- Some users reported that deleting and reinstalling the app restored connectivity.
- At least one user reported that deletion and reinstallation did not help.
These are customer reports, not controlled tests on our development devices. We would prefer a recovery that preserves local save data.
Captured evidence from one affected installation:
- App version 1.89, build 1; Unity 2022.3.62f3.
- Device identifier: iPhone18,1; iOS 26.2.1.
- App in foreground.
- Capture time: 2026-09-07 13:04:31–13:04:32 UTC.
- An unfiltered Network.framework default-path monitor reported: status=unsatisfied reason=wifiDenied interface=Wi-Fi
UnityWebRequest and a newly created native ephemeral NSURLSession both failed against our public HTTPS origin and Apple's independent test endpoint: https://www.apple.com/library/test/success.html
The native requests failed after approximately 1 ms and 3 ms, with NSURLErrorDomain -1009, underlying kCFErrorDomainCFNetwork -1009, and no HTTP response.
The native session allowed cellular, expensive and constrained network access, used normal TLS verification, and had waitsForConnectivity=false. It bypassed Unity's reachability precheck.
CTCellularData changed from unknown to notRestricted. We understand this does not establish successful cellular connectivity or Wi-Fi permission.
Important limitations:
- The native probes ran inside the same Unity-built process, not a separate standalone native app.
- The captured measurements demonstrate a Wi-Fi failure. Cellular failures and enabled Settings permissions are customer reports, not independently verified by these measurements.
- We cannot reliably reproduce the affected state on our development devices and do not have a focused Xcode project that reproduces it.
- An affected-device sysdiagnose is not yet available.
Unity Customer QA reviewed this evidence, assessed it as an iOS network-policy issue rather than a Unity bug, and referred us to Apple. We are seeking Apple's investigation, not presenting that assessment as a confirmed root cause.
The Code-Level Support form directed us to these forums because we cannot currently provide a focused reproducer.
Questions:
- Which affected-device diagnostics or logging profiles would help identify why the effective network policy reports wifiDenied?
- How should we investigate an installation-specific issue when a new minimal app may not reproduce that installation state?
- Is there a supported, data-preserving recovery or application-side mitigation when permission changes and network resets do not help, and reinstallation is not consistently effective?
We have diagnostic screenshots and relevant probe source available. Any customer system logs would be collected with consent and shared privately with Apple, not posted publicly.
Thank you.
