I'm looking into a newer XPC API available starting with macOS 14. Although it's declared as a low-level API I can't figure it how to specify code signing requirement using XPCListener and XPCSession. How do I connect it with xpc_listener_set_peer_code_signing_requirement and xpc_connection_set_peer_code_signing_requirement which require xpc_listener_t and xpc_connection_t respectively? Foundation XPC is declared as a high-level API and provides easy ways to specify code signing requirements on both ends of xpc. I'm confused with all these XPC APIs and their future: Newer really high-level XPCListener and XPCSession API (in low-level framework???) Low-level xpc_listener_t & xpc_connection_t -like API. Is it being replaced by newer XPCListener and XPCSession? How is it related to High-level Foundation XPC? Are NSXPCListener and NSXPCConnection going to be deprecated and replaced by XPCListener and XPCSession??

I need to check how long we can run an app in background which act as a consumer of data / control filter. What is the max time we get to run our app in background without any of these app strategies? https://developer.apple.com/documentation/backgroundtasks/choosing-background-strategies-for-your-app

I am encountering an issue when making an API call using URLSession with DispatchQueue.global(qos: .background).async on a real device running tvOS 18. The code works as expected on tvOS 17 and in the simulator for tvOS 18, but when I remove the debug mode, After the API call it takes few mintues or 5 to 10 min to load the data on the real device. Code: Here’s the code I am using for the API call: appconfig.getFeedURLData(feedUrl: feedUrl, timeOut: kRequestTimeOut, apiMethod: ApiMethod.POST.rawValue) { (result) in self.EpisodeItems = Utilities.sharedInstance.getEpisodeArray(data: result) } func getFeedURLData(feedUrl: String, timeOut: Int, apiMethod: String, completion: @escaping (_ result: Data?) -> ()) { guard let validUrl = URL(string: feedUrl) else { return } var request = URLRequest(url: validUrl, cachePolicy: .useProtocolCachePolicy, timeoutInterval: TimeInterval(timeOut)) let userPasswordString = "\(KappSecret):\(KappPassword)" let userPasswordData = userPasswordString.data(using: .utf8) let base64EncodedCredential = userPasswordData!.base64EncodedString(options: .lineLength64Characters) let authString = "Basic \(base64EncodedCredential)" let headers = [ "authorization": authString, "cache-control": "no-cache", "user-agent": "TN-CTV-\(kPlateForm)-\(kAppVersion)" ] request.addValue("application/json", forHTTPHeaderField: "Content-Type") request.httpMethod = apiMethod request.allHTTPHeaderFields = headers let response = URLSession.requestSynchronousData(request as URLRequest) if response.1 != nil { do { guard let parsedData = try JSONSerialization.jsonObject(with: response.1!, options: .mutableContainers) as? AnyObject else { print("Error parsing data") completion(nil) return } print(parsedData) completion(response.1) return } catch let error { print("Error: \(error.localizedDescription)") completion(response.1) return } } completion(response.1) } import Foundation public extension URLSession { public static func requestSynchronousData(_ request: URLRequest) -> (URLResponse?, Data?) { var data: Data? = nil var responseData: URLResponse? = nil let semaphore = DispatchSemaphore(value: 0) let task = URLSession.shared.dataTask(with: request) { taskData, response, error in data = taskData responseData = response if data == nil, let error = error { print(error) } semaphore.signal() } task.resume() _ = semaphore.wait(timeout: .distantFuture) return (responseData, data) } public static func requestSynchronousDataWithURLString(_ requestString: String) -> (URLResponse?, Data?) { guard let url = URL(string: requestString.checkValidUrl()) else { return (nil, nil) } let request = URLRequest(url: url) return URLSession.requestSynchronousData(request) } } Issue Description: Working scenario: The API call works fine on tvOS 17 and in the simulator for tvOS 18. Problem: When running on a real device with tvOS 18, the API call takes time[enter image description here] when debug mode is disabled, but works fine when debug mode is enabled, Data is loading after few minutes. Error message: Error Domain=WKErrorDomain Code=11 "Timed out while loading attributed string content" UserInfo={NSLocalizedDescription=Timed out while loading attributed string content} NSURLConnection finished with error - code -1001 nw_read_request_report [C4] Receive failed with error "Socket is not connected" Snapshot request 0x30089b3c0 complete with error: <NSError: 0x3009373f0; domain: BSActionErrorDomain; code: 1 ("response-not-possible")> tcp_input [C7.1.1.1:3] flags=[R] seq=817957096, ack=0, win=0 state=CLOSE_WAIT rcv_nxt=817957096, snd_una=275546887 Environment: Xcode version: 16.1 Real device: Model A1625 (32GB) tvOS version: 18.1 Debugging steps I’ve taken: I’ve verified that the issue does not occur in debug mode. I’ve confirmed that the API call works fine on tvOS 17 and in the simulator (tvOS 18). The error suggests a network timeout (-1001) and a socket connection issue ("Socket is not connected"). Questions: Is this a known issue with tvOS 18 on real devices? Are there any specific settings or configurations in tvOS 18 that could be causing the timeout error in non-debug mode? Could this be related to how URLSession or networking behaves differently in release mode? I would appreciate any help or insights into this issue!

Hi, we are in the process of exploring how to create an installer for our array of apps. We have come to the conclusion that regular .pkg installers produced by pkgbuild and productbuild are unfulfilling of our expectations. [1] Regardless, our installer needs to place files at privileged locations (/Library/Application Support) so we are looking into how to best solve this problem, with the user having the largest clarity on what they are about to do (so no shady "wants to make changes" dialogs) the least steps to do to install these files in the right place (so no targeted NSSavePanel-s) Now, we have done our light reading via some nicely collected posts on the topic (https://forums.developer.apple.com/forums/thread/708765 for example) and the single missing option in the list of privilege escalation models seems to be a one-time privilege escalation from a GUI app. Our reasons for declaring so: AuthorizationExecuteWithPrivileges is long deprecated and we are trying to build a futureproof solution NSAppleScript is just putting up a shady ("wants to make changes") dialog when trying something like this: $ osascript -e "set filePath to \"/Library/Application Support\"" -e "do shell script \"touch \" & the quoted form of filePath & \"/yyy.txt\" with administrator privileges" Is there another way to request a one-time authorization from the admin to perform such a simple operation as copying a file to a protected location? I know it's possible to externalize and internalize Authorization Rights, but they are just an interface to create extra rights and use them as barriers, because they don't actually pass the required right to further operations based on this documentation. Using SMAppService to register a daemon, which has to be manually allowed by the user adds a lot to the complexity of this installation process, and is something we would like to avoid if possible. (And it's also not the right security model if we want to be honest - we don't want ongoing administrator rights and a daemon) Is there something we haven't taken into consideration? [1] preinstall scripts run after the choices are presented during installation and we would need advanced logic (not the limited JavaScript system/files API provided by Installer JS) - plus, the GUI is obviously very limited in a .pkg :(

This week I’m handling a DTS incident from a developer who wants to escalate privileges in their app. This is a tricky problem. Over the years I’ve explained aspects of this both here on DevForums and in numerous DTS incidents. Rather than do that again, I figured I’d collect my thoughts into one place and share them here. If you have questions or comments, please start a new thread with an appropriate tag (Service Management or XPC are the most likely candidates here) in the App & System Services > Core OS topic area. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" BSD Privilege Escalation on macOS macOS has multiple privilege models. Some of these were inherited from its ancestor platforms. For example, Mach messages has a capability-based privilege model. Others were introduced by Apple to address specific user scenarios. For example, macOS 10.14 and later have mandatory access control (MAC), as discussed in On File System Permissions. One of the most important privilege models is the one inherited from BSD. This is the classic users and groups model. Many subsystems within macOS, especially those with a BSD heritage, use this model. For example, a packet tracing tool must open a BPF device, /dev/bpf*, and that requires root privileges. Specifically, the process that calls open must have an effective user ID of 0, that is, the root user. That process is said to be running as root, and escalating BSD privileges is the act of getting code to run as root. IMPORTANT Escalating privileges does not bypass all privilege restrictions. For example, MAC applies to all processes, including those running as root. Indeed, running as root can make things harder because TCC will not display UI when a launchd daemon trips over a MAC restriction. Escalating privileges on macOS is not straightforward. There are many different ways to do this, each with its own pros and cons. The best approach depends on your specific circumstances. Note If you find operations where a root privilege restriction doesn’t make sense, feel free to file a bug requesting that it be lifted. This is not without precedent. For example, in macOS 10.2 (yes, back in 2002!) we made it possible to implement ICMP (ping) without root privileges. And in macOS 10.14 we removed the restriction on binding to low-number ports (r. 17427890). Nice! Decide on One-Shot vs Ongoing Privileges To start, decide whether you want one-shot or ongoing privileges. For one-shot privileges, the user authorises the operation, you perform it, and that’s that. For example, if you’re creating an un-installer for your product, one-shot privileges make sense because, once it’s done, your code is no longer present on the user’s system. In contrast, for ongoing privileges the user authorises the installation of a launchd daemon. This code always runs as root and thus can perform privileged operations at any time. Folks often ask for one-shot privileges but really need ongoing privileges. A classic example of this is a custom installer. In many cases installation isn’t a one-shot operation. Rather, the installer includes a software update mechanism that needs ongoing privileges. If that’s the case, there’s no point dealing with one-shot privileges at all. Just get ongoing privileges and treat your initial operation as a special case within that. Keep in mind that you can convert one-shot privileges to ongoing privileges by installing a launchd daemon. Just Because You Can, Doesn’t Mean You Should Ongoing privileges represent an obvious security risk. Your daemon can perform an operation, but how does it know whether it should perform that operation? There are two common ways to authorise operations: Authorise the user Authorise the client To authorise the user, use Authorization Services. For a specific example of this, look at the EvenBetterAuthorizationSample sample code. Note This sample hasn’t been updated in a while (sorry!) and it’s ironic that one of the things it demonstrates, opening a low-number port, no longer requires root privileges. However, the core concepts demonstrated by the sample are still valid. The packet trace example from above is a situation where authorising the user with Authorization Services makes perfect sense. By default you might want your privileged helper tool to allow any user to run a packet trace. However, your code might be running on a Mac in a managed environment, where the site admin wants to restrict this to just admin users, or just a specific group of users. A custom authorisation right gives the site admin the flexibility to configure authorisation exactly as they want. Authorising the client is a relatively new idea. It assumes that some process is using XPC to request that the daemon perform a privileged operation. In that case, the daemon can use XPC facilities to ensure that only certain processes can make such a request. Doing this securely is a challenge. For specific API advice, see this post. WARNING This authorisation is based on the code signature of the process’s main executable. If the process loads plug-ins [1], the daemon can’t tell the difference between a request coming from the main executable and a request coming from a plug-in. [1] I’m talking in-process plug-ins here. Plug-ins that run in their own process, such as those managed by ExtensionKit, aren’t a concern. Choose an Approach There are (at least) seven different ways to run with root privileges on macOS: A setuid-root executable The sudo command AppleScript’s do shell script command, passing true to the administrator privileges parameter The AuthorizationExecuteWithPrivileges routine, deprecated since macOS 10.7 The SMJobSubmit routine targeting the kSMDomainSystemLaunchd domain, deprecated since macOS 10.10 The SMJobBless routine, deprecated since macOS 13 An installer package (.pkg) The SMAppService class, a much-needed enhancement to the Service Management framework introduced in macOS 13 Note There’s one additional approach: The privileged file operation feature in NSWorkspace. I’ve not listed it here because it doesn’t let you run arbitrary code with root privileges. It does, however, have one critical benefit: It’s supported in sandboxed apps. See this post for a bunch of hints and tips. To choose between them: Do not use a setuid-root executable. Ever. It’s that simple! Doing that is creating a security vulnerability looking for an attacker to exploit it. If you’re working interactively on the command line, use sudo. IMPORTANT sudo is not appropriate to use as an API. While it may be possible to make this work under some circumstances, by the time you’re done you’ll have code that’s way more complicated than the alternatives. If you’re building an ad hoc solution to distribute to a limited audience, and you need one-shot privileges, use either AuthorizationExecuteWithPrivileges or AppleScript. While AuthorizationExecuteWithPrivileges still works, it’s been deprecated for many years. Do not use it in a widely distributed product. The AppleScript approach works great from AppleScript, but you can also use it from native code using NSAppleScript. See the code snippet later in this post. If you need one-shot privileges in a widely distributed product, consider using SMJobSubmit. While this is officially deprecated, it’s used by the very popular Sparkle update framework, and thus it’s unlikely to break without warning. If you only need escalated privileges to install your product, consider using an installer package. That’s by far the easiest solution to this problem. Keep in mind that an installer package can install a launchd daemon and thereby gain ongoing privileges. If you need ongoing privileges but don’t want to ship an installer package, use SMAppService. If you need to deploy to older systems, use SMJobBless. For instructions on using SMAppService, see Updating helper executables from earlier versions of macOS. For a comprehensive example of how to use SMJobBless, see the EvenBetterAuthorizationSample sample code. For the simplest possible example, see the SMJobBless sample code. That has a Python script to help you debug your setup. Unfortunately this hasn’t been updated in a while; see this thread for more. Hints and Tips I’m sure I’ll think of more of these as time goes by but, for the moment, let’s start with the big one… Do not run GUI code as root. In some cases you can make this work but it’s not supported. Moreover, it’s not safe. The GUI frameworks are huge, and thus have a huge attack surface. If you run GUI code as root, you are opening yourself up to security vulnerabilities. Appendix: Running an AppleScript from Native Code Below is an example of running a shell script with elevated privileges using NSAppleScript. WARNING This is not meant to be the final word in privilege escalation. Before using this, work through the steps above to see if it’s the right option for you. Hint It probably isn’t! let url: URL = … file URL for the script to execute … let script = NSAppleScript(source: """ on open (filePath) if class of filePath is not text then error "Expected a single file path argument." end if set shellScript to "exec " & quoted form of filePath do shell script shellScript with administrator privileges end open """)! // Create the Apple event. let event = NSAppleEventDescriptor( eventClass: AEEventClass(kCoreEventClass), eventID: AEEventID(kAEOpenDocuments), targetDescriptor: nil, returnID: AEReturnID(kAutoGenerateReturnID), transactionID: AETransactionID(kAnyTransactionID) ) // Set up the direct object parameter to be a single string holding the // path to our script. let parameters = NSAppleEventDescriptor(string: url.path) event.setDescriptor(parameters, forKeyword: AEKeyword(keyDirectObject)) // The `as NSAppleEventDescriptor?` is required due to a bug in the // nullability annotation on this method’s result (r. 38702068). var error: NSDictionary? = nil guard let result = script.executeAppleEvent(event, error: &error) as NSAppleEventDescriptor? else { let code = (error?[NSAppleScript.errorNumber] as? Int) ?? 1 let message = (error?[NSAppleScript.errorMessage] as? String) ?? "-" throw NSError(domain: "ShellScript", code: code, userInfo: nil) } let scriptResult = result.stringValue ?? "" Revision History 2024-11-15 Added info about SMJobSubmit. Made other minor editorial changes. 2024-07-29 Added a reference to the NSWorkspace privileged file operation feature. Made other minor editorial changes. 2022-06-22 First posted.

I have a process [command line cpp application] which i want to run always such as it should relaunch after a crash, after device startup etc. I created a launchd Property List File with KeepAlive true and placed under /Library/LaunchDaemons. Problem Statements: I have a bash script to start and stop this process. start using: launchctl bootstrap. stop involve these two steps: send SIGTERM signal and wait untill process stops after doing some cleanups launchctl bootout [It doesn't sends SIGTERM] during steps 1 - Process is getting stop, but also getting immediate relaunch by launchctl during step 2 - it getting stop again. is there a proper way so that we can disable KeepAlive temporarily so that process will not launch during step 1? or suggest other ways to handle this?

Hello everyone! I'm having a problem with background tasks running in the foreground. When a user enters the app, a background task is triggered. I've written some code to check if the app is in the foreground and to prevent the task from running, but it doesn't always work. Sometimes the task runs in the background as expected, but other times it runs in the foreground, as I mentioned earlier. Could it be that I'm doing something wrong? Any suggestions would be appreciated. here is code: class BackgroundTaskService { @Environment(\.scenePhase) var scenePhase static let shared = BackgroundTaskService() private init() {} // MARK: - create task func createCheckTask() { let identifier = TaskIdentifier.check BGTaskScheduler.shared.getPendingTaskRequests { requests in if requests.contains(where: { $0.identifier == identifier.rawValue }) { return } self.createByInterval(identifier: identifier.rawValue, interval: identifier.interval) } } private func createByInterval(identifier: String, interval: TimeInterval) { let request = BGProcessingTaskRequest(identifier: identifier) request.earliestBeginDate = Date(timeIntervalSinceNow: interval) scheduleTask(request: request) } // MARK: submit task private func scheduleTask(request: BGProcessingTaskRequest) { do { try BGTaskScheduler.shared.submit(request) } catch { // some actions with error } } // MARK: background actions func checkTask(task: BGProcessingTask) { let today = Calendar.current.startOfDay(for: Date()) let lastExecutionDate = UserDefaults.standard.object(forKey: "lastCheckExecutionDate") as? Date ?? Date.distantPast let notRunnedToday = !Calendar.current.isDate(today, inSameDayAs: lastExecutionDate) guard notRunnedToday else { task.setTaskCompleted(success: true) createCheckTask() return } if scenePhase == .background { TaskActionStore.shared.getAction(for: task.identifier)?() } task.setTaskCompleted(success: true) UserDefaults.standard.set(today, forKey: "lastCheckExecutionDate") createCheckTask() } } And in AppDelegate: BGTaskScheduler.shared.register(forTaskWithIdentifier: "check", using: nil) { task in guard let task = task as? BGProcessingTask else { return } BackgroundTaskService.shared.checkNodeTask(task: task) } BackgroundTaskService.shared.createCheckTask()

Swift Concurrency Resources: DevForums tags: Concurrency The Swift Programming Language > Concurrency documentation Migrating to Swift 6 documentation WWDC 2022 Session 110351 Eliminate data races using Swift Concurrency — This ‘sailing on the sea of concurrency’ talk is a great introduction to the fundamentals. WWDC 2021 Session 10134 Explore structured concurrency in Swift — The table that starts rolling out at around 25:45 is really helpful. Swift Async Algorithms package Swift Concurrency Proposal Index DevForum post Matt Massicotte’s blog Dispatch Resources: DevForums tags: Dispatch Dispatch documentation — Note that the Swift API and C API, while generally aligned, are different in many details. Make sure you select the right language at the top of the page. Dispatch man pages — While the standard Dispatch documentation is good, you can still find some great tidbits in the man pages. See Reading UNIX Manual Pages. Start by reading dispatch in section 3. WWDC 2015 Session 718 Building Responsive and Efficient Apps with GCD [1] WWDC 2017 Session 706 Modernizing Grand Central Dispatch Usage [1] Avoid Dispatch Global Concurrent Queues DevForums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] These videos may or may not be available from Apple. If not, the URL should help you locate other sources of this info.

I was experimenting with Service Management API and Xcode project from https://developer.apple.com/documentation/servicemanagement/updating-your-app-package-installer-to-use-the-new-service-management-api and faced some issues with the API. I replaced agent with XPC service and tried to re-register it. Use case is a new app package installation with a newer service binary. In order to get the running service restarted with the new binary it's required to unregister old version and register new one. Otherwise the old version would be still running after app upgrade. The problem is that register fails with "Operation not permitted" error after running unregister which seems to work fine. Experiments with some delays (500ms) between unregister and register seem to help but it's a not a good solution to work around the problem. I'm using open func unregister() async throws with description: The completion handler will be invoked after the running process has been killed if successful or will be invoked whenever an error occurs. After the completion handler has been invoked it is safe to re-register the service. Sample output with no 500ms sleep between unregister and register calls: /Library/Application\ Support/YourDeveloperName/SMAppServiceSampleCode.app/Contents/MacOS/SMAppServiceSampleCode unregister &amp;&amp; /Library/Application\ Support/YourDeveloperName/SMAppServiceSampleCode.app/Contents/MacOS/SMAppServiceSampleCode register Successfully unregistered LaunchDaemon(com.xpc.example.service.plist) Unable to register LaunchDaemon(com.xpc.example.service.plist): Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} In fact it doesn't seem to be safe to re-register. Any explanation would much appreciated! ===================================================== Side issue #2: I tried to add a similar helper executable as in the original project with register/unregister and put it inside the same app bundle but at a different location like Contents/Helpers/ folder instead of Contents/MacOS. And it always fails with this error: Error Domain=SMAppServiceErrorDomain Code=3 "Codesigning failure loading plist: com.okta.service.osquery code: -67028" UserInfo={NSLocalizedFailureReason=Codesigning failure loading plist: com.okta.service.osquery code: -67028} When I moved the helper binary to Contents/MacOS/ folder along with the main app executable it starts working fine again. Other folders like Resources/XPCServices also don't work. Is it a hard requirement for an executable to be located inside main Contents/MacOS folder in order to be able to call SMAppService register/unregister APIs? I haven't found any documentation regarding this requirement. Thanks, Pavel

Hi, I want to create a custom application launcher, so I'd like the app to be able to just list the apps installed and launch them when touched. My idea is to have a Minimalist UI in order to enhance productivity. Is it possible? I see there is already one App doing it https://apps.apple.com/us/app/dumb-phone/id6504743503 I want to do something similar, so how does the App in the link obtains the Apps installed on the device?

When using conformance to ObservableObject and then doing async work in a Task, you will get a warning courtesy of Combine if you then update an @Published or @State var from anywhere but the main thread. However, if you are using @Observable there is no such warning. Also, Thread.current is unavailable in asynchronous contexts, so says the warning. And I have read that in a sense you simply aren't concerned with what thread an async task is on. So for me, that begs a question. Is the lack of a warning, which when using Combine is rather important as ignoring it could lead to crashes, a pretty major bug that Apple seemingly should have addressed long ago? Or is it just not an issue to update state from another thread, because Xcode is doing that work for us behind the scenes too, just as it manages what thread the async task is running on when we don't specify? I see a lot of posts about this from around the initial release of Async/Await talking about using await MainActor.run {} at the point the state variable is updated, usually also complaining about the lack of a warning. But ow years later there is still no warning and I have to wonder if this is actually a non issue. On some ways similar to the fact that many of the early posts I have seen related to @Observable have examples of an @Observable ViewModel instantiated in the view as an @State variable, but in fact this is not needed as that is addressed behind the scenes for all properties of an @Observable type. At least, that is my understanding now, but I am learning Swift coming from a PowerShell background so I question my understanding a lot.

I updated my computer to Sonoma, and now my LaunchDaemon will not load. I have the following setup : File in /Library/LaunchDaemons/com.startup.plist like this : <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.startup</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/bash</string> <string>/Library/Scripts/Startup/startup.sh</string> </array> <key>RunAtLoad</key> <true/> <key>StandardErrorPath</key> <string>/tmp/com.startup.stderr</string> <key>StandardOutPath</key> <string>/tmp/com.startup.stdout</string> </dict> </plist> File in File in /Library/Scripts/Startup/startup.sh #!/bin/zsh PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users:/Users/root:/Users/root/Scripts:/Library/Scripts:/Library/Scripts/Startup #Load modules for Fuse /Library/Filesystems/macfuse.fs/Contents/Resources/load_macfuse /usr/sbin/sysctl -w vfs.generic.macfuse.tunables.allow_other=1 #Connect to XXXXXX_net /bin/sleep 28 myip=0 while [ $myip = 0 ] do /bin/sleep 3 myip=$(ifconfig -l | xargs -n1 ipconfig getifaddr) done /usr/local/bin/sshfs XXXX@XXXXXX.net: /Volumes/XXXXXX.net -o local,auto_cache,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,ConnectTimeout=5,daemon_timeout=60,iosize=2097152,volname=XXXXXX.net,allow_other,defer_permissions,async_read,Ciphers=aes128-gcm@openssh.com,Cipher=aes128-gcm@openssh.com,compression=no And then we need some commands to be run as root user during boot : /private/etc/sudoers.d/startup-script-nopasswd username ALL = (root) NOPASSWD: /usr/sbin/sysctl username ALL = (root) NOPASSWD: /usr/local/bin/sshfs As of now, I cant even get the /Library/LaunchDaemons/com.startup.plist to run after i updated the macOS to Sonoma ….

I created a macOS app, added an XPC service target, and also added a source editor extension. in The source editor extension‘s perform function. It doesn't work - (void)performCommandWithInvocation:(XCSourceEditorCommandInvocation *)invocation completionHandler:(void (^)(NSError * _Nullable nilOrError))completionHandler { self.xpcConnect = [[NSXPCConnection alloc] initWithServiceName:@"test.TestNewXPCApp.NewXPC"]; NSXPCInterface *interface = [NSXPCInterface interfaceWithProtocol:@protocol(NewXPCProtocol)]; self.xpcConnect.remoteObjectInterface = interface; [self.xpcConnect resume]; [[self.xpcConnect remoteObjectProxy] performCalculationWithNumber:@231 andNumber:@119 withReply:^(NSNumber *reply) { // We have received a response. NSLog(@"ui success%@", reply); }]; But In ViewControler.m, executing the same code , it can work. So why is it possible to connect to the XPC service from within the macOS app, but not from the source editor extension?

I have an application, it has main process and some child processes. As we want those child processes to have their own minimum sandbox privilege, not inheriting from parent process, we plan to use XPCService which uses a NSTask to launch those child processes, so those child processes can have its own sandbox privilege. We plan to deliver the application to Mac App Store, so process mode is: the sandboxed main process builds connections to the unsandboxed XPCService, the unsandboxed XPCService launch those sandboxed child processes. Can this process mode pass the Mac App Store rules? I see, there is a rule that all processes must be sandboxed, including XPCService. But I tested locally, the Application downloaded from Mac apple store also launches unsandboxed XPCService, like OneDrive. Do you have any suggestions for my application scenario, sandboxed child processes having its own privilege not inheriting from parent?

Our application has seen a surge in the volume of background launches starting from April and May, and we want to know under what circumstances the application can be launched from the background. First, here's how I determined background launches: we analyze user logs and append UIApplication.appState to each line of log, finding that every log from the start to the end of user sessions has an appState of UIApplicationStateBackground. By checking the "ActivePrewarm" in main() and printing the launch options from application:didFinishLaunchingWithOptions:, we found several scenarios for background launches: launchOptions has a value with the key UIApplicationLaunchOptionsRemoteNotificationKey. launchOptions has no value and there is no "ActivePrewarm." launchOptions has no value but has "ActivePrewarm." I would like to know: Under what circumstances will notifications trigger a background launch (I cannot replicate this locally)? Under what circumstances does an application launch in the background and trigger application:didFinishLaunchingWithOptions: but without any launch options? I hope informations below can provide some insights. Regarding "ActivePrewarm," I've read various questions and answers in the Apple Developer Forums, such as this thread, which states that "ActivePrewarm" does not trigger application:didFinishLaunchingWithOptions: but occurs due to certain behaviors in the application. I would like to know what behaviors may cause this background launch, as there is no information in the launch options, or how I can identify what behaviors triggered it. Specifically, based on that same thread, I've tried to gather more information using runningboardd, and I've currently identified two special cases: When I restart my phone and unlock it after a short period, there is information: &lt;RBSDomainAttribute| domain:"com.apple.dasd" name:"DYLDLaunch" sourceEnvironment:"(null)"&gt; ]&gt; Every day, at intervals of a few hours, there is information: &lt;RBSDomainAttribute| domain:"com.apple.dasd" name:"DYLDLaunch" sourceEnvironment:"(null)"&gt; ]&gt; Then, the following similar information follows: 12:15:56.047625+0800 runningboardd Executing launch request for app&lt;{my_bundle_id}((null))&gt; (DAS Prewarm launch) 12:15:56.050311+0800 runningboardd Creating and launching job for: app&lt;{my_bundle_id}((null))&gt; 12:15:56.050333+0800 runningboardd _mutateContextIfNeeded called for {my_bundle_id} 12:15:56.080560+0800 runningboardd app&lt;{my_bundle_id}((null))&gt;: -[RBPersonaManager personaForIdentity:context:personaUID:personaUniqueString:] required 0.000954 ms (wallclock); resolved to {1000, 39E408CF-2E67-4DB0-BF73-CFC5792285CD} 12:15:56.080632+0800 runningboardd 'app&lt;{my_bundle_id}(39E408CF-2E67-4DB0-BF73-CFC5792285CD)&gt;' Skipping container path lookup because containerization was prevented (&lt;RBSLaunchContext: 0xcd8cc9180&gt;) 12:15:56.080939+0800 runningboardd 'app&lt;{my_bundle_id}(39E408CF-2E67-4DB0-BF73-CFC5792285CD)&gt;' Constructed job description: &lt;dictionary: 0xcd8aa2a00&gt; { count = 19, transaction: 0, voucher = 0x0, contents = *** } 12:15:56.084839+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Memory Limits: active 4096 inactive 4096 &lt;private&gt; 12:15:56.084861+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] This process will be managed. 12:15:56.084882+0800 runningboardd Now tracking process: [app&lt;{my_bundle_id}((null))&gt;:1649] 12:15:56.084928+0800 runningboardd Calculated state for app&lt;{my_bundle_id}((null))&gt;: running-active (role: Background) (endowments: (null)) 12:15:56.086762+0800 runningboardd Using default underlying assertion for app: [app&lt;{my_bundle_id}((null))&gt;:1649] 12:15:56.086977+0800 runningboardd Acquiring assertion targeting [app&lt;{my_bundle_id}((null))&gt;:1649] from originator [app&lt;{my_bundle_id}((null))&gt;:1649] with description &lt;RBSAssertionDescriptor| "RB Underlying Assertion" ID:33-33-23101 target:1649 attributes:[ &lt;RBSDomainAttribute| domain:"com.apple.underlying" name:"defaultUnderlyingAppAssertion" sourceEnvironment:"(null)"&gt;, &lt;RBSAcquisitionCompletionAttribute| policy:AfterApplication&gt; ]&gt; 12:15:56.087203+0800 runningboardd Assertion 33-33-23101 (target:[app&lt;{my_bundle_id}((null))&gt;:1649]) will be created as active 12:15:56.087946+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] reported to RB as running 12:15:56.088053+0800 runningboardd Calculated state for app&lt;{my_bundle_id}((null))&gt;: running-active (role: Background) (endowments: (null)) 12:15:56.088114+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Set jetsam priority to 0 [0] flag[1] 12:15:56.088136+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Resuming task. 12:15:56.088211+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Set darwin role to: Background 12:15:56.088449+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] set Memory Limits to Hard Inactive (4096) 12:15:56.089314+0800 runningboardd Successfully acquired underlying assertion for [app&lt;{my_bundle_id}((null))&gt;:1649] 12:15:56.589755+0800 runningboardd Invalidating assertion 33-76-23100 (target:app&lt;{my_bundle_id}((null))&gt;) from originator [osservice&lt;com.apple.dasd&gt;:76] 12:15:56.590332+0800 runningboardd Removed last relative-start-date-defining assertion for process app&lt;{my_bundle_id}((null))&gt; 12:15:56.593760+0800 runningboardd [app&lt;{my_bundle_id}((null))&gt;:1649] Suspending task. 12:15:56.594120+0800 runningboardd Calculated state for app&lt;{my_bundle_id}((null))&gt;: running-suspended (role: None) (endowments: (null)) From these logs, I understand that the system is accelerating the launch speed of the application. But the time interval between these two logs below is very short, which suggests that the prewarm is executed just before main, and then the process is suspended. Is this understanding correct? 12:15:56.089314+0800 runningboardd Successfully acquired underlying assertion ... 12:15:56.589755+0800 runningboardd Invalidating assertion ... Regarding "DAS DYLD3 Closure Generation," I speculate that after a user restarts their phone, the system uses DYLD3 to prepare closures for frequently used applications, allowing for faster application launches. Is this assumption correct?

Let's say I queue some tasks on DispatchQueue.global() and then switch to another app or locking screen for a while. The app was not terminated but stayed in the background. Is there a chance that some tasks queued but not yet start could be discarded, even if the app hasn’t been terminated, after switching to another app or locking the screen for a while?

我这边用了几台机器升级iOS 18.1并没有测试出来问题，但是审核员测试出来了问题，并将崩溃报告发给了我。 以下是审核员发给我的的测试环境及崩溃报告： Device type: iPad Air (5th generation) OS version: iOS 18.1 崩溃报告如下： Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libobjc.A.dylib 0x196ae7c38 objc_msgSend + 56 1 UIKitCore 0x19bf9c0f4 -[UIView bounds] + 32 2 UIKitCore 0x19c14e15c -[UIScrollView _didEndDirectManipulationWithScrubbingDirection:] + 108 3 UIKitCore 0x19d4cd3e8 -[UIScrollView _stopScrollingNotify:pin:tramplingAnimationDependentFlags:] + 108 4 UIKitCore 0x19d4cd548 -[UIScrollView _stopScrollingAndZoomingAnimationsPinningToContentViewport:tramplingAnimationDependentFlags:] + 52 5 UIKitCore 0x19c385a28 -[UIScrollView dealloc] + 88 6 libsystem_blocks.dylib 0x221c29860 bool HelperBase::disposeCapture<(HelperBase::BlockCaptureKind)3>(unsigned int, unsigned char*) + 68 7 libsystem_blocks.dylib 0x221c29570 HelperBase::destroyBlock(Block_layout*, bool, unsigned char*) + 160 8 libsystem_blocks.dylib 0x221c29030 _call_dispose_helpers_excp + 72 9 libsystem_blocks.dylib 0x221c28fcc _Block_release + 256 10 libdispatch.dylib 0x1a14fe0d0 _dispatch_client_callout + 20 11 libdispatch.dylib 0x1a150c9e0 _dispatch_main_queue_drain + 980 12 libdispatch.dylib 0x1a150c5fc _dispatch_main_queue_callback_4CF + 44 13 CoreFoundation 0x1997fc204 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 16 14 CoreFoundation 0x1997f9440 __CFRunLoopRun + 1996 15 CoreFoundation 0x1997f8830 CFRunLoopRunSpecific + 588 16 GraphicsServices 0x1e57d81c4 GSEventRunModal + 164 17 UIKitCore 0x19c35eeb0 -[UIApplication _run] + 816 18 UIKitCore 0x19c40d5b4 UIApplicationMain + 340 19 BXT 0x104d90090 0x104aa4000 + 3063952 20 dyld 0x1bf1e6ec8 start + 2724 Thread 1: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 2: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 3: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 4 name: com.apple.uikit.eventfetch-thread Thread 4: 0 libsystem_kernel.dylib 0x1e9bba688 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1e9bbdd98 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1e9bbdcb0 mach_msg_overwrite + 424 3 libsystem_kernel.dylib 0x1e9bbdafc mach_msg + 24 4 CoreFoundation 0x1997f9a84 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1997f9130 __CFRunLoopRun + 1212 6 CoreFoundation 0x1997f8830 CFRunLoopRunSpecific + 588 7 Foundation 0x1984a0500 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 8 Foundation 0x1984a0350 -[NSRunLoop(NSRunLoop) runUntilDate:] + 64 9 UIKitCore 0x19c372358 -[UIEventFetcher threadMain] + 420 10 Foundation 0x1984b16c8 NSThread__start + 724 11 libsystem_pthread.dylib 0x221c3137c _pthread_start + 136 12 libsystem_pthread.dylib 0x221c2c494 thread_start + 8 Thread 5: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 6: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 7: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 8: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 9: 0 libsystem_pthread.dylib 0x221c2c480 start_wqthread + 0 Thread 10 name: JavaScriptCore libpas scavenger Thread 10: 0 libsystem_kernel.dylib 0x1e9bbff90 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x221c2ea50 _pthread_cond_wait + 1204 2 JavaScriptCore 0x1b156aca4 scavenger_thread_main + 1512 3 libsystem_pthread.dylib 0x221c3137c _pthread_start + 136 4 libsystem_pthread.dylib 0x221c2c494 thread_start + 8 Thread 11 name: WebThread Thread 11: 0 libsystem_kernel.dylib 0x1e9bba688 mach_msg2_trap + 8 1 libsystem_kernel.dylib 0x1e9bbdd98 mach_msg2_internal + 80 2 libsystem_kernel.dylib 0x1e9bbdcb0 mach_msg_overwrite + 424 3 libsystem_kernel.dylib 0x1e9bbdafc mach_msg + 24 4 CoreFoundation 0x1997f9a84 __CFRunLoopServiceMachPort + 160 5 CoreFoundation 0x1997f9130 __CFRunLoopRun + 1212 6 CoreFoundation 0x1997f8830 CFRunLoopRunSpecific + 588 7 WebCore 0x1ad46bb18 RunWebThread(void*) + 780 8 libsystem_pthread.dylib 0x221c3137c _pthread_start + 136 9 libsystem_pthread.dylib 0x221c2c494 thread_start + 8 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x00000003029b1840 x1: 0x0000000208981838 x2: 0x0000000000000000 x3: 0x0000000000000000 x4: 0x0000000000000001 x5: 0x00000f0300000000 x6: 0x0000000000000002 x7: 0x0000000000000000 x8: 0x00000000000000a0 x9: 0x0000000208981838 x10: 0x00000000024b036c x11: 0x00000000024b036c x12: 0x0000000000000000 x13: 0x00000000024b036c x14: 0x00000003029b1bc0 x15: 0x00000003029b1bc0 x16: 0x00000003029b1bc0 x17: 0x0000000205f46018 x18: 0x0000000000000000 x19: 0x0000000136841400 x20: 0x00000001fd5f4588 x21: 0xffffffffffffffff x22: 0x00000000000006d8 x23: 0x0000000136841ad8 x24: 0x0000000000000000 x25: 0x00000001fd5969e0 x26: 0x00000003032b7640 x27: 0x000000000000000f x28: 0x0000000000000000 fp: 0x000000016b35a4e0 lr: 0x000000019bf9c0f4 sp: 0x000000016b35a4e0 pc: 0x0000000196ae7c38 cpsr: 0x20001000 far: 0x00000000024b036c esr: 0x92000006 (Data Abort) byte read Translation fault

On iPhone, we can use iBeacon to wake up the APP in the background for Bluetooth scanning connection, now we want to port the function to AppleWatch APP, but the API related to iBeacon is not applicable on watchOS, does watchOS have a similar wake up mechanism?

I'm calling the following function in a SwiftUI View modifier in Xcode 16.1: nonisolated function f -> CGFloat { let semaphore = DispatchSemaphore(value: 0) var a: CGFloat = 0 DispatchQueue.main.async { a = ... semaphore.signal() } semaphore.wait() return a } The app freezes, and code in the main queue is never executed.

Greetings, does anyone know if can I use background capabilities to refresh auth token safely without be aware of the OS kill this task? Is there any Apple Oficial recommended flow to handle that? thanks