In terms of the API "contract", the expectation is that a request set as "fail" should either start "immediately" or return an error. 👍 my guess as to what happened is something like ... 4. Whatever happened at #3 didn't clear, so the job never started. A couple thoughts here: maybe the job would have started if the user waited additional time, it didn't start within a few seconds in the recording, I don't know if it never would have started. Seems likely though because they didn't report it start processing randomly at some point in the future. If there is some system bug, something funky with the daemon or otherwise, I'm surprised restarting the iPhone did not change the behavior, but waiting some time and trying it again got it to work. (Note I'm taking the user's word on that.) Without a sysdiagnose to see what actually happened, this is just speculation. I'll see what I can do to get one captured. Perhaps instead of starting automatically after 1.5s I'll ask them to contact support and provide a button to continue without background processing. What object is this? And is there ANY possibility that this object might deallocate? It's the "main" view controller in the app that registers the block and performs the work. It can deallocate in uncommon circumstances (eg closing the app and triggering a Home Screen quick action will recreate the root view controller). If you set things up right, #2 is simply hooking into existing functionality of #1 that's already being used by other parts of your app— the progress object is that same progress object #1 already uses, expiration is just save/cancel/etc. I'm struggling to follow this. It would be incredibly helpful to have a sample project with an example implementation showing the different approaches this API supports :) When the work is "done", then you call setTaskCompleted(success:). The complicated scenario I have in mind with the "start work first then request background continued processing task" approach is if the work were to complete before the register launchHandler got called. When the work gets "done" there is no background task persisted because it hasn't started yet and thus can't call that, then later it'd start for the work that is already done. in the case of BGContinuedProcessingTask, I think you'll basically always send "true". You pass "false" when you need the system to run to your task "again", but that doesn't apply to BGContinuedProcessingTask. I think that's not correct. You're supposed to send false when your work encounters an error and that will show the user it failed in the Live Activity, and the system won't run it again, is what I understand. Your snippet doesn't include setting an expiration handler. Do you set one somewhere else? I do in the real app yep, set inside the startProcessing function. Do you call setTaskCompleted(success:) and do you always pass in "true"? I do inside startProcessing after the task completes, passing true if successful and false if an error occurred. Are you reusing the same task identifier? No, it has a dynamic suffix using the wildcard notation that's unique down to the milliseconds* at the time the user tapped the button to start processing. *I did originally use seconds (which was in place when this user encountered the problem). When the task didn't start, some users rage clicked the start button resulting in the register block getting called again with the same number of seconds, which crashed the app because it's a fatal exception to register the same identifier twice in the same session. Switched to ms with the update that put in the 1.5s manual workaround fix. I've encountered a couple surprises shipping this! 😆 Note I've received 25 of these crash reports, so I know this issue has happened (more than) that many times, because when startProcessing is invoked my in-app progress UI prevents tapping the button again, which means my in-app UI did not appear before the user was able to trigger it again, hence the launchHandler wasn't invoked nor was an error thrown immediately. Sadly none of those users reached out to support or I'd ask them to capture a sysdiagnose.

Thanks Kevin! how do you "know" that? And what other devices have you tested on? That particular device does NOT have a dynamic island, so starting a task doesn't necessarily have any "visible" impact. The task DOES start, but you won't see any system UI unless the app is backgrounded or there are other tasks active. The user shared a screen recording where tapping the start processing button did not start processing (which I have not replicated on my devices). Reviewing the code, I'm quite positive the only way that's possible is if the register launchHandler is not invoked nor the catch block entered from submitting the request because when one of those occurs, I present in-app UI that shows progress in addition to updating the background task progress (if non-nil) in the implementation of the startProcessing() func which didn't get called because in-app UI did not appear in the screen recording. If your user is willing to help, what we really need is a sysdiagnose. I asked them but they said the issue is no longer occurring 😮 I inquired if anything had changed, any device settings, low power mode enabled state or anything like that, but nothing they can think of. I suspect no one else is going to reach out to report the issue because I quickly put a workaround in place to call startProcessing(backgroundTask: nil) if it is not called within 1.5s of submitting the request. 😅 Remember that taskIdentifier needs to be unique to each task. If you try to run the same ID "again", the second submit won't work. Yes they are unique. Similarly, if you're running multiple tasks, make sure that startProcessing() accounts for that and can track "all" of them. I don't support running multiple tasks simultaneously, after one completes the user could start another one if desired. it's certainly possible that there's an issue (or bug) with their particular device configuration. One thing I would check here is "Settings.app-> General-> Background App Refresh". That setting is tied to the BackgroundTask framework, and it's possible that disabling it would also disable BGContinuedProcessingTask. Testing this on my devices, when I turn off Background App Refresh, the register launchHandler is still called immediately. If there were an issue with the device configuration, wouldn't the submit request throw an error since the strategy is set to fail if it can't be started immediately? Or are there scenarios where it's expected behavior for an error to not be thrown and yet the launchHandler won't be called? your app doesn't actually have to wait for the request to fire before it starts its work ... If your app is going to do the work "no matter what", then waiting for the handler to fire is just adding additional complexity, delays, and testing load. I'd start the work "immediately" and update BGContinuedProcessingTask if/when it starts. For my simple use case it seems much more straightforward to perform the work once the launchHandler is invoked (or if the submit request fails perform the work without a BGContinuedProcessingTask). I can directly pass a BGContinuedProcessingTask or nil to the function that does the work, as opposed to needing to persist the BGContinuedProcessingTask when it starts and clean it up upon completion/cancelation/failure. This also avoids a seemingly complicated scenario: what do you do if the register launchHandler is invoked after its work had already completed/was canceled/failed, unclear what you'd do with that BGContinuedProcessingTask, shouldn't persist it, there's not a way to "cancel" it. State management for that seems very complicated. Tis much more straightforward to set the strategy to fail and begin processing once it starts or fails to start, since one of those is supposed to happen immediately when strategy is .fail, and that's a totally valid approach for using this API, is was what I understood.

I submitted a bug report FB21052216

Oh I found it mentioned here: https://developer.apple.com/documentation/photokit/uploading-asset-resources-in-the-background

This sounds related to my feedbacks FB16246168 (Text in Lock screen accessory rectangular widget does not wrap to another line when it should fit) FB16246023 (Lock screen accessory rectangular widget does not appear as expected on iPhone 16 Pro because text is too big and truncated) But both of those were filed before iOS 26

Thanks Ed. To confirm I understand correctly, if you develop a framework project and create an XCFramework to distribute as a closed source SDK, your framework cannot have dependencies on open source code-based packages. Every dependency, if any, must be a closed source XCFramework. It is not possible to create and distribute a Swift Package that is a binary target that has dependencies on other packages that are raw source code. When you do have the requirements to build an XCFramework with dependencies on open and closed source libraries, is the recommendation to use CocoaPods*? Are there plans to support this with Swift Package Manager in the future? *This setup "just works" with CocoaPods. You define a Podfile for your framework project specifying the dependencies with specific version numbers, run pod install, build your XCFramework from the workspace specifying BUILD_LIBRARIES_FOR_DISTRIBUTION=YES and SKIP_INSTALL=NO, create your Podspec specifying the vendored framework and those same dependencies, then add that pod in a new app. When you run pod install for the app, it takes care of downloading and integrating the dependencies appropriately, including open and closed source libraries your framework relies on. Since it can be achieved with CocoaPods, I'm surprised it seemingly can't with SPM.

This is fixed in macOS 26.1.

Thanks Ed! I appreciate the goal of reducing dependencies as much as possible. In this simple example to outline the approach in detail, I chose Kingfisher. Our real SDK is much more complicated, it utilizes a couple dependencies that would be very difficult to build ourselves. For our use case, it is acknowledged that if the app itself adds a dependency that our SDK relies on, it should be the same version number or an otherwise compatible version. Our dependencies are not super popular so that is fairly rare, though it does happen. And our SDK is not widely integrated in apps either, it happens to be quite niche. Note our SDK is already in use distributed via CocoaPods and we haven't had an issue thus far, we are now trying to understand how to distribute it via SPM instead. I'm interested to understand why I see the duplicate class warnings with the example I put together, given the app itself did not add Kingfisher as a dependency, its only dependency is the sample WallpaperKitDist SDK. Perhaps because I didn't configure the framework or package correctly so Kingfisher unintentionally got included in the framework and the app? Which is a good segue to your next comment. If you do want to keep the dependency for your XCFramework library, one thing you can sometimes do is set up a package to vend your XCFramework, and declare a dependency in that package so that consumers of the XCFramework also get a resolved version of the library dependency. The build of your framework would need to be configured so that this dependency doesn't wind up built in to your library binary. This way, the build of the client app provides a resolved version of the dependency. This sounds perfect. Given the steps outlined in my post to create an example framework, what do I need to do differently? Thanks!

Thanks for all your help Kevin! Really appreciate it, this will be a nice upgrade for my app.

Thanks Kevin! Moving performCountWork into the launchHandler (instead of before register) fixed it, simply because the call to set the totalUnitCount did not happen because currentBackgroundContinuedProcessingTask is nil at that time. Makes sense why it was indeterminate, it was never given a total! 😄 performCountWork still doesn't have to be called in the launchHandler, as long as I have the data to be able to set the total unit count when the task gets created at any time during the already in-flight operation, that approach works too. If I did that though, that brings up a question, what if the operation completes before the launchHandler is invoked (if I were to use the queue strategy)? A task would start for work that's already completed and thus wouldn't get progress updates and setTaskCompleted wouldn't be invoked. It seems much more straightforward to use the fail strategy and perform the work in the launchHandler (and if it the submit request fails perform the work without a BGContinuedProcessingTask as we do on iOS 18), at least for my simple use case. The only odd thing I'm seeing now is it animates indeterminately until completedUnitCount is set to a new value. In this example, that happens after just 1 second, so the switch from indeterminate to determinate looks janky. I set total to 100 and completed to 0 when the task starts, but it animates indeterminately until completedUnitCount is set to 1. If I set completed to 1 from the beginning, it animates indeterminately until completed is set to 2 (even if it gets set to 1 again). Any ideas to prevent the indeterminate state always show determinate progress?

I'm not sure what's going on, but I think this is a bug in your app, probably caused by this: [line with Task.sleep] Unless I've misread something, that means you're trying to update the UI and progress display 100x per second and the entire process completed in 1s The UILabel text and task's progress is updated once every 1 billion nanoseconds (1 second). This code sleeps for 1s to simulate a long running process that updates progress once per second and takes 100 seconds to complete. If you place a print statement after line 70, it is executed 100 times total after 1 minute and 40 seconds. I'd have to look at progress implementation, but it's possible/likely that it has some logic in it that's keeping it indeterminate because you're not on screen very long and the value is constantly changing. The indeterminate progress bar is visible (from the get-go and throughout the operation) even when the app stays in the foreground the whole time on iPad. There are details I could argue about in a "real" application I would be interested to hear! I do plan to put this in a real app with a slightly different long-running operation ha (notably you're manipulating UIKit from a background thread) I don't believe that's the case, setting breakpoints before the while block, in it, and after indicates it's on com.apple.main-thread.

the launchHandler is there to "tell" you the task has started and provide you the BGTask object you use to manage that work. No task type actually requires the work to occur inside the task. Thanks Kevin! So I need to think about this a little differently then. Instead of performing the work once you get a BGContinuedProcessingTask, just begin performing the work (the exact same way you do in iOS 18), if a BGContinuedProcessingTask starts persist it and update it as the work completes, and reset state when the work finishes or gets canceled. Basically, something like this: 1-6 I put together code to demonstrate this approach. Did I understand correctly, this should be all good with this simple counting demo? class ViewController: UIViewController { private let taskIdentifier = "\(Bundle.main.bundleIdentifier!).count_task" private let countToNumber: Int64 = 100 private var currentBackgroundContinuedProcessingTask: BGContinuedProcessingTask? private var shouldStopCounting = false @IBOutlet var progressLabel: UILabel! @IBAction func startCountingTapped(_ sender: UIButton) { performCountWork() // Register to support background continued processing // Ensure this is only registered once otherwise app crashes with exception: Launch handler for task with identifier has already been registered if !(UIApplication.shared.delegate as! AppDelegate).didRegisterCountBackgroundContinuedTask { (UIApplication.shared.delegate as! AppDelegate).didRegisterCountBackgroundContinuedTask = true BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: .main) { task in guard let task = task as? BGContinuedProcessingTask else { return } // The background continued processing task has started, use this task to manage the ongoing work self.currentBackgroundContinuedProcessingTask = task task.expirationHandler = { self.shouldStopCounting = true } } } // Request a background continued processing task start let request = BGContinuedProcessingTaskRequest( identifier: taskIdentifier, title: "Demo Task", subtitle: progressText(completedUnitCount: 0, totalUnitCount: countToNumber) ) request.strategy = .fail // Start the task immediately and fail if it cannot do { try BGTaskScheduler.shared.submit(request) } catch { // This should approximately never happen because the app doesn't submit any more tasks to exceed the system limit // But no big deal if it does not start, the user will just have to keep the app open to make progress print("Failed to submit task: \(error.localizedDescription)") } } @IBAction func stopCountingTapped(_ sender: UIButton) { shouldStopCounting = true } private func performCountWork() { Task { var countedToNumber: Int64 = 0 progressLabel.text = progressText(completedUnitCount: countedToNumber, totalUnitCount: countToNumber) currentBackgroundContinuedProcessingTask?.progress.completedUnitCount = countedToNumber currentBackgroundContinuedProcessingTask?.progress.totalUnitCount = Int64(countToNumber) while !shouldStopCounting && countedToNumber < countToNumber { try! await Task.sleep(nanoseconds: 1_000_000_000) countedToNumber += 1 progressLabel.text = progressText(completedUnitCount: countedToNumber, totalUnitCount: countToNumber) if let task = currentBackgroundContinuedProcessingTask { task.progress.completedUnitCount = countedToNumber task.updateTitle(task.title, subtitle: progressText(completedUnitCount: countedToNumber, totalUnitCount: countToNumber)) } } progressLabel.text = shouldStopCounting ? "Canceled" : "Success!" currentBackgroundContinuedProcessingTask?.setTaskCompleted(success: !shouldStopCounting) currentBackgroundContinuedProcessingTask = nil shouldStopCounting = false } } private func progressText(completedUnitCount: Int64, totalUnitCount: Int64) -> String { return "\(completedUnitCount) / \(totalUnitCount)" } } This seems to work, minus some behavior I did not expect: The Live Activity appears upon Start Counting while the app is in the foreground, I expected it to not appear until the user backgrounds the app. I'm using iPad Pro 26.0 (23A341). But on iPhone Air with 26.1 (23B5044l) the Live Activity does not appear until I close the app. Perhaps a bug that got resolved? The circular progress bar is spinning indeterminately in the Live Activity, not filling the circle as a percentage of completion (on both devices). the two strategies are "fail" (the default) and "queue" BGContinuedProcessingTaskRequest.strategy docs state queue is the default 😅

Oof this happens even with apps built using the Mac Catalyst 18 SDK. Production users are unable to use my app on macOS 26, Slider takes it down. Thanks for filing a bug, here’s to hoping it’s fixed quickly in 26.0.1.

I’m experiencing this issue with @FetchRequest in my app as well (using LazyVGrid instead of List). The above sample code replicates on iOS 26 beta 8 and 9 using the latest Xcode beta, though it seems to not replicate the first time you run the app only subsequent runs fail to update the UI upon changing a managed object a second time. I filed FB20029616 with a sysdiagnose and screen recording from when it replicated in my app.

Check if the app was built using the iOS 26 SDK (run it from Xcode 26 beta, not any earlier version).