Title: Accessing Wi-Fi SSID for custom On-Demand logic in PacketTunnelProvider on macOS

Is location access mandatory to access wifi SSID on macOS even if we have a NEPacketTunnelProvider?

I’m not sure what the specific rules are for that on macOS. Before I invest time in investigating that, I’d like to clarify your goals.

we want to add some additional feature to the native behaviour.

Are you porting this feature from iOS? Or is this something new in your Mac product?

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

Thanks for following up.

This is not a port from iOS; it’s a macOS-specific requirement.

We use standard On-Demand rules to automatically connect the tunnel on specific Wifi for example. What we want is to allow the user to manually disconnect the tunnel via a UI button even while the On-Demand condition remains satisfied, without disabling or removing the On-Demand rules.

After a manual disconnect, On-Demand monitoring should continue, and when a different On-Demand rule becomes satisfied, its action should be triggered normally.

Is there a supported way on macOS to allow this kind of user-initiated override while keeping On-Demand enabled?

What we want is to allow the user to manually disconnect the tunnel via a UI button

A button in your app? Or elsewhere in the system?

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

Yes, a button in our app.

OK.

So, there’s no way for your code to plug-in to the VPN On Demand engine. You can configure various parameters that affect its behaviour, but that’s it. This makes sense when you think about it:

• Your container app is not necessarily running when the VPN On Demand engine does its evaluation.
• The VPN On Demand engine is what causes the system to instantiate your NE provider, and so your NE provider can’t change the engine’s decisions because it’s not yet running.

Note Having said that, such an ability would be cool. If you get to the end of your current investigation and decide that the current setup is insufficient for your needs, you should feel free to file an enhancement request describing your requirements. And if you do that, please post your bug number, just for the record.

With that in mind, let’s coming back to your requirements. Earlier you wrote:

we want is to allow the user to manually disconnect the tunnel via a UI button even while the On-Demand condition remains satisfied

and also:

without disabling or removing the On-Demand rules

So, I’m not an expect on VPN On Demand rules. My focus is on APIs, and the VPN On Demand rules fall into the more general category of VPN configuration. When folks ask me questions like this, I general suggest that they prototype their setup using a configuration profile. If they can make things work there, then I’m happy to help work out how to use the API to achieve the same effect.

However, my understanding is that there’s isn’t a direct way to square this particular with the VPN On Demand rules as they currently stand.

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

Thanks for the response.

Given that we can’t influence On-Demand decisions, we’re considering handling user-initiated override logic entirely in the container app while it is running, purely to drive UI state and call stopVPNTunnel() when the user presses a Disconnect button.

For that app-side monitoring, we’d need to observe:

1. active interface type (Wi-Fi vs Ethernet)
2. current Wi-Fi SSID
3. notifications when either of these change

On macOS, is Location authorization mandatory to obtain the Wi-Fi SSID via CWWiFiClient (or related APIs), even when the app bundles an NEPacketTunnelProvider?

Put differently, is there any supported way for a macOS VPN app to observe SSID changes without requesting Location access, or is that an explicit platform requirement?

On macOS, is Location authorization mandatory to obtain the Wi-Fi SSID via CWWiFiClient … even when the app bundles an NEPacketTunnelProvider?

First up, a clarification. On iOS, embedding an NE provider is not sufficient for SSID access. Consider this quote from the the docs:

The app has active VPN configurations installed.

So it’s not gated by the presence of an NE provider, but rather by the user having approved the installation of a VPN configuration for that provider.

As to whether that’s works on macOS, I’m not sure. It’d be easy for you to test though (-:

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

Thanks for the response.

We’ve already tested this on macOS, and in our case obtaining the Wi-Fi SSID via CWWiFiClient does not work without Location authorization, even though:

• the app bundles an NEPacketTunnelProvider
• the user has explicitly installed and approved our VPN configuration

What’s confusing to us is that there are multiple third-party macOS apps (including ones distributed on the Mac App Store) that visibly display the current Wi-Fi SSID and update it live as the network changes, without ever prompting the user for Location permission.

Given that, we wanted to ask more directly:

• is there a supported API, entitlement, or configuration path on macOS that allows observing the current SSID and SSID changes without requesting Location access?

We want to make sure we’re not missing a supported approach before committing to a Location permission prompt purely for UI state management.

We’ve already tested this on macOS

OK.

If you’d like to see this change — that is, for macOS to have the same “active VPN configurations” affordance that iOS has — I recommend that you file an enhancement request for that. Please post your bug number, just for the record.

is there a supported API, entitlement, or configuration path

No.

The Core WLAN policy is gated by a linked-on-or-later check, which provides compatibility for existing products while enforcing the privacy rules for new products. And while it’s easy to lie about the SDK you’re built with — if you’re curious, see the vtool man page — we don’t support that because:

• The SDK you’re built with controls a wide range of interesting functionality, and it’s not hard to imagine scenarios where lying about that could cause your product to fail in unexpected ways.
• The path forward here is clear: We don’t want Mac apps getting the user’s SSID without the user understanding that it could be used to track their location. If you try to get around that, you’ll eventually run into problems.

I actually saw this happen as we rolled out this privacy policy:

1. It was first enabled in Core WLAN.
2. Developers tried to bypass by running the airport tool.
3. And in the next major OS release we blocked that path as well.

Note All of this played out here on the forums. I don’t have time today to look up the threads, but if you’re curious you should search for threads with the Core WLAN tag created since we started seeding macOS 14 (so since June 2023).

So, you want to get on a supported path, and I think the best option in your case is to file an ER for the “active VPN configurations” affordance.

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