Questions about NEHotspotEvaluationProvider Extension

Question

Jasper-Quinn OP

Created 1w

Replies 3

Boosts 0

Participants 3

Description :

Our app helps users connect to Wi-Fi hotspots. We are trying to adapt our code to iOS 26 Hotspot Authentication and Hotspot Evaluation application extensions.

When filtering hotspots in the filterScanList callback, we need to fetch support information from a remote server to determine which hotspots are supported. However, attempts to use URLSession or NWTCPConnection in the extension always fail.

When accessing a URL (e.g., https://www.example.com), the network log shows:

Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found."

When accessing a raw IP address, the log shows:

[1: Operation not permitted]

Interestingly, NWPathMonitor shows the network path as satisfied, indicating that the network is reachable.

Question:

Are there any missing permissions or misconfigurations on our side, or are we using the wrong approach? Is there an official recommended way to perform network requests from an NEHotspotEvaluationProvider extension?

Answered by DTS Engineer in 856334022

Oh, wow, someone finally noticed this new API. Cool (-:

attempts to use URLSession or NWTCPConnection in the extension always fail.

Right. One goal of the new architecture is to improve privacy. That’s why there are two extensions:

The hotspot evaluation provider, which implements the NEHotspotEvaluationProvider protocol, is responsible for .filterScanList and .evaluate commands. It runs in a tight sandbox that prevents it from ‘exporting’ the Wi-Fi scan results.
The hotspot authentication provider, which implements the NEHotspotAuthenticationProvider protocol, handles the other commands. It runs in a looser sandbox, but only receives information about the network the user has chosen to join.

If your evaluation provider needs information about what networks to support, you should have your app (or your authentication provider) put that information in an app group container. The evaluation provider will be able to read that container, but not write to it.

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

Boost

Answer 1

DTS Engineer OP

Apple

1w

Accepted Answer

Recommended

Oh, wow, someone finally noticed this new API. Cool (-:

attempts to use URLSession or NWTCPConnection in the extension always fail.

Right. One goal of the new architecture is to improve privacy. That’s why there are two extensions:

The hotspot evaluation provider, which implements the NEHotspotEvaluationProvider protocol, is responsible for .filterScanList and .evaluate commands. It runs in a tight sandbox that prevents it from ‘exporting’ the Wi-Fi scan results.
The hotspot authentication provider, which implements the NEHotspotAuthenticationProvider protocol, handles the other commands. It runs in a looser sandbox, but only receives information about the network the user has chosen to join.

If your evaluation provider needs information about what networks to support, you should have your app (or your authentication provider) put that information in an app group container. The evaluation provider will be able to read that container, but not write to it.

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

0

Answer 2

wym572 OP

4d

After testing the new NEHotspotManager in iOS 26, we ran into some challenges:

Since NEHotspotEvaluationProvider does not allow network requests, how can we practically match scanned WiFi networks against our hotspot database (billions of SSID/BSSID entries)?
In iOS 26, does NEHotspotManager still require a separate Hotspot Helper entitlement?
If yes, will the existing NEHotspotHelper continue to work, and is there a planned deprecation timeline?

0

Answer 3

DTS Engineer OP

Apple

21h

1- Since NEHotspotEvaluationProvider does not allow network requests, how can we practically match scanned WiFi networks against our hotspot database (billions of SSID/BSSID entries)?

That would require significant engineering smarts, and possibly some trade-offs. I can think of at least two potential paths forward:

I can imagine that an SSID database would compress very well, although you’ll probably want to develop a custom compression algorithm rather than, say, relying on a general-purpose compressor like Deflate.
You could also divide the database up by regions and let the user download the database for their preferred regions.

2- In iOS 26, does NEHotspotManager still require a separate Hotspot Helper entitlement?

Yes. Well, no, but also yes.

In iOS 26 you can produce a useful hotspot helper without the com.apple.developer.networking.HotspotHelper entitlement. The trick is:

Do not implement an evaluation provider.
Implement an authentication provider.
Put the SSIDs you support in the evaluatedSSIDs property.

This has significant limits, but it’s a nice path forward for those that can fit within those limits.

If you’re product requires an evaluation provider, you will need the com.apple.developer.networking.HotspotHelper entitlement.

3- If yes, will the existing NEHotspotHelper continue to work, and is there a planned deprecation timeline?

NEHotspotHelper should work as it always did on iOS 26.

We’ve not announced a deprecation timeline.

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

0