I'm writing an application that implements a Bonjour service and browser for the purpose of connecting to Logic Pro and interacting with a MIDI Device Script. Because it's connecting to Logic Pro running on the same system as the application, the service and browser do not need to access anything else on the local network. I'm creating the service and browser with calls like this: err = DNSServiceRegister( &serviceRef, 0, kDNSServiceInterfaceIndexLocalOnly, "MyService", "_osc._udp", "local", nullptr, 52854, txtLen, txtRecord, static_cast<DNSServiceRegisterReply>(myCallback), context ); err = DNSServiceBrowse( &browserRef, 0, kDNSServiceInterfaceIndexLocalOnly, "_osc._udp", nullptr, static_cast<DNSServiceBrowseReply>(browserCallback), context ); Despite the fact that I'm passing in kDNSServiceInterfaceIndexLocalOnly for the network interface, it still triggers an "Allow 'Application' to find devices on local networks?" permissions prompt. How can I avoid that prompt? It is both a significant failure point (in case users don't notice it or click 'Don't Allow' by mistake) but it may also scare them away, since it strongly implies my application is scanning devices on the local network, even though it's doing no such thing!

I'm developing software that implements functionality for third party touch screens. It provides features such as having touch gestures trigger mouse clicks and drags, among other possible actions. One of its features allows keyboard focus to return to whichever app originally had it prior to performing a touch gesture. Previously it worked by recording the current frontmost app when a touch action starts, and then when all touch actions have concluded, calling NSRunningApplication.activateWithOptions and passing NSApplicationActivateIgnoringOtherApps. However, in macOS 14 and later, this no longer works, as NSRunningApplication.activateWithOptions is deprecated. The new API provides a way for the current frontmost app to yield frontmost to whichever app is being activated with the new functions NSRunningApplication.yieldActivationToApplication and NSRunningApplication.activate, but in my case it just silently fails, presumably because my app in that moment is not frontmost. (However there is no error code provided for me to be able to find out what exactly the issue is.) Is there a supported way I can fix this feature in macOS 14 and later?

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.

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.

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 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 &amp; 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 &amp; Privacy &gt; Privacy &gt; Accessibility. Does that also include permission to monitor keystrokes and does that explain why "input monitoring" permission is not required?