I'm observing something that is a bit worrying when it comes to system extensions. I have a simple system extension that contains 2 providers: a NEFilterDataProvider a NEFilterPacketProvider It's basically the Simple Firewall sample code with the additional NEFilterPacketProvider provider. Problem: When I start the system extension from a clean state, everything works as fine as it can. When I stop the system extension, it does stop as fine as it can. When I try to start the system extension again, the network extension is reported not to be running in the System Preferences > Network pref pane. If I restart the Mac, the network extension is reported to be running in the System Preferences > Network pref pane. Question: Is this the expected behavior? No restart was required when there was only a NEFilterDataProvider in the system extension. Environment: macOS 10.15.4 / Xcode 11.4.1 Side note: Is system extensions UX improved in Big Sur when it comes to installation, activation, etc. ? When something goes sideways in Catalina, it's more difficult to figure out the origin of the issue when using system extensions than it used to be with kernel extensions. Part of this is due to the different sources of information not being synchronised or consistent/coherent. e.g. what systemextensionsctl says may not match what the system Preferences > Network panel says.

According to Technical Note TN2151 - https://developer.apple.com/library/archive/technotes/tn2151/_index.htm, in the Binary Images section of a .crash file, when a binary name/identifier is prefixed with a +, it means that the binary is part of the OS. Question: Is this really the (only) case? I'm looking at a crash log for an application named "CCLibrary.app" and numerous binaries from this bundle application have their names prefixed with + in the Binary Images section.

I have an app and a launchd daemon.- The app communicates with the launchd daemon through XPC.- The launchd daemon is triggered by the XPC "message" and exits after having completed its task.Problem:When I repeatedly launch the app, launchd is not happy with the fact that the daemon only runs for around a second and starts complaining in system.log with:Service only ran for 5 seconds. Pushing respawn out by 5 seconds.Service only ran for 7 seconds. Pushing respawn out by 3 seconds.And sure enough launching and getting an answer from the launchd daemon is delayed at some point.Question:Is there a key to put in the launcdh plist file or a function to call from the launchd daemon to explain to launchd that this is the expected behavior for the daemon and that it should not delayed its next launch?I've checked the launchd.plist man page but have not found anything enlightening so far.

I'm trying to figure out whether it's possible to authenticate a user as an admin using Touch ID on macOS. And Using _public_ APIs (*)Basically, what I'm trying to achieve is:1. User clicks on a button to perform a task that can only performed by a user who is allowed to administer the computer.2. A standard security authentication dialog appears and allows to authenticate using Touch ID.3. A AuthenticationRef is retrieved.When I look at the Local Authentication API, I see multiple limitations (by design or not):- it lets you prove you are the current user. But it does not check that you are an admin user.- the dialog does not work as the one in Installer.app for instance: . if you move the authentication dialog to a screen corner and then click the User Password… button, the Password window is displayed on the center of the screen.- it does not seem possible to retrieve a AuthorizationRef.QuestionAre there public API or services that allows to check for admin privileges which support Touch ID?* I know it's possible using private frameworks since this for instance what the Startup Disk preference pane does.

Setup:- MacBook (macOS 10.14.6) closed but running.- Other Mac (macOS 10.14.6) using Screen Sharing.app to remotely control the MacBook.Problem:NSUserNotification(s) banners are not displayed in the Screen Sharing.app. Yet, they are said to have been delivered and they are listed in the Notifications sidebar.If the MacBook is opened, then the NSUserNotification(s) are visible on both the real MacBook display and in the Screen Sharing.app window on the other Mac.Question:Is this a known bug?I haven't seen an obvious options in the Notifications System Preferences pane that would solve this (Do Not Disturb "When mirroring to TV…" option has no effect).

When you have a launchd daemon that can be triggered by XPC messages, it could be possible to check whether the daemon is doing something using XPCs.The issue is that this would start the daemon.Question:Is there a "launchd" way to know whether a daemon is running? That does not involve starting the daemon.By "launchd" way, I mean a solution which is not basically checking the entire list of running processes and figuring out whethere the daemon is there somewhere.Already quickly checked:- SystemManagement APIs: they are considered obsolete and do not allow this as far as I can tell.- launch.h: it's considered obsolete and is not well documented and does not look like to allow this.Maybe it's possible to achieve this via the NSXPC APIs but I have not found an obvious solution yet.

"In macOS 10.15.4, use of deprecated KPIs triggers a notification to the user that the software includes a deprecated API and asks the user to contact the developer for alternatives."This seems strange and somehow inappropriate to display this kind of notifications in a minor OS release. Even more considering that the SDKs for the "alternatives" have not been properly documented so far.If Apple knows in which OS release the KPIs will stop working, please communicate this piece of information to the 3rd party developers. That would be more helpful to everyone.If we could avoid another macOS UX disaster as the ones with SKEL and FDA, this would be welcome.

Fact:According to the documentation, the notarization process is basically just a way to provide an artifact to Apple so that it can be verified. Any developer account can submit an artifact produced by someone else.Question:Is it not totally absurd that the notarization server refuses to process an artifact when the "Paid Applications Schedule" has been modified by Apple and not accepted yet by the account requesting the notarization?Because :- notarizing an artifact does not imply it will be distributed or sold through the Mac App Store or App Store. So which connection is there supposed to be with the Paid Applications Schedule?- anyone else could notarize the artifact.

The notarization process is failing today by reporting errors for requisites that should only report a warning till the 3rd of February.So are we already the 3rd of February or is there an issue on the notarization server side?e.g.{ "severity": "error", "code": null, "path": "Notarization_Archive.zip/Notarization_Archive/xxxxxxx/something", "message": "The executable does not have the hardened runtime enabled.", "docUrl": null, "architecture": "x86_64h" },

I've been observing an annoying phenomenom with NSUserNotificationCenter/NSUserNotification.I have 2 processes:- procD: a launchd daemon launched at startup- procA: a launchd agent launched at login. procA can also be launched by procD using a watch path.. procD communicates through XPC with procA using an anonymousListener endpoint provided by procA.. procD can send a message (MSG) to procA through XPC. The message in procA delivers a NSUserNotification.What I've been observing:Case that works:procD is running.procA is running and has been launched automatically after login.1. procD sends MSG to procA. procA receives the message, uses the NSUserNotification API to deliver a user notification: it works fine.Step 1 can be repeated again and again and it works fine in every single case.Case that does not work:procD is running.procA is running and has been launched automatically after login.1. procA is killed (via Activity Monitor for instance).2. procD triggers the launch of procA using the watch path => procA is launched.3. procD sends MSG to procA. procA receives the message, uses the NSUserNotification API to deliver a user notification=> the user notification does not appear. It i reported as delivered to the NSUserNotificationCenter delegate. Uh?!4. procD sends MSG to procA. procA receives the message, uses the NSUserNotification API to deliver a user notification=> the notification does appear.It's as if delivering a user notification following a kill of the process is not working. I have added a NSBeep() before delivering the notification and it's played. So the issue really is with the user notification code and not the messaging code.Workaround that I've found so far:I call [[NSUserNotificationCenter defaultUserNotificationCenter] removeAllDeliveredNotifications] in the + (void)initialize method of the class I use to call the NSUserNotification API and deliver the notifications.Doing this enables the first user notification to be displayed as it should.Question:Could it be that there is a bug in the NSUserNotificationCenter/NSUserNotification API/server where some cached data remains after a process has been killed?I've read that these APIs are deprecated but they are the only ones that work on macOS < 10.14 which is still supported here.macOS 10.14.6 / Objective-C code

Starting probably with macOS Catalina, .panic files are illegible for impatient human eyes in a basic text editor because the files is formatted in some kind of json format (with no CRs).So how are we supposed to read .panic files?Trying to use Console.app is useless as I'm trying to read a 10.15 .panic file from a 10.14 OS,