Following up with a related second scenario that's part of the same investigation. Scenario 2: Multiple installations of the same app on disk Setup: the same bundle identifier installed at more than one path on the same Mac, for example one copy installed via a DMG at /Applications/App.app, and a separate copy installed via the Mac App Store, or a locally built development version at a different path. We understand Launch Services treats these as the same app for identification purposes, and that duplicate registrations are a known, accepted characteristic of Launch Services rather than something the system actively prevents. Questions: When a push or local notification arrives for that shared bundle identifier and the user taps it, which installation actually gets launched or brought to the foreground? Is the resolution based on something like most recently registered path, highest CFBundleVersion, most recently launched, or something else in Launch Services? Is this resolution behavior documented anywhere, or should developers actively avoid this situation entirely, for example by using distinct bundle identifiers per distribution channel, the way some developers already do for App Store versus development builds?

Following up with some additional findings that narrow this down further. Wanted to note upfront: I've since replaced the deprecated application(:didReceiveRemoteNotification:) approach and tested using UNUserNotificationCenterDelegate's userNotificationCenter(:didReceive:withCompletionHandler:) and userNotificationCenter(_:willPresent:withCompletionHandler:) as the primary handlers - same underlying issue persists, so this isn't a deprecated-API artifact. The more significant finding: Notification Service Extension and Notification Content Extension are not being invoked at all for remote pushes on macOS in our testing. Sent a payload with mutable-content: 1 (to trigger NSE) and a separate payload with a category matching a registered NCE (both extensions properly configured — targets build/sign cleanly, Info.plist extension points correct) Confirmed the App ID in use has the correct platform selected (including macOS) and Push Notifications capability enabled — ruling out App ID configuration as a factor APNs returns HTTP/2 200 for both payloads Checked Console.app filtered by both extension process names — no log output whatsoever from either extension, not even our own NSLog calls placed at the very start of didReceive(:withContentHandler:) / didReceive(:) System-level usernoted logs confirm the notification is registered into the notification database and then removed, without ever being displayed or invoking either extension Testing on macOS 26.5 (25F71) / Xcode 26.2 (17C52). Any guidance on what else could prevent these extensions from being invoked, given the network layer clearly accepts and delivers the payload, would be appreciated.

After a while when i ran the xcode project again without making any changes , application worked fine , agent was getting registered/running , i was getting logs for agent in console.app. Tried it multiple time and it was working whole day. But today again ran application from xcode , i started getting same error . Registering Agent. Status: 3 Failed to register agent: Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} What possibly could be the reason for such behavior?

Thanks for your response @DTS Engineer In my app , i dont want to show any UI to user because user will be using this app just to do some background task like importing some data etc. So that our primary application which will be a different bundle can use that data which it may need during its launch (because of some reason it cann't get it using primary application itself). (This use can is just a example to explain what experience we want to give to user.) In this application, we wanted to have user experience , where user can double click on app icon and launch it . And then application will do its work and close . Since we have to give double click experience to user, we need to use a bundle application. We were using UIApplicationMain which will start a NSRunLoop to block main thread , until we finish our work on worker thread. And we were able to achive our objective using this approach. But since we dont have to show any UI to user , we were thinking can we use CFRunLoop to block main thread. We need a event loop (blocking main thread is just one example, we may also need to listen to some events etc on event loop)

I want to discover printers on worker thread . My end goal it to do print operation explicitly on worker thread. In UIkit, UIPrintInteractionController can send the printing job to printer in two ways: , Presenting the printing user interface(using present() func , which can work only with main thread) Printing directly to a printer(using print() func , in which we can pass UIPrinter() object containing information about the printer and it can work with worker thread). Using UIPrinterPickerController , which works on main thread , i can get list of printer . And then do the printing to that printer using method to of UIPrintInteractionController's method 2 of printing from worker thread . But i want whole printing to be done on worker thread. By using cups i want to discover the printers using worker thread , so that whole print operation in my application can happen on worker thread.