Hi, we've come to notice that macOS will always do a password prompt even if our app is trying to deactivate our own system extension. There are other posts on this topic as well and we're probably going to have to accept this fact. However, a separate scenario that's bothering us is that, even if we have a MDM profile that whitelists our system extension (so that activating it doesn't require user interaction), we still get password prompts when trying to uninstall it. We're going to file a support ticket for this but before that we want to see if we can get some quicker response here, is this the current expected behavior or maybe are we doing something wrong in our MDM profile? Thanks!

We've seen some crash logs coming from a few of our product users. The unique device count having this issue is pretty low but 1 of them generated 35K crash logs. And so far all of the logs have been coming from macOS 12.0.1 (21A559) build. The crash stack ended at "NSCGSPanicv" in AppKit. Any pointers on what to make sense of this will be appreciated. Thread 0 (CRASHED) 0 AppKit 0x00007ff80c9837b6 NSCGSPanicv (in AppKit) + 261 1 AppKit 0x00007ff80c9836b1 NSCGSPanicv (in AppKit) + 0 2 AppKit 0x00007ff80c7983d4 +[NSCGSStatusItem statusItemWithWindowID:confiningDisplayID:flags:priority:systemInsertOrder:preferredPosition:appearance:] (in AppKit) + 0 3 AppKit 0x00007ff80c798402 +[NSCGSStatusItem statusItemWithWindowID:confiningDisplayID:flags:priority:systemInsertOrder:preferredPosition:appearance:] (in AppKit) + 46 4 AppKit 0x00007ff80c6ada6e -[NSStatusItem _wakeStatusItem] (in AppKit) + 316 5 AppKit 0x00007ff80c1f4394 -[NSStatusBar _statusItemWithLength:withPriority:] (in AppKit) + 95 ... (our product code stack below) The way by which our code is calling into AppKit is like this - [[NSStatusBar systemStatusBar] statusItemWithLength:NSSquareStatusItemLength];

This question came from https://developer.apple.com/forums/thread/695826, where I saw crashes in AppKit if called without a GUI session. What troubles me from there is that our code is registered as a LaunchAgent (under /Library/LaunchAgents), and I was under the impression that a LaunchAgent only runs if a user logs into a GUI session. I tried at least ssh-only sessions and didn't see it launch automatically (I had to manually launch it through ssh to reproduce the crash). But the fact that we see thousands of crash reports coming from a few devices means somehow our LaunchAgent is trying to launch itself automatically & repeatedly on these devices, while there is no GUI session so it keeps crashing. So, maybe there is a legit way to reproduce the scenario, to launch a LaunchAgent without a GUI session that I'm not aware of?

We noticed there had been a new "App Management" permission option under "Privacy & Security" settings introduced in the upcoming Ventura release. It accidentally blocked some of our scripts modifying parts of our product, which, at this point, proved to be problems on our end and can be resolved by us. However, we are in general wary that there doesn't seem to be any documentation on this new option and what behaviors would run into its way. Are there any guidelines Apple can provide? Also, IF it turned out at some point we couldn't work around this option, is there a corresponding MDM payload we can grant certain apps this permission through a profile (we are largely dealing with enterprise customers)?

Since upgraded to Ventura we've started seeing this popup occasionally while starting/stopping a VPN client provided by a 3rd party software. It seems like to be coming from the "System Settings" instead of from an individual software and doesn't seem to be really impacting anything - even if we just cancel the prompt the VPN can be started/stopped properly. However this is confusing nonetheless. If we do cancel the prompt without providing the authentication it asks, we get an error message in the system logs saying "AuthenticatedOperation (Change Configuration Status) error ". Is there an explanation to this prompt, or is it some kind of system bug? In the latter case we do have certain reproducing steps we'd be happy to share through a radar ticket.

While doing some persistent testing against our product (the target is a system extension), we noticed huge memory usage (1Gig+) reported by the Activity Monitor. However when we sat down to actually profile the memory usage, we noticed Intruments tool only reported ~200MB overall usage against the same process (same PID). These 2 numbers were observed at the same time. We knew that our system extension had processed some intense events during the persistent testing and its heap usage peaked at around 800 or perhaps 900MB at a time in the memory profiling; But since at the end of profiling the heap usage dropped to ~200MB I'd say we are good (we trust the Instruments result mostly). However how do we explain the fact Activity Monitor still reported the 1Gig usage (and I knew there were also confusion around the "real memory" or "private memory" stuff, the "1Gig" number referred here was from the "Memory" column from Activity Monitor)? Mostly, our concern is that since the Activity Monitor is an end user facing utility, they'd potentially look at the big number and come back complaining about our memory usage. If this happens is it ok for us to explain that the actual memory usage by our program is less than what Activity Monitor shows?

I saw another post https://developer.apple.com/forums/thread/652719 where it was mentioned at this point MetricKit is not meant to be enabled within the App Extension targets and it's up to the container app to receive the payloads on behalf of the extensions. But what's the guidance to use MetricKit for System Extension targets on macOS? I've tried subscribing to diagnostic reports from both a container app and its system extension on macOS, neither could receive any payload from the system extension. (The subscriber within the container app did receive payloads for its own reports - e.g. when the container app crashed itself, so I'm somewhat sure my test code was set up properly)

We noticed from the Monterey Beta 8/Beta 9 release notes that - Support for cleartext HTTP URL schemes for Proxy Automatic Configuration (PAC) is now deprecated. Use only HTTPS URL schemes for PAC. This affects all PAC configurations, including, but not limited to, configurations set via Settings, System Preferences, profiles, and URLSession APIs such as connectionProxyDictionary and CFNetworkExecuteProxyAutoConfigurationURL(::::). If you configure a cleartext HTTP PAC URL, the system may upgrade it to HTTPS during PAC file loads. Web Proxy Auto-Discovery (WPAD) Protocol via DNS isn’t affected. Dynamic Host Configuration Protocol (DHCP) Option 252 WPAD may attempt to upgrade cleartext HTTP URLs to HTTPS during PAC file loads. (61981845) We have a product that delivers a PAC file through http://localhost, we verified with Beta 8 and Beta 9 builds this didn't cause any problem. The question is, is this expected? The release notes make it sounds like the deprecation is enforced, or maybe this is because we are using "localhost"? If it's expected, are we going to keep this behavior in the final release? (Because it's pretty late for us to fix the HTTP scheme in time for our product now. We'd be happy if we can get away with it for now and plan for a proper fix in the next release.)

This is related to my post https://developer.apple.com/forums/thread/724698 where I submitted an issue that MetricKit reports didn't work for System Extensions on mac. I've come to realize that this is also true for Launch Daemons/Agents in the system domain (and so it probably also explains the System Extension case as I understand System Extensions are somewhat like Launch Daemons). I have a "thin executable" (a Command Line Tool target) that registers with MetricKit reports and then just crashes itself. Here's the scenarios I've tested - If I launch this executable as the current user, I receive the crash reports from MetricKit. If I launch this executable as root, I also receive the crash reports. If I register it as a Launch Agent in a "user", or a "gui" domain, I still receive the crash reports. However, if I register it as a Launch Agent in the "system" domain, or as a Launch Daemon, I got this error from the CrashReport process. <<bundle ID>> is not a MetricKit client (I noticed the same error from MetricKit APIs in our system extension targets as well) I decided to open this new post here, because the solution we were talking about in post 724698 - delivering metric reports from system extensions to their host apps - may not apply here, since a Launch Daemon/Agent may not have a host app at all. What is the guidance if we want to receive these reports?

Hi guys. I'm evaluating porting our daemon/agent service over to the new SMAppService API. I noticed one major gap here (or maybe I missed something?) that, with launchctl, we can put something under "/Library/LaunchAgents" and trivially register it as a global launch agent, yet with SMAppService.agent(...) or SMAppService.loginItem(...), the item is bound to the current user and won't propagate to a different user logged in subsequently. So what is the equivalent of the global launch agent using SMAppService?

We recently migrated our entire product to Apple Unified Logging due to the various benefits it provides. However we immediately started hitting the "log quarantine" problem ("QUARANTINED DUE TO HIGH LOGGING VOLUME"). This is partly because we are indeed over logging in a few cases (which we have to work on fixing), but also partly because it's a complicated product with potentially hundreds of libraries, and some of the code can legitimately be very busy. For example we have a system extension that's implemented both as a NetworkExtension client and an EndpointSecurity client, if we were to log decent information about each network or file system event so we can troubleshoot something, they are bound to be high volume logs. Now when our app is running in a normal user environment, this is not a problem. We can disable certain heavy log levels, or at least disable persisting for certain logs (one of the benefits of Apple Unified Logging we really like is that it allows very flexible controls, log config command, OSLogPreferences, configuration profile, we can employ whatever that suits a specific case). But ultimately, the question is what if we end up with a troubleshooting case we don't know exactly where a problem is so we just need the full logs at debug level? And not only just enabled, but because we might not know when the issue can happen either we also need to persist the full set of logs for as long as possible? We will start hitting log quarantine again. Granted this is a very extreme case, but if worst comes to worst, how can we even do that with Apple Unified Logging? Is there an option that allows us to override the quarantine, if but temporarily? I've searched a few relevant forum posts, some of which described log quarantine but no one had mentioned any solution for it (besides having to stop logging so much from the app but as I explained we do have legitimate cases where log volume can still be huge). I've also read The Eskimo's "Your Friend the System Log" and browsed some of the troubleshooting config profiles provided by Apple hoping to discover some hidden payloads but found none so far. There is an OSLogRateLimit environment variable that I noticed if I run a launchctl print system/<a-launch-daemon-lable> and it's usually 64. Is this something relevant? And knowing Apple it's probably something that can't be tampered with?

This is stemmed from another forum post on Apple Unified Logging. A few additional questions were raised towards a relevant but different topic - activity tracing, starting a new post following The Eskimo's suggestion. The first question is on log capture from an activity chain. The related documentation stated something but very vaguely. https://developer.apple.com/documentation/os/generating-log-messages-from-your-code?language=objc#Choose-the-Appropriate-Log-Level-for-Each-Message If an activity object exists, the system captures information for the related process chain We had hoped that this would somewhat play into the "speculative logging" approach we had touched upon in the original post, in the sense that if we try to log an error or fault within an activity, then it helps to capture and persist other logs on the activity chain even though they are originally not meant to be. But unfortunately from our test it didn't seem to be behaving towards that understanding. Then our question is, if we may ask - what are the exact additional information the system captures "for the related process chain"? 2nd question - are activity objects always persisted and would they also contribute to log quarantine? Our thoughts were that if we can, we'd like to create an independent activity for each event we receive from the system so the logs on every event are automatically correlated (we have a use case described in FB21839588). However as demonstrated in the FB ticket, that would mean A LOT of events and hence a lot of os_activity_create. I noticed we do have a flag Signpost-Persisted to control persisting for signposts, but there isn't a control for activities. My assumption is that they (the activity objects themselves) are always to be persisted so they would indeed contribute to quarantine in the worst case, is that correct? (Although from log stats it looks like each individual activity object is tiny in terms of storage size, so maybe they are not a big concern themselves?) And finally we noticed this control flag Propagate-with-Activity used by some logging configuration files from Apple. We didn't find any official Apple documentation but some 3rd party MDM vendors mentioned something about Propagate-with-Activity Messages attached to the activity tree Messages are attached to the activity tree in Console and crash dumps Right now based on our observation messages are always attached to the activity tree in Console regardless, and we can't seem to be able to find anything to do between activities and crash dumps. Maybe this flag is obsolete?