Sorry for the typo I meant NSWorkspace.runningApplications.

Hi, An update: as I use KVO on NSWorkspace main run loop remains mandatory (documented and tested). Anyway I’m not sure if the difference is only footprint-relative or if there are more complex reason for going GCD only.

Waiting for NEHotspotHelper on Mac, I've been able to implement a (somehow) working solution relying on NSRunningApplication.runningApplications. When looking at CNMarkPortalOnline documentation: Captive Network Support will notify the rest of the system that WiFi is now a viable interface. How does this notification occurs ? Is there an event or notification such as 'Captive Portal is now Online' ?

Hi an update on this topic. Using SNI using handleOutboundDataFromFlow fails because near all traffic is encrypted and no headers or metadata can be fetched for that purpose. I tried as B-plan to replicate capture.apple.com behaviour to detect redirects and allow them. This is a tricky job because the Firewall rules need to be updated live to follow redirects but on the paper (i.e simulating with Safari) it works. However in captive-portal tests I face another problem: Captive Portal Assistant seems to block all traffic out if his own session (not sure how this is done). For Example Safari or curl won't get a response while the CPA is opened, as they do under the same SSID if CPA is closed. Is some way this could be an helpful solution for my use-case if I was able to confirm that CPA session is ongoing. CNCopySupportedInterfaces seems to be dedicated to that and is available on Mac. However it always returns null. I know that some (obsolete) CN API require some specific entitlements on iOS but I've found nothing about Mac requirements. Any hint ?

If my understanding is good you suggest : Using RFC7710 to grab captive URL Get SNI during handshake and compare with portal host Drop handshake flow if they don’t match This limit to a subset of portals implementing the RFC but could be a good start. I’ll try that.

Hi Matt, Thank you for looking at this topic. My concern is not for a specific portal I can whitelist explicitly. I’m looking to support any portal (hotels, transportation, restaurants, etc). Regards, Jerome Tarantino

Feature request is sent as FB9963670

Local notifications can be sent using the legacy (deprecated) NSUserNotification & NSUserNotificationCenter. The main bundle doesn’t seems to be on the critical path for this API. I’ll file a feature request for supporting LaunchAgents hosted in XPC Service with UNNotificationCenter. In the meantime NSUserNotificationCenter can act as a workarround.

An update on KVO observing. I succeeded solving my issue by : Observing a defaults inited with initWithSuiteNamed. Observing standardUserDefault + addSuiteName seems to fail. Adding TeamID to the suite name.

I used the default SCNetworkReachabilityScheduleWithRunLoop from main source code during launch. As the service is based on MachService name the resume method returns and I did setup a main run loop. I tried also postponing SCNetworkReachabilityScheduleWithRunLoop using GCD (dispatch to main queue) and both solutions are running fine. I’ll try SCNetworkReachabilitySetDispatchQueue As well to see potential benefits.

Hi Quinn, I confirm this is a System Extension (content filter used as Firewall). OSSystemExtensionErrorValidationFailed disappears if bundle ID and AppGroup are synchronized. It’s not yet clear to me if the ‘group.’ prefix need to be used for AppGroup. Looking at Group Containers folder some apps use the prefix some others do not (including Apple’s). Based on your explanation, I moved the XPC Service from daemon to agent so that it runs in user context. However KVO observation isn’t triggered between container app and XPC Service. Yet defaults values are up-to-date if I use XPC communication as notification.

Hi suMac, Did you had any chance to find a solution ? I'm looking also on a way to do local user notifications from an agent.

An update on this issue. When the service runs as agent it behave as expected. i then assume this is related to some process privileges.

Update: fixed now. Maybe due to heavy load as someone suggested. Maybe because I did first 11.5 beta 2 installation.

Same here even on day 2. Tried with MacBoorAir 2017 which is in the supported list of hardware.