I am building an app that uses the SMAppService to register a LaunchDaemon that is bundled with my .app. I've got a priming flow created which walks the user through approving the service so that it will start on login. However, I need to also be able to upgrade this background service if the user updates the app. To do this, I think I need to call unregisterAndReturnError and then registerAndReturnError. From my testing, this seems to work correctly, but I have a concern. Will the user ever be prompted to re-authorize the LaunchDaemon that I am registering? If so, under what circumstances will that happen, and what does it look like (so that I can guide the user through it)?

I have BGProcessingTask & BGAppRefreshTask working fine. The main purpose of my use of BGProcessingTask is to upload a file to AWS S3 using multipart/form-data. I have found that any file above about 2.5MB times out after running almost four minutes. If I run the same RESTful api using curl or Postman, I can upload a 25MB file in 3 seconds or less. I have tried to deliberately set .earliestBeginDate to 01:00 or 02:00 local time on the iPhone, but that does not seem to help. I use the delegate (yes, I am writing in Objective C) - URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend: and find that the iOS system uploads about 140kB every 15 seconds or so. I am looking for recommendations or insight into how I might enable uploads of 25MB files. I would be happy it I could do just one a day for my use case. I provide code on how I set up the NSURLSession and NSURLSessionDownloadTask, as it is my guess that if there is something that needs to be modified it is there. I have to believe there is a solution for this since I read in many posts here and in StackOverflow how developers are using this functionality for uploading many, many files. NSURLSessionConfiguration *sConf = [NSURLSessionConfiguration backgroundSessionConfigurationWithIdentifier:bkto.taskIdentifier]; sConf.URLCache = [NSURLCache sharedURLCache]; sConf.waitsForConnectivity = YES; sConf.allowsCellularAccess = NO; sConf.networkServiceType = NSURLNetworkServiceTypeVideot; sConf.multipathServiceType = NSURLSessionMultipathServiceTypeNone; sConf.discretionary = YES; sConf.timeoutIntervalForResource = kONEHOURINTERVAL; sConf.timeoutIntervalForRequest = kONEMINUTEINTERVAL; sConf.allowsExpensiveNetworkAccess = NO ; sConf.allowsConstrainedNetworkAccess = NO; sConf.sessionSendsLaunchEvents = YES; myURLSession = [NSURLSession sessionWithConfiguration:sConf delegate:self delegateQueue:nil]; And then later in the code... NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:pth]]; request.HTTPMethod = kHTTPPOST; request.HTTPBody = [NSData my body data]; request.timeoutInterval = 60; [request setValue:@"*/*" forHTTPHeaderField:@"Accept"]; [request setValue:@"en-us,en" forHTTPHeaderField:@"Accept-Language"]; [request setValue:@"gzip, deflate, br" forHTTPHeaderField:@"Accept-Encoding"]; [request setValue:@"ISO-8859-1,utf-8" forHTTPHeaderField:@"Accept-Charset"]; [request setValue:@"600" forHTTPHeaderField:@"Keep-Alive"]; [request setValue:@"keep-alive" forHTTPHeaderField:@"Connection"]; NSString *contType = [NSString stringWithFormat:@"multipart/form-data; boundary=%@",bnd]; [request setValue:contType forHTTPHeaderField:@"Content-Type"]; [request addValue:[NSString stringWithFormat:@"%lu",(unsigned long)myData.length] forHTTPHeaderField:@"Content-Length"]; and here are a few lines from my logs to show the infrequent multi-part uploads of only small chunks of data by the iOS system: -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: bytesSent = 393,216 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: totalBytesSent = 393,216 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: task = BackgroundDownloadTask <76A81A80-4703-4686-8742-A0048EB65108>.<2>, time Fri Mar 7 16:25:27 2025 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: bytesSent = 131,072 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: totalBytesSent = 524,288 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: task = BackgroundDownloadTask <76A81A80-4703-4686-8742-A0048EB65108>.<2>, time Fri Mar 7 16:25:42 2025 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: bytesSent = 131,072 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: totalBytesSent = 655,360 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: task = BackgroundDownloadTask <76A81A80-4703-4686-8742-A0048EB65108>.<2>, time Fri Mar 7 16:25:56 2025 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: bytesSent = 131,072 -[BKSessionManager URLSession:task:didSendBodyData:totalBytesSent:totalBytesExpectedToSend:]: totalBytesSent = 786,432

I have an app for macOS that is built using Mac Catalyst. I need to perform some background processing. I'm using BGProcessingTaskRequest to schedule the request. I have also integrated CKSyncEngine so I need that to be able to perform its normal background processing. On iOS, when the user leaves the app, I can see a log message that the request was scheduled and a bit later I see log messages coming from the actual background task code. On macOS I ran the app from Xcode. I then quit the app (Cmd-q). I can see the log message that the request was scheduled. But the actual task is never run. In my test, I ran my app on a MacBook Pro running macOS 26.0. When I quit the app, I checked the log file in the app sandbox and saw the message that the task was scheduled. About 20 minutes later I closed the lid on the MacBook Pro for the night. I did not power down, it just went to sleep. Roughly 10 hours later I opened the lid on the MacBook Pro, logged in, and checked the log file. It had not been updated since quitting the app. I should also mention that the laptop was not plugged in at all during this period. My question is, does a Mac Catalyst app support background processing after the user quits the app? If so, how is it enabled? The documentation for BGProcessingTaskRequest and BGProcessingTask show they are supported under Mac Catalyst, but I couldn't find any documentation in the Background Tasks section that mentioned anything specific to setup for Mac Catalyst. Running the Settings app and going to General -> Login Items & Extension, I do not see my app under the App Background Activity section. Does it need to be listed there? If so, what steps are needed to get it there? If this is all documented somewhere, I'd appreciate a link since I was not able to find anything specific to making this work under Mac Catalyst.

Hi there, First thanks for all the work on BGContinuedProcessingTask! It looks really promising. I have a question / issue around the behavior when a BGContinuedProcessingTask expires. Here is my setup. I have an app who's responsible for uploading large files in the field (AKA wifi is not expected) For a given file, it can likely fail due to network conditions I'm using Multipart upload though so I can retry a file to pick up where it left off. I use one taskIdentifier per file, and when the file fails, I can retry the task and have it continue where it left off (I am reusing the taskIdentifier here for retries, let me know if I shouldn't be doing that) Here is the behavior I am seeing I start an upload, it seems to be uploading normally I turn on airplane mode to simulate expiration of the task the task fails as expected after ~30 seconds, and I see the failure in my home screen. I have callbacks in the task to put my app in the proper state on expiration / failure I turn back on airplane mode and I retry the task, the way I do this is I do NOT re-register, I simply re-submit the task with the same TaskIdentifier. What I would have expected is that the failure task is REPLACED with the new task and new progress. Instead what I see is TWO ContinuedBackgroundProcessingTasks, one in the failure state and one in progress. My question is How can I make retries reuse the same task notification item? OR if that's not possible, how do I programmatically clear the task failure? I've tried cancelTask but that doesn't seem to clear it.

We are building a 'server' application that can either run as a daemon or can run in background without showing any GUI. Basically, the end user can either configure this to run as a daemon so that it can be tied to the user's session or will launch the process which user will start and quit as needed. I wanted to understand what is the recommended mechanism for such an application from Apple - Should this application be built as a macOS Bundle ? Apple documentation also says that we should not daemonize the process by calling fork. Hence if we create a unix-style executable, will I not need to fork to make it run in a detached state when I launch the executable via double-click ? [Reference Link] Is it fine to have an application on macOS which is a bundle but does not show any UI when launched by double click on the app-icon or via 'open'? While we have been able to achieve this by using NSApplicationMain and not showing the UI, was wondering if using CFRunLoop is best for this case as it is a non-gui application. If we can get the right documentation link or recommendations on how we should build such an application which can run in a non-gui mode and also in a daemonized manner, it will help us. Should the application be always built as a macos bundle or should it be a unix-style executable to support both the cases - by the same application/product and how should we look at the distribution of such applications.

The following code worked as expected on iOS 26 RC, but it no longer works on the official release of iOS 26. Is there something I need to change in order to make it work on the official version? Registration BGTaskScheduler.shared.register( forTaskWithIdentifier: taskIdentifier, using: nil ) { task in ////////////////////////////////////////////////////////////////////// // This closure is not called on the official release of iOS 26 ////////////////////////////////////////////////////////////////////// let task = task as! BGContinuedProcessingTask var shouldContinue = true task.expirationHandler = { shouldContinue = false } task.progress.totalUnitCount = 100 task.progress.completedUnitCount = 0 while shouldContinue { sleep(1) task.progress.completedUnitCount += 1 task.updateTitle("\(task.progress.completedUnitCount) / \(task.progress.totalUnitCount)", subtitle: "any subtitle") if task.progress.completedUnitCount == task.progress.totalUnitCount { break } } let completed = task.progress.completedUnitCount >= task.progress.totalUnitCount if completed { task.updateTitle("Completed", subtitle: "") } task.setTaskCompleted(success: completed) } Request let request = BGContinuedProcessingTaskRequest( identifier: taskIdentifier, title: "any title", subtitle: "any subtitle", ) request.strategy = .queue try BGTaskScheduler.shared.submit(request) Sample project code: https://github.com/HikaruSato/ExampleBackgroundProcess

I'm troubleshooting a crash I do not understand. I have a queue called DataQueue which never has anything dispatched to it - it's the sample buffer delegate of an AVCaptureVideoDataOutput. It can call DispatchQueue.main.sync to do some work on the main thread. It works fine no matter what we test, but has some crashes in the field that I need to fix. Here's it crashing: AppleCameraDataDelegate.dataQueue 0 libsystem_kernel.dylib 0x7bdc __ulock_wait + 8 1 libdispatch.dylib 0x4a80 _dlock_wait + 52 2 libdispatch.dylib 0x486c _dispatch_thread_event_wait_slow$VARIANT$mp + 52 3 libdispatch.dylib 0x113d8 __DISPATCH_WAIT_FOR_QUEUE__ + 332 4 libdispatch.dylib 0x10ff0 _dispatch_sync_f_slow + 140 The main thread isn't doing something I asked it to, but appears to be busy: Thread 0 libsystem_kernel.dylib 0x71a4 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x7fd8 _pthread_cond_wait$VARIANT$mp + 1232 2 grpc 0x2cb670 gpr_cv_wait + 131 (sync.cc:131) 3 grpc 0x119688 grpc_core::Executor::ThreadMain(void*) + 225 (executor.cc:225) 4 grpc 0x2e023c grpc_core::(anonymous namespace)::ThreadInternalsPosix::ThreadInternalsPosix(char const*, void (*)(void*), void*, bool*, grpc_core::Thread::Options const&)::'lambda'(void*)::__invoke(void*) + 146 (thd.cc:146) 5 libsystem_pthread.dylib 0x482c _pthread_start + 104 6 libsystem_pthread.dylib 0xcd8 thread_start + 8 Can anyone help me understand why this is a crash?

For some reason, after invoking an unrelated dlclose() call to unload any .dylib that had previously been loaded via dlopen(..., RTLD_NOW), the subsequent call to task_info(mach_task_self(), TASK_DYLD_INFO, ...) syscall returns unexpected structure in dyld_uuid_info image_infos-&gt;uuidArray, that, while it seems to represent an array of struct dyld_uuid_info elements, there is only 1 such element (dyld_all_image_infos *infos-&gt;uuidArrayCount == 1) and the app crashes when trying to access dyld_uuid_info image-&gt;imageLoadAddress-&gt;magic, as image-&gt;imageLoadAddress doesn't seem to represent a valid struct mach_header structure address (although it looks like a normal pointer within the process address space. What does it point to?). This reproduces on macOS 15.4.1 (24E263) Could you please confirm that this is a bug in the specified OS build, or point to incorrect usage of the task_info() API? Attaching the C++ file that reproduces the issue to this email message It needs to be built on macOS 15.4.1 (24E263) via Xcode or just a command line clang++ compiler. It may crash or return garbage, depending on memory layout, but on this macOS build it doesn’t return a correct feedfacf magic number for the struct mach_header structure. Thank you Feedback Assistant reference: FB18431345 //On `macOS 15.4.1 (24E263)` create a C++ application (for example, in Xcode), with the following contents. Note, that this application should crash on this macOS build. It will not crash, however, if you either: //1. Comment out `dlclose()` call //2. Change the order of the `performDlOpenDlClose()` and `performTaskInfoSyscall()` functions calls (first performTaskInfoSyscall() then performDlOpenDlClose()). #include &lt;iostream&gt; #include &lt;dlfcn.h&gt; #include &lt;mach/mach.h&gt; #include &lt;mach-o/dyld_images.h&gt; #include &lt;mach-o/loader.h&gt; void performDlOpenDlClose() { printf("dlopen/dlclose function\n"); printf("Note: please adjust the path below to any real dylib on your system, if the path below doesn't exist!\n"); std::string path = "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libswiftDemangle.dylib"; printf("Dylib to open: %s\n", path.c_str()); void* handle = ::dlopen(path.c_str(), RTLD_NOW); if(handle) { ::dlclose(handle); } else { printf("Error: %s\n", dlerror()); } } void performTaskInfoSyscall() { printf("Making a task_info() syscall\n"); printf("\033[34mSource File: %s\033[0m\n", __FILE__); task_t task = mach_task_self(); struct task_dyld_info dyld_info; mach_msg_type_number_t size = TASK_DYLD_INFO_COUNT; kern_return_t kr = task_info(task, TASK_DYLD_INFO, (task_info_t)&amp;dyld_info, &amp;size); if (kr != KERN_SUCCESS) { fprintf(stderr, "task_info failed: %s\n", mach_error_string(kr)); } const struct dyld_all_image_infos* infos = (const struct dyld_all_image_infos*)dyld_info.all_image_info_addr; printf("version: %d, infos-&gt;infoArrayCount: %d\n", infos-&gt;version, infos-&gt;infoArrayCount); for(uint32_t i=0; i&lt;infos-&gt;infoArrayCount; i++) { dyld_image_info image = infos-&gt;infoArray[i]; const struct mach_header* header = image.imageLoadAddress; printf("%d ", i); printf("%p ", (void*)image.imageLoadAddress); printf("(%x) ", header-&gt;magic); printf("%s\n", image.imageFilePath); fflush(stdout); } printf("\n\n"); printf("infos-&gt;uuidArrayCount: %lu\n", infos-&gt;uuidArrayCount); for(uint32_t i=0; i&lt;infos-&gt;uuidArrayCount; i++) { dyld_uuid_info image = infos-&gt;uuidArray[i]; const struct mach_header* header = image.imageLoadAddress; printf("%d ", i); printf("%p ", (void*)image.imageLoadAddress); printf("(%x)\n", header-&gt;magic); fflush(stdout); } printf("task_info() syscall result processing is completed\n\n"); } int main(int argc, const char * argv[]) { performDlOpenDlClose(); performTaskInfoSyscall(); return 0; }

I have an app that uses background audio recording. From what others say, I have enabled the audio background mode to keep the audio session active, and this worked. But when submitting the app to the app store, the app was rejected because the audio background mode is only supposed to be used for audio playback. How do I create this background mode while following Apple's guidelines?

Started a new X-Code Project after updating to 26.0.1 and realized that I get an error when trying to mark a class as ObservableObject => "Class XYZ does not conform to Protocol 'ObservableObject'. Strange behaviour, because at old projects the code is working even though the build options are the same and other settings like iOS version in Target are the same. There must be something chaged under the hood of XCode? I have to import Combine now, before I could write my class, e.g. CoreData Datamanager: ObservableObject only using CoreData.

Hello, I'm experiencing an issue with my app where it's being terminated by the system with a watchdog violation during back-to-back messaging operations. I've analyzed the crash logs but would appreciate additional insights on optimizing my approach. I'd appreciate any insights on how to resolve this problem. Crash Details: Exception Type: EXC_CRASH (SIGKILL) Termination Reason: FRONTBOARD with code 0x8BADF00D Error: "scene-update watchdog transgression: app exhausted real time allowance of 10.00 seconds" Reproduction Steps: User A initiates back-to-back messages to other User User A's UI becomes unresponsive and eventually the app crashes. Stack Trace Analysis: The crash occurs on the main thread, which appears to be blocked waiting for a condition in the keyboard handling system. The thread is stuck in [UIKeyboardTaskQueue _lockWhenReadyForMainThread] and related methods, suggesting an issue with keyboard-related operations during the messaging process. Crash Tag Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: app<com.msikodiak.eptt(AD934F8A-DF57-4B75-BE73-8CF1A9A8F856)>:301 exhausted real (wall clock) time allowance of 10.00 seconds ProcessVisibility: Foreground ProcessState: Running WatchdogEvent: scene-update WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 6.390 (user 3.640, system 2.750), 11% CPU", "Elapsed application CPU time (seconds): 0.020, 0% CPU" ) ThermalInfo: ( "Thermal Level: 0", "Thermal State: nominal" ) reportType:CrashLog maxTerminationResistance:Interactive> Triggered by Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x1e773d438 __psynch_cvwait + 8 1 libsystem_pthread.dylib 0x2210bc328 _pthread_cond_wait + 1028 2 Foundation 0x1957d8a64 -[NSCondition waitUntilDate:] + 132 3 Foundation 0x1957d8888 -[NSConditionLock lockWhenCondition:beforeDate:] + 80 4 UIKitCore 0x1998f1238 -[UIKeyboardTaskQueue _lockWhenReadyForMainThread] + 456 5 UIKitCore 0x19a3d775c __59-[UIKeyboardImpl updateAutocorrectPrompt:executionContext:]_block_invoke_9 + 28 6 UIKitCore 0x19986b084 -[UIKeyboardTaskQueue lockWhenReadyForMainThread] + 168 7 UIKitCore 0x19a3f2994 -[UIKeyboardTaskQueue waitUntilTaskIsFinished:] + 148 8 UIKitCore 0x19a3f2ac4 -[UIKeyboardTaskQueue performSingleTask:breadcrumb:] + 132 9 UIKitCore 0x199e2f7e4 -[_UIKeyboardStateManager updateForChangedSelection] + 144 10 UIKitCore 0x199e24200 -[_UIKeyboardStateManager invalidateTextEntryContextForTextInput:] + 92 11 WebKit 0x1ad52fa54 WebKit::PageClientImpl::didProgrammaticallyClearFocusedElement(WebCore::ElementContext&&) + 40 12 WebKit 0x1ad55adcc WebKit::WebPageProxy::didProgrammaticallyClearFocusedElement(WebCore::ElementContext&&) + 136 13 WebKit 0x1acec74e8 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 18604 14 WebKit 0x1acd21184 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 236 15 WebKit 0x1ace449b8 WebKit::WebProcessProxy::dispatchMessage(IPC::Connection&, IPC::Decoder&) + 40 16 WebKit 0x1ace44228 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) + 1764 17 WebKit 0x1acd1e904 IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) + 268 18 WebKit 0x1acd1e478 IPC::Connection::dispatchIncomingMessages() + 576 19 JavaScriptCore 0x1ae386b8c WTF::RunLoop::performWork() + 524 20 JavaScriptCore 0x1ae386960 WTF::RunLoop::performWork(void*) + 36 21 CoreFoundation 0x196badce4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 22 CoreFoundation 0x196badc78 __CFRunLoopDoSource0 + 172 23 CoreFoundation 0x196bac9fc __CFRunLoopDoSources0 + 232 24 CoreFoundation 0x196babc3c __CFRunLoopRun + 840 25 CoreFoundation 0x196bd0700 CFRunLoopRunSpecific + 572 26 GraphicsServices 0x1e3711190 GSEventRunModal + 168 27 UIKitCore 0x1997ee240 -[UIApplication _run] + 816 28 UIKitCore 0x1997ec470 UIApplicationMain + 336 29 Telstra PTT 0x1004d30c8 main + 56 30 dyld 0x1bd5d3ad8 start + 5964

Our app will launch automatically in the background，Doubt is the result of background fetch ，so we cancel the background modes setting of the background fetch,but we still can see the performFetchWithCompletionHandler method called when app launch in the background。Background launch will cause some bugs in our app. We don't want the app to start in the background. We hope to get help

when we use raise in GCD, the signal handler is executed asynchronously, whereas in pthread, it is executed synchronously as expected. example: #include &lt;Foundation/Foundation.h&gt; #include &lt;pthread/pthread.h&gt; static void HandleSignal(int sigNum, siginfo_t* signalInfo, void* userContext) { printf("handle signal %d\n", sigNum); printf("begin sleep\n"); sleep(3); printf("end sleep\n"); } void InstallSignal(void) { static const int g_fatalSignals[] = { SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGPIPE, SIGSEGV, SIGSYS, SIGTRAP, }; int fatalSignalsCount = sizeof(g_fatalSignals) / sizeof(int); struct sigaction action = {{0}}; action.sa_flags = SA_SIGINFO | SA_ONSTACK; #if defined(__LP64__) action.sa_flags |= SA_64REGSET; #endif sigemptyset(&amp;action.sa_mask); action.sa_sigaction = &amp;HandleSignal; struct sigaction pre_sa; for(int i = 0; i &lt; fatalSignalsCount; i++) { int sigResult = sigaction(g_fatalSignals[i], &amp;action, &amp;pre_sa); } } void* RaiseAbort(void *userdata) { raise(SIGABRT); printf("signal handler has finished\n"); return NULL; } int main(int argc, const char * argv[]) { InstallSignal(); dispatch_async(dispatch_get_global_queue(0, 0), ^{ raise(SIGABRT); // abort(); // abort() is ok RaiseAbort(nullptr); }); // pthread is ok // pthread_t tid; // int ret = pthread_create(&amp;tid, NULL, RaiseAbort, NULL); // if (ret != 0) { // fprintf(stderr, "create thread failed\n"); // return EXIT_FAILURE; // } [[NSRunLoop mainRunLoop] run]; return 0; } console log: signal handler has finished handle signal 6 begin sleep end sleep

Hi, I have a sandboxed app with a bundled sandboxed XPC service. When it’s launched, the XPC service registers a repeating XPC activity with the system. The activity’s handler block does get called regularly like I’d expect, but it stops being called once the main app terminates. What’s the recommended way to fix this issue? Could I have a bundled XPC service double as a launch agent, or would that cause other problems?

I've been experimenting with the new low-level Swift API for XPC (XPCSession and XPCListener). The ability to send and receive Codable messages is an appealing alternative to making an @objc protocol in order to use NSXPCConnection from Swift — I can easily create an enum type whose cases map onto the protocol's methods. But our current XPC code validates the incoming connection using techniques similar to those described in Quinn's "Apple Recommended" response to the "Validating Signature Of XPC Process" thread. I haven't been able to determine how to do this with XPCListener; neither the documentation nor the Swift interface have yielded any insight. The Creating XPC Services article suggests using Xcode's XPC Service template, which contains this code: let listener = try XPCListener(service: serviceName) { request in request.accept { message in performCalculation(with: message) } } The apparent intent is to inspect the incoming request and decide whether to accept it or reject it, but there aren't any properties on IncomingSessionRequest that would allow the service to make that decision. Ideally, there would be a way to evaluate a code signing requirement, or at least obtain the audit token of the requesting process. (I did notice that a function xpc_listener_set_peer_code_signing_requirement was added in macOS 14.4, but it takes an xpc_listener_t argument and I can't tell whether XPCListener is bridged to that type.) Am I missing something obvious, or is there a gap in the functionality of XPCListener and IncomingSessionRequest?

It looks like ExtensionKit (and ExtensionFoundation) is fully available on iOS 26 but there is no mention about this in WWDC. From my testing, it seems as of beta 1, ExtensionKit allows the app from one dev team to launch extension provided by another dev team. Before we start building on this, can someone from Apple help confirm this is the intentional behavior and not just beta 1 thing?

When I install my application, it installs fine and everything works alongwith all the system level daemons but when I reboot the system, none of my daemons are getting launched and this happens only on MacOS 15x, on older version it is working fine. In the system logs, I see that my daemons have been detected as legacy daemons by backgroundtaskmanagementd with Disposition [enabled, allowed, visible, notified] 2025-01-13 21:17:04.919128+0530 0x60e Default 0x0 205 0 backgroundtaskmanagementd: [com.apple.backgroundtaskmanagement:main] Type: legacy daemon (0x10010) 2025-01-13 21:17:04.919128+0530 0x60e Default 0x0 205 0 backgroundtaskmanagementd: [com.apple.backgroundtaskmanagement:main] Flags: [ legacy ] (0x1) 2025-01-13 21:17:04.919129+0530 0x60e Default 0x0 205 0 backgroundtaskmanagementd: [com.apple.backgroundtaskmanagement:main] Disposition: [enabled, allowed, visible, notified] (0xb) But later, it backgroundtaskmanagementd decides to disallow it. 2025-01-13 21:17:05.013202+0530 0x32d Default 0x4d6 89 0 smd: (BackgroundTaskManagement) [com.apple.backgroundtaskmanagement:main] getEffectiveDisposition: disposition=[enabled, disallowed, visible, notified], have LWCR=true 2025-01-13 21:17:05.013214+0530 0x32d Error 0x0 89 0 smd: [com.apple.xpc.smd:all] Legacy job is not allowed to launch: &lt;private&gt; status: 2 Is there anything changed in latest Mac OS which is causing this issue? Also what does this status 2 means. Can someone please help with this error? The plist has is true

To establish a privileged helper daemon from a command line app to handle actions requiring root privileges I still use the old way of SMJobBless. But this is deprecated since OSX 10.13 and I want to finally update it to the new way using SMAppService. As I'm concerned with securing it against malicious exploits, do you have a recommended up-to-date implementation in Objective-C establishing a privileged helper and verifying it is only used by my signed app? I've seen the suggestion in the documentation to use SMAppService, but couldn't find a good implementation covering security aspects. My old implementation in brief is as follows: bool runJobBless () { // check if already installed NSFileManager* filemgr = [NSFileManager defaultManager]; if ([filemgr fileExistsAtPath:@"/Library/PrivilegedHelperTools/com.company.Helper"] && [filemgr fileExistsAtPath:@"/Library/LaunchDaemons/com.company.Helper.plist"]) { // check helper version to match the client // ... return true; } // create authorization reference AuthorizationRef authRef; OSStatus status = AuthorizationCreate (NULL, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authRef); if (status != errAuthorizationSuccess) return false; // obtain rights to install privileged helper AuthorizationItem authItem = { kSMRightBlessPrivilegedHelper, 0, NULL, 0 }; AuthorizationRights authRights = { 1, &authItem }; AuthorizationFlags flags = kAuthorizationFlagDefaults | kAuthorizationFlagInteractionAllowed | kAuthorizationFlagPreAuthorize | kAuthorizationFlagExtendRights; status = AuthorizationCopyRights (authRef, &authRights, kAuthorizationEmptyEnvironment, flags, NULL); if (status != errAuthorizationSuccess) return false; // SMJobBless does it all: verify helper against app and vice-versa, place and load embedded launchd.plist in /Library/LaunchDaemons, place executable in /Library/PrivilegedHelperTools CFErrorRef cfError; if (!SMJobBless (kSMDomainSystemLaunchd, (CFStringRef)@"com.company.Helper", authRef, &cfError)) { // check helper version to match the client // ... return true; } else { CFBridgingRelease (cfError); return false; } } void connectToHelper () { // connect to helper via XPC NSXPCConnection* c = [[NSXPCConnection alloc] initWithMachServiceName:@"com.company.Helper.mach" options:NSXPCConnectionPrivileged]; c.remoteObjectInterface = [NSXPCInterface interfaceWithProtocol:@protocol (SilentInstallHelperProtocol)]; [c resume]; // call function on helper and wait for completion dispatch_semaphore_t semaphore = dispatch_semaphore_create (0); [[c remoteObjectProxy] callFunction:^() { dispatch_semaphore_signal (semaphore); }]; dispatch_semaphore_wait (semaphore, dispatch_time (DISPATCH_TIME_NOW, 10 * NSEC_PER_SEC)); dispatch_release (semaphore); [c invalidate]; [c release]; }

Hello! We are in the progress of migrating a large Swift 5.10 legacy code base over to use Swift 6.0 with Strict Concurrency checking. We have already stumbled across a few weird edge cases where the "guaranteed" @MainActor isolation is violated (such as with @objc #selector methods used with NotificationCenter). However, we recently found a new scenario where our app crashes accessing main actor isolated state on a background thread, and it was surprising that the compiler couldn't warn us. Minimal reproducible example: class ViewController: UIViewController { var isolatedStateString = "Some main actor isolated state" override func viewDidLoad() { exampleMethod() } /// Note: A `@MainActor` isolated method in a `@MainActor` isolated class. func exampleMethod() { testAsyncMethod() { [weak self] in // !!! Crash !!! MainActor.assertIsolated() // This callback inherits @MainActor from the class definition, but it is called on a background thread. // It is an error to mutate main actor isolated state off the main thread... self?.isolatedStateString = "Let me mutate my isolated state" } } func testAsyncMethod(completionHandler: (@escaping () -> Void)) { let group = DispatchGroup() let queue = DispatchQueue.global() // The compiler is totally fine with calling this on a background thread. group.notify(queue: queue) { completionHandler() } // The below code at least gives us a compiler warning to add `@Sendable` to our closure argument, which is helpful. // DispatchQueue.global().async { // completionHandler() // } } } The problem: In the above code, the completionHandler implementation inherits main actor isolation from the UIViewController class. However, when we call exampleMethod(), we crash because the completionHandler is called on a background thread via the DispatchGroup.notify(queue:). If were to instead use DispatchQueue.global().async (snippet at the bottom of the sample), the compiler helpfully warns us that completionHandler must be Sendable. Unfortunately, DispatchGroup's notify gives us no such compiler warnings. Thus, we crash at runtime. So my questions are: Why can't the compiler warn us about a potential problem with DispatchGroup().notify(queue:) like it can with DispatchQueue.global().async? How can we address this problem in a holistic way in our app, as it's a very simple mistake to make (with very bad consequences) while we migrate off GCD? I'm sure the broader answer here is "don't mix GCD and Concurrency", but unfortunately that's a little unavoidable as we migrate our large legacy code base! 🙂

I have several processes maintaining NSXPConnection to an XPC service. The connections are bi-directional. Each side service and clients) of the connection exports an object, and an XPCInterface. The @protocols are different - to the service, and from the service to clients. So long as all the "clients" fully implement their "call-back" @protocol, there's no problem. All works fine. However - If a client does NOT implement a method in the "call back protocol", or completely neglects to export an object, or interface - and the service attempts to call back using the nonexistent method -- the XPC connection invalidates immediately. So far - expected behaviour. However, if I want the service to behave to the client a little like a "delegate" style -- and check first whether the client "respondsToSelector" or even - supports an interface BEFORE calling it, then this doesn't work. When my XPC service tries the following on a client connection: if (xpcConnection.remoteObjectInterface == nil) os_log_error(myXPCLog, "client has no remote interface); the condition is never met - i.e. the "remoteObjectInterface is never nil even when the client does NOT configure its NSXPCConnection with any incoming NSXPCInterface, and does not set an "exportedObject" Furthermore, the next check: if ([proxy respondsToSelector:@selector(downloadFiltersForCustomer:withReply:)]) { } will not only fail - but will drop the connection. The client side gets the invalidation with the following error: <NSXPCConnection: 0x600000b20000> connection to service with pid 2477 named com.proofpoint.ecd: received an undecodable message for proxy 1 (no exported object to receive message). Dropping message. I guess the "undecidable message" is the respondsToSelector - because the code doesn't get to attempt anything else afterwards, the connection drops. Is there a way to do this check "quietly", or suffering only "interruption", but without losing the connection,