NEAppPushProvider lifecycle guarantees for safety-critical local networking

Question

Created 5d

Replies 1

Boosts 0

Participants 2

We have an iOS companion app that talks to our IoT device over the device’s own Wi‑Fi network (often with no internet). The app performs bi-directional, safety-critical duties over that link.

We use an NEAppPushProvider extension so the handset can keep exchanging data while the UI is backgrounded. During testing we noticed that if the user backgrounds the app (still connected to the device’s Wi‑Fi) and opens Safari, the extension’s stop is invoked with NEProviderStopReason.unrecoverableNetworkChange / noNetworkAvailable, and iOS tears the extension down. Until the system restarts the extension (e.g. the user foregrounds our app again), the app cannot send/receive its safety-critical data.

Questions:

Is there a supported way to stop a safety-critical NEAppPushProvider from being terminated in this “background app → open Safari” scenario when the device remains on the same Wi‑Fi network (possibly without internet)?
If not, is NEAppPushProvider the correct extension type for an always-on local-network use case like this, or is there another API we should be using?
For safety-critical applications, can Apple grant entitlements/exemptions so the system does not terminate the extension when the user switches apps but stays on the local Wi‑Fi?

Any guidance on the expected lifecycle or alternative patterns for safety-critical local connectivity would be greatly appreciated.

Boost

Answer 1

DTS Engineer OP

Apple

3d

During testing, we noticed that if the user backgrounds the app (still connected to the device’s Wi‑Fi) and opens Safari, the extension’s stop is invoked with NEProviderStopReason.unrecoverableNetworkChange / noNetworkAvailable, and iOS tears the extension down.

What's the specific testing scenario here? More specifically, is this "real world" testing with a disconnected device or is this a development device that's attached to a Mac, particularly with any kind of “active” interactions between the device being tested and the Mac?

The one scenario I can think of that might explain this is that Safari has its own network-based debugging infrastructure, and it's (theoretically) possible that might be disrupting the app’s normal networking behavior.

Related to that point, are you SURE the device is on the same WiFi network? I can't think of any scenario where NEAppPushProvider would stop working while you remained on the same network, but I can see the device changing networks without that being "obvious".

What I'd actually suggest here is making a small test app that lets you ping/interact with your network server WITHOUT involving your VoIP app. As a handy "testing trick", give that test app the "audio" background category and have it play simple tones every few seconds that tell you the state of things. That will let the app constantly monitor the state of things while still using the device normally.

However, if this is happening under normal usage*, then the next step is to file a bug and post the bug number back here, as this should not be happening.

*You can certainly file a bug even if this is specifically caused by the Safari debugger; however, the reality is that there are always going to be cases where we just can't both:

Provide the "best" debugging/development tools.
Have the device behave "normally" while those tools are running.

Sometimes you can only have one of those.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0