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?

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.

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.

Hello, I am working on a cross-platform application where IPC between a LaunchDaemon and a LaunchAgent is implemented via Unix domain sockets. On macOS, the socket path length is restricted to 104 characters. What is the Apple-recommended directory for these sockets to ensure the path remains under the limit while allowing a non-sandboxed agent to communicate with a root daemon? Standard paths like $TMPDIR are often too long for this purpose. Thank you in advance!

We have tried using background tasks for file saving via (UIBackgroundTaskIdentifier) beginBackgroundTaskWithName:(NSString *) taskName expirationHandler:(void (^)(void)) handler; when our app goes into the background and/or is closed by the user. But we cannot make it work the way the documentation tells us it should. While task creation never reports an issue (in fact it never calls our expiration handler at all) and the returned task id is always valid, when we ask for how much time we have left via backgroundTimeRemaining we always get 6s instead of the specified 30s. We tried to create the task when the app state goes to inactive or when our delegate is called via applicationDidEnterBackground but it makes no difference, besides the fact that the remaining time reported is basically max double, when the app is not in background yet which is by design as far we understand. But we don't even get the 6s for saving when a user closes the app. Because almost immediately after applicationDidEnterBackground our delegate is called via applicationWillTerminate which will then again almost immediately end in the app receiving a SIGKILL. So we must be doing something wrong. Why would applicationWillTerminate be called at all when we have a valid background task that reports we have 6s left? We tried blocking the thread in both background and terminate to at least give us the 5s the spec says we have before we get the SIGKILL. That works in general but doesn't feel like the correct approach and we do need more time than the 5s or 6s we get this way. Are we supposed to add something to our plist in order for these background tasks to work correctly? It is very confusing that there is a second mechanism that's also called background tasks for running apps in the background in general, which is not applicable to us. Are we supposed to block somewhere when we create the task? Or even spin up an extra thread for the task? Why is our expirationHandler never called? The spec says that our handler should be called if it was unable to "grant the ask assertion" so it seems like we do not have that problem. But it's also supposed to be called just before we are running out of time but by that time the app is already dead. This was all tested on iOS 26.3 and it is probably worth mentioning that our app is Qt-based.

We are developing a mileage tracking application that depends on continuous background location updates on iOS. Our app has the required background modes enabled: <key>UIBackgroundModes</key> <array> <string>remote-notification</string> <string>processing</string> <string>fetch</string> <string>location</string> </array> We are observing inconsistent behavior with background location tracking in app terminated state. In some cases, after a period of time, location updates stop completely. Sometimes iOS successfully relaunches the app when movement is detected and location updates resume correctly. However, in other cases, the app is not relaunched by the system, and we stop receiving location updates entirely. We reviewed Apple’s documentation on handling background location updates: https://developer.apple.com/documentation/corelocation/handling-location-updates-in-the-background Based on our observations, we would appreciate clarification on the following points: Is this considered expected iOS behavior or a system limitation? Under what conditions does iOS decide not to relaunch a terminated app for location events? Are there recommended best practices to improve the reliability of background location relaunch behavior? Is there any logging, diagnostics, or debugging mechanism available to determine why the app was not relaunched? Apple’s documentation mentions that location updates may be queued while the app is terminated and later delivered after relaunch. However, in some scenarios we do not receive those queued updates after the app restarts. Under what conditions can queued location updates be discarded or not delivered? Additional notes: We are using standard Core Location background updates. “Always” location permission is granted. Background App Refresh is enabled. The issue is observed intermittently across multiple iOS devices.

When my app enter to background, I start a background task, and when Expiration happens, I end my background task. The code likes below: backgroundTask = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^{ dispatch_async(dispatch_get_main_queue(), ^{ if (backgroundTask != UIBackgroundTaskInvalid) { [[UIApplication sharedApplication] endBackgroundTask:backgroundTask]; backgroundTask = UIBackgroundTaskInvalid; [self cancel]; } }); }]; When the breakpoint is triggered at the endBackgroundTask line, I also get the following log: [BackgroundTask] Background task still not ended after expiration handlers were called: <UIBackgroundTaskInfo: 0x282d7ab40>: taskID = 36, taskName = Called by MyApp, from MyMethod, creationTime = 892832 (elapsed = 26). This app will likely be terminated by the system. Call UIApplication.endBackgroundTask(:) to avoid this. The log don't appear every time, so why is that? Is there something wrong with my code?

Hello, I am currently developing an iOS application using SensorKit. I encountered an issue when attempting to fetch SensorKit data in the background using background tasks (appRefresh, processing). The following error occurs: In the delegate function func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, failedWithError error: any Error) {}, I receive the error: SRErrorDataInaccessible. In code specific manner: start and handle background fetch (appRefresh) func handleAppRefreshTask(task: BGAppRefreshTask) { logger.logWithServer(level: .default, message: "background fetch start", category: String(describing: BackgroundTaskManager.self)) scheduleBackgroundFetch() let queue = OperationQueue() queue.maxConcurrentOperationCount = 1 let fetchOperation = FetchOperation() queue.addOperation(fetchOperation) task.expirationHandler = { self.logger.logWithServer(level: .error, message: "background fetch expirated", category: String(describing: BackgroundTaskManager.self)) queue.cancelAllOperations() } fetchOperation.completionBlock = { task.setTaskCompleted(success: !fetchOperation.isCancelled) } } Background fetch operation class class FetchOperation: Operation { override func main() { guard !isCancelled else { return } Task { // this function will execute fetch request for all user allowed sensorReader, 'func fetch(_ request: SRFetchRequest)' await SensorkitManager.shared.startFetchAndUpload() } } } I have the following questions: Is it possible to fetch SensorKit data in the background? If it is possible, why does the above error occur? If it is possible, could you provide the solution code and the correct workflow to avoid this error? Thank you.

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?

We are currently developing a VoIP application that supports Local Push extention. I would like to ask for your advice on how the extension works when the iPhone goes into sleep mode. Our App are using GCD (Grand Central Dispatch) to perform periodic processing within the extension, creating a cycle by it. [sample of an our source] class LocalPushProvider: NEAppPushProvider { let activeQueue: DispatchQueue = DispatchQueue(label: "com.myapp.LocalPushProvider.ActiveQueue", autoreleaseFrequency: .workItem) var activeSchecule: Cancellable? override func start(completionHandler: @escaping (Error?) -&gt; Void) { : self.activeSchecule = self.activeQueue.schedule( after: .init(.now() + .seconds(10)), // start schedule after 10sec interval: .seconds(10) // interval 10sec ) { self.activeTimerProc() } completionHandler(nil) } } However In this App that we are confirming that when the iPhone goes into sleep mode, self.activeTimerProc() is not called at 10-second intervals, but is significantly delayed (approximately 30 to 180 seconds). What factors could be causing the timer processing using GCD not to be executed at the specified interval when the iPhone is in sleep mode? Also, please let us know if there are any implementation errors or points to note. I apologize for bothering you during your busy schedule, but I would appreciate your response.

Hi Team, We intend to create a custom serial dispatch queue targetting a global queue. let serialQueue = DispatchQueue(label: "corecomm.tallyworld.serial", target: DispatchQueue.global(qos: .default)) The documentation for DispatchQueue init does not show any minimum OS versions. BUT DispatchSerialQueue init does show iOS 17.0+ iPadOS 17.0+ Mac Catalyst macOS 14.0+ tvOS 17.0+ visionOS watchOS 10.0+. Does that mean - I will not be able to create a custom serial dispatch queue below iOS 17?

I’m trying to enable Background Modes (specifically for audio, background fetch, remote notifications) in my iOS SwiftUI app, but I’m getting this error: Provisioning profile “iOS Team Provisioning Profile: [my app]” doesn’t include the UIBackgroundModes entitlement. On the developer website when I make the provision profile It doesnt give me the option to allow background modes. I added it to the sign in capabilities seccion in X code and matched the bundle ID to the provision profile and certificate etc but it still runs this error because the provision profile doesnt have the entitlements..

We are experiencing a crash in our application that only occurs on devices running iOS beta 26. It looks like a Beta problem. The crash appears to be caused by an excessive number of open File Descriptors. We identified this after noticing a series of crashes in different parts of the code each time the app was launched. Sometimes it would crash right at the beginning, when trying to load the Firebase plist file. That’s when we noticed a log message saying “too many open files,” and upon further investigation, we found that an excessive number of File Descriptors were open in our app, right after the didFinishLaunching method of the AppDelegate. We used the native Darwin library to log information about the FDs and collected the following: func logFDs() { var rlim = rlimit() if getrlimit(RLIMIT_NOFILE, &rlim) == 0 { print("FD LIMIT: soft: \(rlim.rlim_cur), hard: \(rlim.rlim_max)") } // Count open FDs before Firebase let openFDsBefore = countOpenFileDescriptors() print("Open file descriptors BEFORE Firebase.configure(): \(openFDsBefore)") } private func countOpenFileDescriptors() -> Int { var count = 0 let maxFD = getdtablesize() for fd in 0..<maxFD { if fcntl(fd, F_GETFD) != -1 { count += 1 } } return count } With this code, we obtained the following data: On a device with iOS 26 Beta 1, 2, or 3: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 256 On a device with iOS 18: FD LIMIT: soft: 256, hard: 9223372036854775807 Open file descriptors BEFORE Firebase.configure(): 57 In the case of the device running iOS 26 beta, the app crashes when executing Firebase.configure() because it cannot open the plist file, even though it can be found at the correct path — meaning the OS locates it. To confirm this was indeed the issue, we used the following code to close FDs before proceeding with Firebase configuration. By placing a breakpoint just before Firebase.configure() and running the following LLDB command: expr -l c -- for (int fd = 180; fd < 256; fd++) { (int)close(fd); } This released the FDs, allowing Firebase to proceed with its configuration as expected. However, the app would later crash again after hitting the soft limit of file descriptors once more. Digging deeper, we used this code to try to identify which FDs were being opened and causing the soft limit to be exceeded: func checkFDPath() { var r = rlimit() if getrlimit(RLIMIT_NOFILE, &r) == 0 { print("FD LIMIT: soft: \(r.rlim_cur), hard: \(r.rlim_max)") for fd in 0..<Int32(r.rlim_cur) { var path = [CChar](repeating: 0, count: Int(PATH_MAX)) if fcntl(fd, F_GETPATH, &path) != -1 { print(String(cString: path)) } } } } We ran this command at the very beginning of the didFinishLaunching method in the AppDelegate. On iOS 26, the log repeatedly showed Cryptexes creating a massive number of FDs, such as: /dev/null /dev/ttys000 /dev/ttys000 /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Application Support/DTX_8.191.1.1003.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/Caches/KSCrash/MyAppScheme/Data/ConsoleLog.txt /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-wal /private/var/mobile/Containers/Data/Application/AEE414F2-7D6F-44DF-A6D9-92EDD1D2B014/Library/HTTPStorages/mybundleId/httpstorages.sqlite-shm /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.01 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.11 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.12 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.13 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.14 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.15 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.16 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.17 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.18 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.19 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.20 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.21 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.22 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.23 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.24 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.25 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.26 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.29 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.30 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.31 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.32 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e … This repeats itself a lot of times. … /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.36 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.37 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.38 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.39 /private/preboot/Cryptexes/OS/System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64e.40

I am trying to create an app bundle with an xpc service. The main app creates a keychain item, and attempts to share (keychain access groups) with the xpc service it includes in its bundle. However, the xpc service always encounters a 'user interaction not allowed' error regardless of how I create the keychain item. kSecAttrAccessiblei is set to kSecAttrAccessibleWhenUnlockedThisDeviceOnly, the keychain access group is set for both the main app and the xpc service and in the provisioning profile. I've tried signing and notarizing. Is it ever possible for an xpc service to access the keychain? This all on macos 15.5.

Hi, I'm working on an application on MacOS. It contains a port-forward feature on TCP protocol. This application has no UI, but a local HTTP server where user can access to configure this application. I found that my application always exit for unknown purpose after running in backgruond for minutes. I think this is about MacOS's background process controlling. Source codes and PKG installers are here: https://github.com/burningtnt/Terracotta/actions/runs/16494390417

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]; }

I have several combine pipelines in my watch and iPhone app. While background tasks on the iPhone work correctly (the combine pipelines all activate), on the watch the pipelines do not get activated. I have an internal log reporting that data is being fed to the sources but is not propagating to the sinks. Thoughts?

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! 🙂

TCC Permission Inheritance for Python Process Launched by Swift App in Enterprise Deployment We are developing an enterprise monitoring application that requires a hybrid Swift + Python architecture due to strict JAMF deployment restrictions. We must deploy a macOS application via ABM/App Store Connect, but our core monitoring logic is in a Python daemon. We need to understand the feasibility and best practices for TCC permission inheritance in this specific setup. Architecture Component Bundle ID Role Deployment Swift Launcher com.athena.AthenaSentry Requests TCC permissions, launches Python child process. Deployed via ABM/ASC. Python Daemon com.athena.AthenaSentry.Helper Core monitoring logic using sensitive APIs. Nested in Contents/Helpers/. Both bundles are signed with the same Developer ID and share the same Team ID. Required Permissions The Python daemon needs to access the following sensitive TCC-controlled services: Screen Recording (kTCCServiceScreenCapture) - for capturing screenshots. Input Monitoring (kTCCServiceListenEvent) - for keystroke/mouse monitoring. Accessibility (kTCCServiceAccessibility) - a prerequisite for Input Monitoring. Attempts & Workarounds We have attempted to resolve this using: Entitlement Inheritance: Added com.apple.security.inherit to the Helper's entitlements. Permission Proxy: Swift app maintains active event taps to try and "hold" the permissions for the child. Foreground Flow: Keeping the Swift app in the foreground during permission requests. Questions Is this architecture supported? Can a Swift parent app successfully request TCC permissions that a child process can then use? TCC Inheritance: What are the specific rules for TCC permission inheritance between parent/child processes in enterprise environment? What's the correct approach for this enterprise use case? Should we: Switch to a Single Swift App? (i.e., abandon the Python daemon and rewrite the core logic natively in Swift). Use XPC Services? (instead of launching the child process directly).