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.
Any situation that requires you to restart your device to clear a problem, as you’re seeing on iOS 17, is obviously a bug.
Normally I’d encourage you to just file that bug, but in this case I’m gonna be a bit equivocal. On the one hand, iOS 17 is in maintenance mode and that makes it hard to find a release vehicle for a fix like this. On the other hand, this is related to privacy, and privacy bugs often make the cut for maintenance updates. On the other other hand, it fails securely (inconveniently, but securely), so it might not make that cut.
Honestly, it’s up to you whether you want to file this, but please don’t be surprised if it comes back as ‘not to be fixed’.
If you do file a bug, please post your bug number, just for the record.
On the iOS 18 front, if you’re continuing to see problems on the iOS 18.6 beta, you should definitely file a bug about that.
IMPORTANT Don’t mix this in with your iOS 17 issue. Also, don’t muddy the waters by including details of iOS 18.x, x < 6. Keep this bug report focused on the latest iOS 18.6 beta.
Make sure you:
-
If possible, create a small test project, use that in all your tests, and attach the project to your bug. That guarantees that the issue isn’t somehow being caused by something else in your main app.
-
Install the relevant debug profiles on the device you’re testing on. I recommend Network Diagnostics, VPN (Network Extension), and Wi-Fi, all available on our Bug Reporting > Profiles and Logs page.
-
Include detailed steps to reproduce the problem, with rough timestamps of relevant events.
-
Attach sysdiagnose log taken shortly after reproducing the problem.
Please post your bug number, just for the record.
ps I love that table! Clearly you’ve done almost as much LNP testing as I have (-:
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"