After Denying Local Network Permission on iOS 18, Re-granting Doesn't Allow the App to Discover Devices Over LAN for Configuration

Question

Created Apr ’25

Replies 3

Boosts 0

Participants 2

On an iOS 18 device, after installing the application and initially denying local network permission when prompted, manually enabling this permission in the system settings does not resolve the issue. After uninstalling and reinstalling the app, although local network access is granted, the app cannot discover smart hardware devices over the local area network (LAN) or proceed with configuration. The smart hardware sends configuration data packets over the LAN, but the app fails to receive these packets. This issue persists even after another uninstall and reinstall of the app. However, rebooting the device restores normal functionality.

Steps to Reproduce:

Install the application on an iOS 18 device.
Upon first launch, deny the request for local network permissions.
Manually enable local network permissions via "Settings" > [App Name].
Uninstall and then reinstall the application.
Attempt to discover and configure smart hardware devices using the app. Notice that the app fails to receive configuration data packets sent by the smart hardware over the LAN.

Expected Result:

The application should be able to normally receive configuration data packets from smart hardware devices over the LAN and successfully complete the configuration process after obtaining local network permissions.

Actual Result:

Even after being granted local network permissions, the application cannot discover devices or receive configuration data packets over the LAN unless the iPhone device is rebooted. (reinstall app and obtaining local network permissions is not work too.)

Answered by DTS Engineer in 838620022

Your answers rule out the obvious issues that I’m aware of, which brings me back to this:

Written by DTS Engineer in 834073022

Anything that requires a restart to fix is most definitely a bug.

It sounds like you can reproduce this quite reliably. If so, that’s great, because:

A lot of problems like this are really hard to reproduce.
It lets you install a debug profile, reproduce the problem, and then capture good diagnostics.

So, I recommend that you file a bug about this, following the Network Diagnostics for iOS/iPadOS instructions on our Bug Reporting > Profiles and Logs to capture detailed logging.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’25

First up, lemme start you out with TN3179 Understanding local network privacy, which is a general explanation of how this stuff is supposed to work.

Written by EricFan in 780094021

However, rebooting the device restores normal functionality.

Anything that requires a restart to fix is most definitely a bug. I’ve seen a number of reports like this from folks working on the Mac, but this is the first time I’ve seen it from someone on iOS. That’s important because iOS is a much more constrained environment, meaning that you’ll likely be able to file a more actionable bug report.

But before I send you in that direction, two questions:

In step 1 and 4, where you install the app, are you installing from App Store?
One cause of weird network access issues is programs without a main executable UUID, or multiple programs that share the same main executable UUID. See the Build-time considerations section of TN3179. I typically see this when folks have multiple apps that ‘re-skin’ the same core code. Is there any change that’s in play here?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

EricFan OP

Apr ’25

@DTS Engineer

Regarding Question 1:

Yes, the application was installed exclusively through the App Store in both Step 1 and Step 4. The issue has been consistently reproducible on iOS 18.4 and 18.3.x devices following the outlined steps. Notably, the same steps did not reproduce the issue on an iOS 16.7.10 device, suggesting potential version-specific behavior.

Regarding Question 2:

While we do maintain an internal testing version of the app with a different Bundle ID (built from the same codebase), we specifically uninstalled the test variant, performed a full device reboot, and ensured only the App Store version was present during testing. Despite these precautions, the issue persists on iOS 18 environments. This indicates the problem is unlikely related to UUID conflicts from multiple installations, as documented in TN3179's "Build-time Considerations."

We would be happy to provide additional diagnostics or clarify any details.

0

Answer 3

DTS Engineer OP

Apple

May ’25

Recommended

Your answers rule out the obvious issues that I’m aware of, which brings me back to this:

Written by DTS Engineer in 834073022

Anything that requires a restart to fix is most definitely a bug.

It sounds like you can reproduce this quite reliably. If so, that’s great, because:

A lot of problems like this are really hard to reproduce.
It lets you install a debug profile, reproduce the problem, and then capture good diagnostics.

So, I recommend that you file a bug about this, following the Network Diagnostics for iOS/iPadOS instructions on our Bug Reporting > Profiles and Logs to capture detailed logging.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0