I have an app that includes a DriverKit extension that up until now I've been building without issue using Xcode 13. It was time to regenerate my Developer ID Application certificate so I needed to rebuild the app. However, I'm now running macOS Ventura and Xcode 14.3.1, and cannot get it to build in this later version of Xcode for reasons that are totally inscrutable to me. I've tried using both the newly generated provisioning profiles I've manually created in the "Certificates, Identifiers & Profiles" developer page, and the (still valid) provisioning profiles I already had installed. The trouble is that, when I select a provisioning profile I made for the DriverKit extension, Xcode won't accept it for the following reason: Platform: macOS Doesn't match platform DriverKit This makes no sense to me! There is no way to create a distribution provisioning profile for the "DriverKit" platform. All I can select is either "Mac" or "Mac Catalyst". So there's seemingly no way out of this. What am I missing?

I just noticed that NSCursor.currentSystemCursor is deprecated starting in macOS 15. What method should I now use to get information about the current system cursor, including its image?

My company is distributing a DriverKit System Extension as part of our software. As of recently (perhaps around a month or two ago -- I'm not sure on the exact timing), activating the System Extension only triggered one prompt to the user: the standard "System Extension Blocked" message that includes an option to open Security settings and allow the System Extension. Now however for some reason there is suddenly a second prompt that comes before: a dialog opens with a message saying that my application is trying to "modify" a System Extension, and it asks for an admin username and password. Then once that's supplied, they get the other prompt requiring them to go into System Settings. (This new prompt is in fact the same one that appears when trying to deactivate the System Extension.) At first I thought this was a new aspect of macOS Sonoma, but then I discovered that this prompt now appears in macOS Ventura and Monterey as well. Why is this prompt now appearing when it wasn't there before? Did this come about as a result of a system update to Ventura and Monterey? And more to the point, why is it there at all? Is this a bug, or is there otherwise anyway to avoid it? The user already has to enter their username and password to activate the System Extension. Why is there an additional prompt creating even more friction for this process? (Note that System Extension activation accounts for a sizeable portion of my company's macOS support requests, due to users not understanding what's going on or misunderstanding the steps necessary for activation. More friction to this process means more headaches for us!)

I'm trying to write a MIDI device script (MDS) for Logic Pro, as is (briefly) discussed here: https://support.apple.com/en-kg/guide/logicpro/ctls718dd5b2/mac I can see other such scripts bundled with Logic and that they're written in Lua. However, I cannot find any documentation this anywhere. Could someone kindly point me towards any documentation that might help me?

I manage a system that automatically generates system extensions, and in order to ensure that every release's dext can be activated over top of any other release, I have it increment the dext's CFBundleVersion so that every release has a unique version number. However I just hit an error where, once CFBundleVersion reached 10000, dext activation would fail with this error: Property "CFBundleVersion" must be a valid kext version Apparently the maximum value any one of the three digits can be for CFBundleVersion is 9999, at least for a dext. So if CFBundleVersion only uses one number as opposed to three, it can't go higher than 9999. Note that I found this out from experimentation. No where in Apple's documentation have I found any mention of this restriction, including, most distressingly, in the docs for CFBundleVersion. Since I'm programmatically assigning this value, now I need to know: Are there any other requirements or restrictions for CFBundleVersion? I'm curious if there are any in the context of an app (be it on macOS, iOS, tvOS, and so on) or other types of extensions, as well as with a DriverKit extension.

Back on December 11 I submitted a TSI to Apple on behalf of my company. I got a response from an engineer on December 14 and then sent off another reply on December 15. Since then, I have not gotten any response from Apple, and I'm starting to get worried that I've fallen out of the system somehow. The TSI is about an issue that's causing trouble for a lot of my company's users, so we were hoping to get it resolved ASAP. I resent my last reply on Dec 28. Both of my replies, from Dec 15 and Dec 28, have not generated the usual automated acknowledgement email from developer technical support that they usually do. I have confirmed that my email address is still able to receive email, and that no emails from Apple have been erroneously flagged as spam. Is anyone else having trouble getting a reply from Apple? I know it's the holidays and figured responses may be slower than normal, but I figured I should at least get an automated response to let me know my reply is in the system.

My company provides a driver that utilizes a codeless kext to prevent the system IOHID driver from taking over any device we support. However, after uninstalling our software, we'd like for the system driver to take over the device again. In previous versions of macOS, after uninstalling our kext, re-enumerating the device would get it to load the default system driver. However in Big Sur that is not working any longer, and the system doesn't take control of the device until after the system has been rebooted. Is there any way to get this to happen without requiring a reboot in Big Sur?

On Apple's documentation page "Installing a Custom Kernel Extension" - https://developer.apple.com/documentation/kernel/installing_a_custom_kernel_extension, which has been updated to include information for macOS 11, it includes the following: For codeless kexts, the system asks the user for permission to install the kext, but doesn’t reboot the user’s system. My company has been using a codeless kext for many years, and installing it on Big Sur requires the user to reboot, contradicting this claim. Is it possible we're building our codeless kext incorrectly? (The source code for the kext is literally an empty file, though the resulting kext does contain an executable under Contents/MacOS.) Or is this documentation page simply wrong?

My company's software relies on a codeless kext in order to prevent a macOS built-in driver from taking control of hardware. We automatically generate numerous kexts for many different hardware configurations. Earlier kernel extensions we've built and notarized still load fine in macOS 10.15.6, though of course the first time requires the user to allow the kext to load in the Security & Privacy pref pane. Now the most recent driver I've built and notarized produces this message: "System Extension Blocked A program tried to load a new system extension(s) signed by "XYZ" that need to be updated by the developer." Now there is no option to load the kext! Why are some kexts able to load in 10.15.6 and not others? Is there some restriction on how recently a kext can be signed or notarized and still be allowed to load?

I've just built an app, signed it with my Developer ID certificate, and had it successfully notarized. However, when I download a zipped copy of the app in macOS 10.15.5 and try to run it, I get the "“XYZ” can’t be opened because Apple cannot check it for malicious software" error message. The same zip file works fine in 10.14.6 and earlier.All of the usual checks to make sure the app is signed and notarized properly report that it is:% codesign --verbose --verify XYZ.app XYZ.app: valid on disk XYZ.app: satisfies its Designated Requirement % xcrun stapler validate XYZ.app Processing: /path/to/XYZ.app The validate action worked! % spctl --assess --verbose XYZ.app XYZ.app: accepted source=Notarized Developer IDPrevious versions of the app had no issue with notarization. I haven't changed anything significant in the app since its last release, aside from a few bugfixes, nor have I changed the method I use to sign or notarize it.What's going wrong? I've had so many headaches due to the new notarization requirement, so I'm quite dismayed I've run into another one. And due to the black-box nature of notarizing there's no way for me to figure out what's going wrong other than to ask here!

I'm trying to build and activate a simple USBDriverKit system extension. I have not yet requested the entitlements I need from Apple, and so I'm trying to do so on a local system that has SIP disabled.I'm pulling my hair out trying to get this thing to build and activate!According to the documentation and threads I've read here, when SIP is disabled then macOS won't verify the app's signature is valid and so it'll let me use the entitlements I need in my system extension (`com.apple.developer.driverkit` and `com.apple.developer.driverkit.transport.usb`). But I can't actually build the app with those entitlements because Xcode will complain that I need a provisioning profile that includes them, and I'm not allowed to create one. There doesn't seem to be any option for codesigning the app with the entitlements I need without a provisioning profile, and thus I'm stuck.What am I supposed to do in this situation?

I'm working on a software project that requires me to frequently make notarized releases, as many as five in one day, possibly even more. Prior to today it wasn't a big time sink as notarizing generally took a couple of minutes. The last several requests to Apple's notary though have taken 30 minutes to complete, and the entire time I twiddling my thumbs waiting for it to finish before I can continue my work.Can anyone at Apple speak to the wait times for getting software notarized and whether or not Apple intends to dedicate resources to keeping it short?Is this perhaps the result of many developers using the notary service all at once due to the recent release of Catalina?

I'm working on an application that monitors keystrokes using an event tap. Under macOS 10.15 I thought that required the user to grant my app that permission specifically in the Security & Privacy preference pane, under Privacy / Input Monitoring.However, no apps are listed in that section, and yet my app can successfully create an event tap that listens for events of type kCGEventKeyDown for the entire system. Why is this? I'm quite confused what the actual security requirements are, and searching through Apple's documentation has provided no help at all.This application does already have permission to use accessibility features in Security & Privacy > Privacy > Accessibility. Does that also include permission to monitor keystrokes and does that explain why "input monitoring" permission is not required?

In Catalina beta 6, I'm unable to find an option for switching to Mail's classic layout. Has this been removed from Mail in Catalina?It's still mentioned in the "Mail User Guide" accessible from the Help menu. If it is removed, then any reference to it in Mail's documentation should be removed as well.That said, I very much hope it's not actually removed. I very much prefer the classic layout over the standard one, and might opt to switch to another mail clients if it's removed.

Does anyone know whether the functions defined in AXUIElement.h are thread safe or reentrant?I've been working with them for years, and I still haven't been able to figure out in what contexts it's safe to call these functions. In the past I've had issues with calling them from threads other than an application's main thread, so to play it safe I try to keep my Accessibility functionality constrained to my app's main thread.But sometimes the functions are slow and block the app's user interface, so it's becoming increasingly untenable for me not to use them in a separate thread.The documentation and header file give no indication whatsoever.Any help with this would be much appreciated!