We are developing an IoT companion app that connects to the IoT device's Wi-Fi network and communicates with it through local network APIs.
To support this functionality, we have:
Added the necessary keys in the Info.plist.
NSLocalNetworkUsageDescription ,
NSBonjourServices
Used a Bonjour service at app launch to trigger the local network permission prompt.
Problem on iOS 18.x (including 18.6 beta)
Even when the user explicitly denies the local network permission, our API communication still works.
This is unexpected behavior, as we assume denying permission should restrict access to local network communication.
We tested this with the latest iOS 18.6 beta (as per Thread 789461021), but the issue still persists. This behavior raises concerns about inconsistent permission enforcement in iOS 18.x.
Problem on iOS 17.x
In iOS 17.x, if the user accidentally denies the local network permission and later enables it manually via Settings, the change does not take effect immediately.
The app cannot access the local network unless the device is restarted, which results in a confusing and poor user experience.
Expected Behavior
-
If local network permission is denied, local API communication should be strictly blocked.
-
If the permission is later enabled via Settings, the app should regain access without requiring a device restart.
Request
We request clarification and resolution on:
-
Why local network APIs are accessible even when permission is denied on iOS 18.x.
-
Whether the delayed permission update (requiring restart) in iOS 17.x is expected or a known issue.
-
Best practices to ensure consistent and predictable permission handling across iOS versions.