Enhancement request filed: FB12083539 On the status front, I think your best option is to provide an XPC service from your sysex that vends the status. You’ll be able to connect to that from anywhere. The only issue with that approach is I don't think it's doable from the appex, so I'll anyways need an alternative. Is my understanding correct? On the start/stop front, I don’t see a good solution. Launching your container app hidden might work but I can see that ending up being quite brittle. It seems to work well with a Developer ID app since I can open it using NSWorkspace.shared.open and passing startup arguments that prevent the app from fully launching. The problem though is that those launch arguments are ignored for the Sandbox version, so I'm trying to figure out an alternative for it. Any ideas are welcome.

I managed to resolve my issue to the point where I can at least debug the app. I'm not sure yet if my solution resolves the issue for good, but it's good enough for being able to test. It was indeed a weird caching issue by macOS. I'll document it here in hopes that it may help others resolve this issue in the future. We're developing an app that uses a different target / bundle ID for the developer ID build and the App Store one. Additionally the same applies to the Login Item we're launching, where the same login item has a developer ID target and an App Store target with different bundle IDs. What caused this issue in the first place? I believe the trigger for this issue was that when I set up the developer ID build of our App, I added the wrong login item. This caused in our developer ID app being associated with the App Store login item in launchctl. I changed the agent after realizing the mistake but the App Store Agent would never launch. How I debugged this I initially focused on checking the parent app / login item association that you can see by calling: sfltool dumpbtm The association returned by that tool was correct, and nothing in it seemed off. I tried resetting it through sfltool resetbtm, but that didn't work at all. At some point I started diving deeper into launchctl, and used this command to get a very detailed state report: launchctl dumpstate > out.txt And when looking for my agent's bundle ID I realized that launchctl was showing a different association with the wrong parent bundle ID. The snippet looked more or less like so: gui/userid/teamid.my.agent.bundle.id = { active count = 0 path = (submitted by smd.299) type = Submitted state = spawn scheduled program identifier = teamid.my.agent.bundle.id (mode: 1) parent bundle identifier = developer.id.bundle.id.instead.of.app.store.bundle.id Resolution: Once realizing that association was off... I looked at this file: /var/db/com.apple.xpc.launchd/loginitems.userid.plist It contains an association between login items and parent bundle IDs. I manually edited the file to correct parent app bundle ID. Cleaned everything, rebooted, et voila! Hope it helps.

I found that CFMessagePort is working fine for the appex but not for the sysex (where the network extension is listening on a port, and the menu login-item app is connecting to it to get status updates). Is this expected or should it be working? The exact same code works fine for our App Store build using an appex. In generally I find it that IPC with network extensions (appex vs sysex) requires completely different approaches, which is a huge time sink for development (and I'd love to avoid!). Thanks for all the help!

The strange thing is CFMessagePortCreateLocal is succeeding, CFMessagePortCreateRemote is also succeeding (which I imagine means the port lookup is working well on both ends), but calls to CFMessagePortSendRequest are timing out only for the sysex. I'm testing different things following your indications, but I was wondering if this scenario could be indicative of a specific problem to look at?

We're having the same problem that prevents us from using on-demand at all. I've reported an improvement suggestion under FB12451642

There's actually a more worrying issue around this as I'm managing to start my VPN system extension even if the user doesn't allow it. Are you sure that the extension is not working for you? It is for me. When only one App requests permission to install a System Extension, the user only has two choices in System Settings: ignore the request or allow it. This means that if the user ignores the request nothing will be installed. However when there's more than one request to activate an extension at the same time there seem to be three options: ignore all requests, allow some, or allow all. The problematic option, at least from what I'm seeing, is "allow some". Leaving the toggle turned OFF and disallowing some extensions is what seems to not be really disallowing those extensions... I can still start them both with the App I'm working on, and with a third party app named Lulu that I used to test this further. Is this expected?

I found one way to reproduce this easily is by having two requests to install a system extension, and only allowing the other one (ie: not the one for my VPN). This results in my VPN loading anyways, but the routing table not being set correctly. I added some additional details here: https://developer.apple.com/forums/thread/724153?answerId=762021022#762021022 We'll be posting a radar with a video because it seems to be a larger problem than the VPN not routing.

Some additional information: we did try debugging this issue and in my case OSSystemExtensionRequestDelegate's request(_:didFailWithError:) is being called with error OSSystemExtensionErrorRequestSuperseded. When debugging this in someone else's system the delegate is not being called at all, even though a new request is being queued.

Since Apple isn't responding to TSIs this week, but will be looking at developer forums I was wondering if it would be possible to get some response on this query. It'd be great to be able to offer PiP to users.