I'm developing an app that uses SMAppService to register a launch daemon. I'm running into big troubles with having the daemon start up reliably because, over the course of testing, the location of my app bundle has changed. Various workflows for this app require testing it running from with /Applications, /Applications/Utilities, or in the project's build directories, which includes both debug and release builds. And I need to account for users moving the app bundle around. The trouble is that the launch daemon seems to want to launch from the first path it was registered, not at the path it was last registered. For example, if my app originally registered it while located in /Applications/MyApp.app, then the launch daemon will only run from within an app bundle at that specific location, even if there is no app bundle at that path. As per advice on these forums, I've tried accounting for this by unregistering the daemon, waiting two seconds, and then re-registering it. But in practice this isn't working. I can use sfltool dumbtm and see that the app is still registered in /Applications/MyApp.app and not its new location, and the launch daemon simply silently fails to launch -- SMAppService returns no error. sudo launchctl list displays the job as having status 78. If I set up a stdout/stderr redireciton in its job file, the files are empty. (I'm aware that I can use sfltool resetbtm to completely reset all login items and background tasks and temporarily fix this issue at least on my own system, but I can hardly have my app use that as part of its standard installation procedure. I need some way of dealing with this that doesn't requiring reseting the state of every app that has a background item.) I'm starting to pull my hair out dealing with this! (Figuratively, mind you. Not literally, at least not yet.) How can I get this to work? This API is starting to seem like a downgrade from placing a plist file in /Library/LaunchDaemons because at least that was able to work very reliably.

I'm developing an Accessibility-enabled app that includes a helper app registered as a launch daemon using SMAppService. This daemon will connect to HID which requires both being root as well as having Accessibility (or Input Monitoring) permissions. I want this app to have as little friction for the user as I can manage. One friction I'd like to avoid is requiring the user to grant more than one application permission to use Accessibility features. So I'm wondering if I can set up the launch daemon so that it inherits the TCC permissions of its parent bundle. I'll note that the one way I've found that works is to not have the helper app have its own app bundle, but rather just have it be an executable placed alongside the main executable in enclosing bundle's Contents/MacOS directory. This has the disadvantage though of having the helper process and main process have the same name in Activity Monitor, which I think will be confusing to users. So in short, is there a supported way for a bundled application with its own CFBundleName / CFBundleDisplayName key to run as a launch daemon and also inherit Accessibility permissions from its parent app bundle?

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.