# CoreWLAN SSID access and Location Services authorization > Source-anchored research for CoreWLAN SSID access and Location Services authorization. Run status: COMPLETED. Parent: [macOS App Sandbox Networking and Entitlements](https://llms-explorer.com/tree/macos-app-sandbox-networking/) · 4 facets · 8 facts · page: https://llms-explorer.com/tree/corewlan-ssid-access-and-location-services-authorization/ ## Definitions - Core WLAN is not supported in Mac Catalyst and NEHotspotNetwork is iOS-only. 'Mac (Designed for iPad)' strips sandbox entitlements. DTS says there is no good way to read the SSID there, so a native AppKit/SwiftUI-for-macOS target is required for an SSID feature. (low confidence) — [source](https://developer.apple.com/forums/thread/770670) ## How it works - On macOS 27.0 CWInterface.ssid() and bssid() still return nil without Location authorization, while non-identifying data such as RSSI is returned. The fix reported is to add NSLocationWhenInUseUsageDescription to Info.plist, request Core Location authorization, then retry ssid(). Stats 3.0.17 shows SSID 'Unknown' on macOS 27 because it does none of this. (medium confidence) (verified as of 2026-09-23) — [source](https://github.com/exelban/stats/issues/3636) - Command-line tools are unreliable for CoreWLAN SSID. On Sequoia 15.1.1 a CLI got nil SSID and BSSID from scanForNetworks with Location authorized, while the same code in a GUI app worked. DTS guessed the cause is run-loop behavior (a normal app runs the run loop continuously) and left it unresolved. (low confidence) (verified as of 2024-11-01) — [source](https://developer.apple.com/forums/thread/769950) ## Problems, failure modes and limitations - A launchd daemon cannot obtain the location privilege. Apple DTS said 'as things currently stand I don't think it's feasible for a daemon to do this'. A privileged helper or LaunchDaemon cannot read the SSID itself, so the GUI app must read it and pass it over. (medium confidence) — [source](https://developer.apple.com/forums/thread/732431) ## Facts and statements - Since macOS Sonoma (change landed in Sonoma beta 2), CWInterface.ssid() requires the location privilege. Apple DTS relayed from the CoreWLAN team that this was deliberate, and the CWInterface.h comment reads: 'SSID information is not available unless Location Services is enabled and the user has authorized the calling app to use location services.' Without it, ssid() returns nil. (high confidence) — [source](https://developer.apple.com/forums/thread/732431) - A sandboxed app needs the App Sandbox entitlement com.apple.security.personal-information.location (Xcode: Signing & Capabilities > App Sandbox > App Data > Location) to be eligible for Core Location authorization, plus com.apple.security.network.client. Forum users report this working. A DTS engineer said no restricted entitlements or provisioning profile are needed for CoreWLAN itself. (medium confidence) — [source](https://developer.apple.com/forums/thread/732431) - For a LaunchAgent registered via SMAppService.agent(plistName:), request Location authorization from the container GUI app, not the agent. TCC treats the app as the agent's responsible code, so the grant should extend to the agent. A reporter on macOS 26.3 saw the agent get nil while the app did not, and DTS advised this approach. (medium confidence) (verified as of 2026-02-01) — [source](https://developer.apple.com/forums/thread/816619) - Shell-level SSID routes were closed in macOS 14.x: the airport tool stopped returning connection info in 14.4, and wdutil info shows 'redacted' for MAC address, SSID and BSSID from 14.5. networksetup -getairportnetwork still worked per admins, with no guarantee. These routes are unavailable to a sandboxed App Store app anyway. (low confidence) (verified as of 2024-05-01) — [source](https://community.jamf.com/general-discussions-2/collecting-active-ssid-with-macos-sonoma-14-4-and-later-32298)