Using 1.1 beta 1, I am unable to download TestFlight from the App Store. All other apps work, including VisionOS and iPhone and iPadOS. Logging out / back in and rebooting the device didn't fix this. Anyone find a way to resolve this?

We are using a DNS Settings profile with On Demand rules pushed to macOS devices and that is working swimmingly... until users try to use a network with a captive portal present. Upon connecting to a network with a captive portal that is preventing access to the internet, the DNS Settings take effect and start routing all DNS requests – namely those that are required to clear the captive portal itself – towards the DNS Settings defined name servers. Those name servers exist on the public internet. Of course, those DNS packets are dropped by the network because the captive portal isn't cleared, so the user is stuck staring at a blank Captive Portal Assistant login screen since the DNS requests required to load the captive portal UI are failing. We've tried all sorts of hacks to try to get the DNS Settings profile to disconnect using creative On Demand rules, but alas, since the interface is only in a "half connected" state while pending Captive Portal Assistant completion, those On Demand rules are never even evaluated. It seems like Apple needs to fix this with logic to the effect of "if there are no network interfaces with an active gateway, disconnect/deactivate the DNS Settings ". Right now, it defaults to the "Connected" state, so "half connected" interfaces when a captive portal is present will always be bricked. As a workaround: is there a programmatic way to disable the DNS Settings configuration on the device? networksetup doesn't seem to have remit over the DNS Settings config, only physical network interfaces, and I can't find anything similar. It is possible to set the DNS Settings config to "Inactive" in the Network preferences pane (through the ... menu), but I can't seem to find a way to do this programmatically. Or, is there a prescribed way to support captive portals? Thanks for the help!

Hello,We actually managed to get all of the code signing and entitlements with our Developer ID all aligned properly such that our NE system extension is installed, activated, and our packet tunnel provider is started and code is executed in the extension. So far so good!However, the outstanding problem that is tripping us up at the finish line is that we just can’t seem get the NE provider to read from a shared keychain. The main app is able to write a password type key to the keychain no problem (we can see it in the macOS Keychain app), but our extension reports a -25291 or -25300 depending upon what we are trying when trying to read in the value. The exact same keychain read/write implementation works fine in dev builds without using System Extensions, so I’m pretty sure there must be some specific configuration I am missing when it comes to keychain sharing with System Extensions.We've tried with App Sandbox on and off, and there is no difference.According to this doc a shared Keychain Access Group Entitlement configured in the main app and NE System Extension should be all that is required. This is what we are doing and I believe is why everything is working fine in builds without the system extension.We’ve tried all of the combinations of things I can think of, specifically mixing and matching various app group and keychain group identifiers, unfortunately all with the same result.I beleive we are possibly in bug territory, but given how precise Keychain configuration needs to be, I wanted to check with the community to see if anyone had run into this same issue and found a solution before I file a bug. Thanks!

We have had many devices install our SystemExtension based Network Extension via Developer ID, and all of that works fine. However, when upgrading, some devices end up in a strange state where the SystemExtension is "stuck" between versions. See the systemextensionsctl list results below: -- com.apple.system_extension.network_extension enabled active teamID bundleID (version) name [state] LLW79T3K9U app.company.ne (0.5.5/5) app.company.ne [terminating for uninstall] LLW79T3K9U app.company.ne (0.3.4/4) app.company.ne [terminated waiting to uninstall on reboot] LLW79T3K9U app.company.ne (0.5.6/6) app.company.ne [activated waiting to upgrade] We've noticed that the[terminated waiting to uninstall on reboot] happens on all machines, but appears to be benign. However, the [terminating for uninstall] 0.5.5 version seems to be blocking 0.5.6 with the[activated waiting to upgrade] state. In this state our 0.5.5 version is not working, throwing immediate errors when trying to start the VPN. Specifically, we see the below in our logging: 2020-08-05 12:13:21.618+02:00 [Info][AppStateService]: Tunnel activation started. 2020-08-05 12:13:21.619+02:00 [Info][AppStateService]: System extension activation started. 2020-08-05 12:13:21.622+02:00 [Info][SystemExtensionService]: System extension (app.company.ne) request started. 2020-08-05 12:13:21.626+02:00 [Info][AppStateService]: Application state changed - enabling 2020-08-05 12:13:21.627+02:00 [Info][AppStateService]: Application state changed - enabling 2020-08-05 12:13:21.628+02:00 [Info][StatusItemPopoverViewModel]: Reload popover state - enabling 2020-08-05 12:13:26.710+02:00 [Error][SystemExtensionService]: System extension request failed - The operation couldn’t be completed. (OSSystemExtensionErrorDomain error 1.) 2020-08-05 12:13:26.711+02:00 [Error][AppStateService]: System extension activation failed - The operation couldn’t be completed. (OSSystemExtensionErrorDomain error 1.) 2020-08-05 12:13:26.711+02:00 [Error][AppStateService]: Tunnel activation failed - The operation couldn’t be completed. (OSSystemExtensionErrorDomain error 1.) 2020-08-05 12:13:26.752+02:00 [Error][StatusItemPopoverViewModel]: Show error - The operation couldn’t be completed. (OSSystemExtensionErrorDomain error 1.) Thoughts? Anyone else ever see this?