Post not yet marked as solved
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?
Post not yet marked as solved
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?
Post not yet marked as solved
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.)
Post not yet marked as solved
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)
Post not yet marked as solved
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?
Post not yet marked as solved
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.
We noticed there had been a new "App Management" permission option under "Privacy &amp; 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)?
Post not yet marked as solved
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?
Post not yet marked as solved
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];
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!
qb_s.