Hi All, I'm working on an app that needs to connect to BLE device and on defined schedules download data from the device. the amount of data is segnificant and might take around a minute to download. we tought about utilizing both state restoration and preservation for app waking and scheduling (triggered by the ble peripheral) and BGTaskScheduler to schedule a task that will handle a long running task to manage the full data download. now, will this solution in general valid? isnt it a "hack" that goes around the 10s limit that state restoration enforces? i know there are limitations for BGTask (like when it runs, it might be terminated by the system etc) but considering that, can we proceed with this approach without breaching apple guidelines? thank you in advance!

When I use BGContinuedProcessingTask to submit a task, my iPhone 12 immediately shows a notification banner displaying the task’s progress. However, on my iPhone 15 Pro Max, there’s no response — the progress UI only appears in the Dynamic Island after I background the app. Why is there a difference in behavior between these two devices? Is it possible to control the UI so that the progress indicator only appears when the app moves to the background?

Hello, In a launched agent, I need to call into a third‑party library that may occasionally hang. At present, these calls are made from a separate thread, but if the thread hangs it cannot be terminated (pthread_cancel/pthread_kill are ineffective). Would Apple recommend isolating this functionality in a separate process that can be force‑terminated if it becomes unresponsive, or is there a preferred approach for handling such cases in launched agents? Can I use the system call fork() in launched agent? Thank you in advance!

I'm specifically focused on Live Activity, but I think this is somewhat a general question. The app could get a few callbacks when: There's a new payload (start, update, end) There's a new token (start, update) There's some other lifecycle event (stale, dismissed) Assuming that the user didn't force kill the app, would the app get launched in all these scenarios? When OS launches the app for a reason, should we wrap our tasks with beginBackgroundTask or that's unnecessary if we're expecting our tasks to finish within 30 seconds? Or the OS may sometimes be under stress and give you far less time (example 3 seconds) and if you're in slow internet, then adding beginBackgroundTask may actually come in handy?

I've experimentally seen that the notifications(named:) API of NotificationCenter appears to buffer observed notifications internally. In local testing it appears to be limited to 8 messages. I've been unable to find any documentation of this fact, and the behavior seems like it could lead to software bugs if code is not expecting notifications to potentially be dropped. Is this behavior expected and documented somewhere? Here is a sample program demonstrating the behavioral difference between the Combine and AsyncSequence-based notification observations: @Test nonisolated func testNotificationRace() async throws { let testName = Notification.Name("TestNotification") let notificationCount = 100 var observedAsyncIDs = [Int]() var observedCombineIDs = [Int]() let subscribe = Task { @MainActor in print("setting up observer...") let token = NotificationCenter.default.publisher(for: testName) .sink { value in let id = value.userInfo?["id"] as! Int observedCombineIDs.append(id) print("🚜 observed note with id: \(id)") } defer { extendLifetime(token) } for await note in NotificationCenter.default.notifications(named: testName) { let id: Int = note.userInfo?["id"] as! Int print("🚰 observed note with id: \(id)") observedAsyncIDs.append(id) if id == notificationCount { break } } } let post = Task { @MainActor in for i in 1...notificationCount { NotificationCenter.default.post( name: testName, object: nil, userInfo: ["id": i] ) } } _ = await (post.value, subscribe.value) #expect(observedAsyncIDs.count == notificationCount) // 🛑 Expectation failed: (observedAsyncIDs.count → 8) == (notificationCount → 100) #expect(observedCombineIDs == Array(1...notificationCount)) print("done") }

Hi everyone, could you help us? We implemented a Flutter library that basically makes a call every x minutes if the app is in the background, but when I generate the version via TestFlight for testing, it doesn't work. Can you help us understand why? Below is a more detailed technical description. Apple Developer Technical Support Request Subject: BGTaskScheduler / Background Tasks Not Executing in TestFlight - Flutter App with workmanager Plugin Issue Summary Background tasks scheduled using BGTaskScheduler are not executing when the app is distributed via TestFlight. The same implementation works correctly when running the app locally via USB/Xcode debugging. We are developing a Flutter application that needs to perform periodic API calls when the app is in the background. We have followed all documentation and implemented the required configurations, but background tasks are not being executed in the TestFlight build. App Information Field Value App Version 3.1.15 (Build 311) iOS Minimum Deployment Target iOS 15.0 Framework Flutter Flutter SDK Version ^3.7.2 Technical Environment Flutter Dependencies (Background Task Related) Package Version Purpose workmanager ^0.9.0+3 Main background task scheduler (uses BGTaskScheduler on iOS 13+) flutter_background_service ^5.0.5 Background service management flutter_background_service_android ^6.2.4 Android-specific background service flutter_local_notifications ^19.4.2 Local notifications for background alerts timezone ^0.10.0 Timezone support for scheduling Other Relevant Flutter Dependencies Package Version firebase_core 4.0.0 firebase_messaging (via native Podfile) sfmc (Salesforce Marketing Cloud) ^9.0.0 geolocator ^14.0.0 permission_handler ^12.0.0+1 Info.plist Configuration We have added the following configurations to Info.plist: UIBackgroundModes <key>UIBackgroundModes</key> <array> <string>location</string> <string>remote-notification</string> <string>processing</string> </array> ### BGTaskSchedulerPermittedIdentifiers ```xml <key>BGTaskSchedulerPermittedIdentifiers</key> <array> <string>br.com.unidas.apprac.ios.workmanager.carrinho_api_task</string> <string>br.com.unidas.apprac.ios.workmanager</string> <string>be.tramckrijter.workmanager.BackgroundTask</string> </array> **Note:** We included multiple identifier formats as recommended by the `workmanager` Flutter plugin documentation: 1. `{bundleId}.ios.workmanager.{taskName}` - Custom task identifier 2. `{bundleId}.ios.workmanager` - Default workmanager identifier 3. `be.tramckrijter.workmanager.BackgroundTask` - Plugin's default identifier (as per plugin documentation) ## AppDelegate.swift Configuration We have configured the `AppDelegate.swift` with the following background processing setup: ```swift // In application(_:didFinishLaunchingWithOptions:) // Configuration to enable background processing via WorkManager // The "processing" mode in UIBackgroundModes allows WorkManager to use BGTaskScheduler (iOS 13+) // This is required to execute scheduled tasks in background (e.g., API calls) // Note: User still needs to have Background App Refresh enabled in iOS settings if UIApplication.shared.backgroundRefreshStatus == .available { // Allows iOS system to schedule background tasks with minimum interval UIApplication.shared.setMinimumBackgroundFetchInterval(UIApplication.backgroundFetchIntervalMinimum) } ## WorkManager Implementation (Dart/Flutter) ### Initialization ```dart /// Initializes WorkManager static Future<void> initialize() async { await Workmanager().initialize(callbackDispatcher, isInDebugMode: false); print('WorkManagerService: WorkManager initialized'); } ### Task Registration /// Schedules API execution after a specific delay ## Observed Behavior ### Works (Debug/USB Connection) - When running the app via Xcode/USB debugging - Background tasks are scheduled and executed as expected - API calls are made successfully when the app is backgrounded ### Does NOT Work (TestFlight) - When the app is distributed via TestFlight - Background tasks appear to be scheduled (no errors in code) - Tasks are **never executed** when the app is in background - We have tested with: - Background App Refresh enabled in iOS Settings - App used frequently - Device connected to WiFi and charging - Waited for extended periods (hours) ## Possible heart points 1. **Are there any additional configurations required for `BGTaskScheduler` to work in TestFlight/Production builds that are not required for debug builds?** 2. **Is the identifier format correct?** We are using: `br.com.unidas.apprac.ios.workmanager.carrinho_api_task` - Should it match exactly with the task name registered in code? 3. **Are there any known issues with Flutter's `workmanager` plugin and iOS BGTaskScheduler in production environments?** 4. **Is there any way to verify through logs or system diagnostics if the background tasks are being rejected by the system?** 5. **Could there be any conflict between our other background modes (`location`, `remote-notification`) and `processing`?** 6. **Does the Salesforce Marketing Cloud SDK (SFMC) interfere with BGTaskScheduler operations?** ## Additional Context - We have verified that `Background App Refresh` is enabled for our app in iOS Settings - The app has proper entitlements for push notifications and location services - Firebase, SFMC (Salesforce Marketing Cloud), and other SDKs are properly configured - The issue is **only** present in TestFlight builds, not in debug/USB-connected builds ## References - [Apple Documentation - BGTaskScheduler](https://aninterestingwebsite.com/documentation/backgroundtasks/bgtaskscheduler) - [Apple Documentation - Choosing Background Strategies](https://aninterestingwebsite.com/documentation/backgroundtasks/choosing_background_strategies_for_your_app) Thank you

I've tuned my task to be decently resilient, but I found a few issues that caused it to expire regularly. excessive CPU usage -> I'm actually running it behind ReactNative, and I found an issue where I was still updating ReactNative and thus it was keeping it alive the entire time the task was running. Removing this update helped improve stability not updating progress frequently enough ( see https://aninterestingwebsite.com/forums/thread/809182?page=1#868247022) My feature request is, would it be possible to get a reason the task was expired in task.expirationHandler? That would be helpful for both the user and for debugging why the task was expired. Thanks!

I tried making a concurrency-safe data queue. It was going well, until memory check tests crashed. It's part of an unadvertised git project. Its location is: https://github.com/CTMacUser/SynchronizedQueue/commit/84a476e8f719506cbd4cc6ef513313e4e489cae3 It's the blocked-off method "`memorySafetyReferenceTypes'" in "SynchronizedQueueTests.swift." Note that the file and its tests were originally AI slop.

I'm working on an editor for Bevy games and wanted the following workflow: Launch the game process Host a Metal view for the game's render target Use an XPC service to transfer an MTLSharedTextureHandle Keep the connection for editor/game communication and hot reload As such I created the following editor service: public let XPCEditorServiceName = "org.bevy.editor" public enum XPCEditorMessage: Codable { case ping } public enum XPCEditorReply: Codable { case pong } extension XPCListener { static let bevy = try! XPCListener(service: XPCEditorServiceName) { request in request.accept(XPCEditorService.init) } } struct XPCEditorService: XPCPeerHandler { let session: XPCSession private func handle(_ message: XPCEditorMessage) -> XPCEditorReply? { switch message { case .ping: return .pong } } func handleIncomingRequest(_ message: XPCReceivedMessage) -> (any Encodable)? { do { return handle(try message.decode()) } catch { return nil } } func handleCancellation(error: XPCRichError) { print(error) } } and I initialize it in my app's App initializer: // Launch the XPC service print(XPCListener.bevy) I wanted to test this using an executable target with the following main.swift: let session = try XPCSession(xpcService: XPCEditorServiceName) let response: XPCEditorReply = try session.sendSync(XPCEditorMessage.ping) print("Connected to editor!") The editor prints Listener<org.bevy.editor>(Active) but the game fails with Underlying connection was invalidated. Reason: Connection init failed at lookup with error 3 - No such process What am I doing wrong? PS. Would also appreciate an example of sending & rendering the MTLSharedTextureHandle both in editor & game.

I have migrated my code to use SMAppService but am running into trouble deleting the old SMJobBless launchd registration using launchd remove. I am invoking this from a root shell when I detect the daemon and associated plist still exist, then also deleting those files. The remove seems to work (i.e. no errors returned) but launchd list shows the service is registered, with a status code of 28 I am using the same label for SMAppService as previously and suspect this is the reason for the problem. However, I am reluctant to change the label as there will a lot of code changes to do this. If I quit my application, disable the background job in System Settings and run sudo launchd remove in the Terminal then it is removed and my application runs as expected once the background job is re-enabled. Alternatively, a reboot seems to get things going. Any suggestions on to how I could do this more effectively welcome.

We are developing a watchOS application that records long audio sessions and uploads them to our backend in chunks (~5 MB each) using pre-signed URLs and URLSession background upload. Current behavior: While audio recording is active, uploads continue successfully even when the app is in the background. Once the recording stops, if multiple chunks (e.g., 10+) are still pending, the remaining uploads do not proceed in the background and appear to be suspended. We attempted to use WKExtendedRuntimeSession (mindfulness type) to allow sufficient time to enqueue background upload tasks, but the session is invalidated when the app goes to the background (e.g., wrist down or app inactive), which prevents reliable scheduling of uploads. Additionally, we added the entitlement: com.apple.developer.extended-runtime-session (mindfulness) in the Watch app entitlements file, but Xcode automatic signing fails with: “Provisioning profile does not include the com.apple.developer.extended-runtime-session entitlement.” It appears that the provisioning profile is not being updated to include this entitlement. Our questions: Is WKExtendedRuntimeSession (mindfulness) expected to support scheduling background URLSession uploads after the app goes to background? How should we reliably complete pending background uploads on watchOS after a long recording session ends? Is there any additional entitlement or recommended approach for this use case? Why is the extended runtime entitlement not being applied to the provisioning profile despite being added in the entitlements file? We are aiming to follow Apple-recommended practices for long-running tasks and background uploads on watchOS. Any guidance would be greatly appreciated.

Hello, I am developing a macOS Launch Daemon (packaged as a bundle) that acts as an XPC server. For debugging purposes, I am trying to run the daemon's executable directly from the terminal via sudo ./mydaemon.app/Contents/MacOS/myexecutable. Initially, I added the com.apple.security.application-groups entitlement to the daemon. However, when starting the process, it failed to create the XPC service with the following errors: Unsatisfied entitlements: com.apple.security.application-groups Soft-restriction provisioning profile validation failure: Error Domain=AppleMobileFileIntegrityError Code=-413 "No matching profile found" UserInfo={NSURL=, unsatisfiedEntitlements=, NSLocalizedDescription=No matching profile found} listener failed to activate: xpc_error=[1: Operation not permitted] To resolve the profile validation failure, I registered a new App Group in the Apple Developer Portal, generated a new provisioning profile for the daemon that includes this group, and embedded it into the bundle (Contents/embedded.provisionprofile). Now, the previous profile error is gone, but I am getting a new identity conflict error, and the XPC listener still fails: Two equal instances have unequal identities. <anon<myproc_name>(501) pid=2818 AUID=501> and <anon<myproc_name>(501)(262) pid=2818 AUID=262> listener failed to activate: xpc_error=[1: Operation not permitted] My questions are: What exactly causes the Two equal instances have unequal identities error? I noticed the Audit UID difference (AUID=501 vs AUID=262). Why does NSXPCListener still fail with Operation not permitted? What is the recommended workflow for debugging a Launch Daemon that requires an App Group provisioning profile for XPC communication? Thank you in advance!

How can I return the results of a Spotlight query synchronously from a Swift function? I want to return a [String] that contains the items that match the query, one item per array element. I specifically want to find all data for Spotlight items in the /Applications folder that have a kMDItemAppStoreAdamID (if there is a better predicate than kMDItemAppStoreAdamID > 0, please let me know). The following should be the correct query: let query = NSMetadataQuery() query.predicate = NSPredicate(format: "kMDItemAppStoreAdamID > 0") query.searchScopes = ["/Applications"] I would like to do this for code that can run on macOS 10.13+, which precludes using Swift Concurrency. My project already uses the latest PromiseKit, so I assume that the solution should use that. A bonus solution using Swift Concurrency wouldn't hurt as I will probably switch over sometime in the future, but won't be able to switch soon. I have written code that can retrieve the Spotlight data as the [String], but I don't know how to return it synchronously from a function; whatever I tried, the query hangs, presumably because I've called various run loop functions at the wrong places. In case it matters, the app is a macOS command-line app using Swift 5.7 & Swift Argument Parser 1.5.0. The Spotlight data will be output only as text to stdout & stderr, not to any Apple UI elements.

Dear Apple： We are developing an app for file sharing between mobile devices. We want to create an iOS app that can continue sharing files with other devices even when it is running in the background. We are using WLAN channels for file sharing. Could you please advise on which background persistence measures we should use to ensure the iOS app can maintain file transfer when it goes to the background? Thank you.

Hi everyone, I’m Jaswanth. My friends and I are students working on a project where we’ve developed a website and a companion app. Here’s the key functionality: When two users enter a virtual room, one of them is prompted to download a desktop app. The app is built with Python and uses psutil to check for certain running processes. It does not send any data over the internet. It has a GUI that clearly shows the system is being monitored , it’s not hidden or running in the background silently. We want to sign and notarize the app to make sure it runs on macOS without warning users. However, we’re concerned that since the app accesses system process information, it might be flagged as malicious. Before we pay for the Apple Developer Program, we wanted to ask: Will an app like this (which only reads running processes and does not exfiltrate or hide activity) be eligible for notarization? Thanks in advance for any insights. We'd appreciate any clarity before moving forward. Best, Jaswanth

我在开发 Mac应用完成 后 通过Xcode 上传二进制文件的过程中, 出现了错误, 错误提示: App里面用到的 com.apple.security.application-groups 权限里面 有 group.*** 和 开发者组ID.*** 导致校验失败, 当我单独使用 group.xxx的时候, 我的程序会崩溃 , 因为里面用到了 MachPortRende 进程间通信问题, 这里默认了 开发者组ID.*** 这个路径, 错误详情: 在尝试启动 QuickFox 应用时，程序因权限问题而崩溃。具体的错误信息 bootstrap_check_in 组ID.xxxx.MachPortRendezvousServer.82392: Permission denied (1100) 显示，应用在尝试使用 Mach 端口进行进程间通信时，没有获得足够的权限, 因此 我需要您们的帮助, 如果单独用开发者组ID.*** 我们又没有权限 将数据写入 组ID.xxx里面的文件

Hello, I am programming a CLI tool to partition USB disks. I am calling diskutil to do the work, but I am hitting issues with permissions, it seems. Here is a trial run of the same command running diskutil directly on the terminal vs running from my code: Calling diskutil directly (works as expected) % /usr/sbin/diskutil partitionDisk /dev/disk2 MBR Free\ Space gap 2048S fat32 f-fix 100353S Free\ Space tail 0 Started partitioning on disk2 Unmounting disk Creating the partition map Waiting for partitions to activate Formatting disk2s1 as MS-DOS (FAT32) with name f-fix 512 bytes per physical sector /dev/rdisk2s1: 98784 sectors in 98784 FAT32 clusters (512 bytes/cluster) bps=512 spc=1 res=32 nft=2 mid=0xf8 spt=32 hds=16 hid=2079 drv=0x80 bsec=100360 bspf=772 rdcl=2 infs=1 bkbs=6 Mounting disk Finished partitioning on disk2 /dev/disk2 (disk image): #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme +104.9 MB disk2 1: DOS_FAT_32 F-FIX 51.4 MB disk2s1 Calling diskutil programmatically (error -69877) % sudo ./f-fix DEBUG: /usr/sbin/diskutil partitionDisk /dev/disk2 MBR Free Space gap 2048S fat32 f-fix 100353S Free Space tail 0 Started partitioning on disk2 Unmounting disk Error: -69877: Couldn't open device (Is a disk in use by a storage system such as AppleRAID, CoreStorage, or APFS?) Failed to fix drive `/dev/disk2' Source Code The relevant code from my program is this: char *args[16]; int n = 0; args[n++] = "/usr/sbin/diskutil"; args[n++] = "partitionDisk"; args[n++] = (char *)disk; args[n++] = (char *)scheme; (...) args[n++] = NULL; char **parent_env = *_NSGetEnviron(); if (posix_spawnp(&pid, args[0], NULL, NULL, args, parent_env) != 0) return 1; if (waitpid(pid, &status, 0) < 0) return 1; return 0; Question Are there any system protections against running it like so? What could I be missing? Is this a Disk Arbitration issue?

How can you force cancel a task that doesn't need cleanup and doesn't check for cancellation? If this cannot be done, would this be a useful addition to Swift? Here is the situation: The async method doesn't check for cancellation since it is not doing anything repetively (for example in a loop). For example, the method may be doing "try JSONDecoder().decode(Dictionary<String, ...>.self, from: data)" where data is a large amount. The method doesn't need cleanup. I would like the force cancellation to throw an error. I am already handling errors for the async method. My intended situation if that the user request the async method to get some JSON encoded data, but since it is taking longer that they are willing to wait, they would tap a cancellation button that the app provides.

When I search, it's always people trying to do stuff in the background. I want my app to only do stuff when it is active. And this post https://aninterestingwebsite.com/forums/thread/685525 seems to have prevented replies from the start. Which means it's just a documentation page and does not belong in the discussion forums at all, because it prevents all discussion.

Will App be terminated or suspended when updating to incremental version from app store?