NEAppPushProvider blocked from local network access even when container app has permission

Hi everyone,

I’m encountering what appears to be a system-level issue with NEAppPushProvider extensions being unable to communicate with other devices on the local network, even when the main app has already been granted Local Network permission by the user.

Context

The following problem occurs in an iPad app running iOS 18.5. The main app successfully requests and is granted Local Network access via NSLocalNetworkUsageDescription in its Info.plist configuration. It can connect to a WebSocket server hosted on the local network without any issues, resolving its address by name.

The extension (NEAppPushProvider) uses the same networking code as the app, extended via target membership of a controller class. It attempts to connect to the same hostname and port but consistently fails to establish a connection. The system log shows it properly resolving DNS but being stopped due to "local network prohibited". An extract of the logs from the Unified Logging System:

12:34:10.086064+0200	PushProvider	[C526 Hostname#fd7b1452:8443 initial parent-flow ((null))] event: path:start @0.000s
12:34:10.087363+0200	PushProvider	[C526 Hostname#fd7b1452:8443 waiting parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: path:satisfied @0.005s
12:34:10.090074+0200	PushProvider	[C526 Hostname#fd7b1452:8443 in_progress parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: flow:start_connect @0.006s
12:34:10.093190+0200	PushProvider	[C526.1 Hostname#fd7b1452:8443 in_progress resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: resolver:start_dns @0.009s
12:34:10.094403+0200	PushProvider	[C526.1.1 IPv4#f261a0dc:8443 waiting path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, uses wifi)] event: path:unsatisfied @0.010s
12:34:10.098370+0200	PushProvider	[C526.1.1.1 IPv4#f261a0dc:8443 failed path (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, uses wifi)] event: null:null @0.014s
12:34:10.098716+0200	PushProvider	[C526.1 Hostname#fd7b1452:8443 failed resolver (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: resolver:children_failed @0.015s
12:34:10.099297+0200	PushProvider	[C526 Hostname#fd7b1452:8443 waiting parent-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi)] event: flow:child_failed @0.016s

What I’ve Confirmed:

  • The extension works perfectly if the DNS is changed to resolve the name to a public IP instead of a local one. The extension always connects by hostname.
  • Devices on the local network can resolve each other’s IP addresses correctly and respond to pings.

What I’ve Tried

  • Adding NSLocalNetworkUsageDescription to the main app’s Info.plist, as recommended.
  • Clean building the project again.
  • Removing and reinstalling the app to ensure permission prompts are triggered fresh.
  • Restarting the iPad.
  • Ensuring main app cannot access the local network until the permission is granted.
  • Ensuring the main app has connected to the same hostname and port before the extension attempts a connection
  • Toggling the permission manually in Settings.

Apple’s documentation states (TN3179):

“In general, app extensions share the Local Network privilege state of their container app.”

It also notes that some background-running extension types may be denied access if the privilege is undetermined. But in my case, the main app clearly has Local Network access, and the extension never receives it, even after repeated successful connections by the main app.

Question

Is this a known limitation with NEAppPushProvider? Is there a recommended way to ensure the extension is able to use the local network permission once the user has granted it on the app?

Any feedback, suggestions, or confirmation would be greatly appreciated. Thanks in advance.

After further testing on other devices, I’m unable to reproduce this issue on either an iPhone 16E or an iPhone SE, both running iOS 18.5. However, running the exact same project on an iPad (7th generation, also on iOS 18.5) consistently results in local network traffic being blocked, with the same Local network prohibited message in the logs.

Could there be a reason why this behavior would affect iPads specifically?

Accepted Answer

Please check out the discussion of FB14321888 in TN3179 Understanding local network privacy. Given the severity of that bug, I recommend that you repeat your tests on iOS 18.6.

Well, iPadOS 18.6 (-:

Quoting the top of that technote:

Local network privacy works the same on iOS, iPadOS, and visionOS. Unless otherwise noted, assume that any info about iOS applies to all three platforms.

Share and Enjoy

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

I’ve updated to iPadOS 18.6 on the devices currently available to me, and the Local Network permission now appears to be working correctly in the extension. I’ll be able to run the full test suite in our lab environment within 24 hours to confirm this. If everything checks out, I’ll mark this as resolved.

After testing in our tech lab with all devices updated to iOS/iPadOS 18.6, I’m seeing improved behavior overall, but some inconsistencies remain, particularly with older hardware.

  • On iPhone SE (18.6), the issue does not reproduce. Local network access from the extension works as expected.
  • On iPad 10th gen (18.6), the issue is no longer observed. Notably, this device did occasionally fail on 18.5.
  • On iPad 7th gen (18.6), behavior remains inconsistent. The extension is sometimes able to send local network traffic, but in other cases, it fails with the same “Local network prohibited” error. Success seems more likely after switching Wi-Fi networks or if the main app has already made a successful local connection beforehand, but this is not reliable or predictable.

So while iPadOS 18.6 clearly improves the situation, it appears that residual issues may still affect older devices. I’ll be extending testing to 8th and 9th gen iPads on Monday and will share any additional findings.

Let me know if there are any additional diagnostics or system logs I can provide to help isolate this further.

Thanks for testing this so thoroughly.

it appears that residual issues may still affect older devices.

I can’t think of any good reason why this would be hardware specific [1].

If you’re able to reliably reproduce this with iOS 18.6, I recommend that you file a new bug about that. Also:

  • If it’s tied to specific hardware, call that out in your bug report.
  • Install the Network Diagnostics debug profile before you test. See our Bug Reporting > Profiles and Logs for more.
  • Trigger a sysdiagnose as soon as you see the problem.
  • And attach that to your bug report.

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"

[1] Hmmm, it could be a lack of memory causing some internal subsystem to be jetsammed at an inconvenient time, but that’s hardly a good reason.

After testing iPads from the 7th, 8th, 9th, and 10th generations on both iPadOS 18.5 and 18.6, the original issue appears to be resolved on all but some 7th gen devices.

On those affected 7th gen iPads, the NEAppPushProvider extension still consistently fails to access the local network, even after clean installs, restarts, and other troubleshooting previously described. Notably, at least one 7th gen device did not exhibit the issue.

I’ve filed a new bug report: FB19375657, including sysdiagnose logs and context.

Thanks for the help.

NEAppPushProvider blocked from local network access even when container app has permission
 
 
Q