I’m reaching out regarding an issue we’ve been experiencing with BGProcessingTask since upgrading to Xcode 26.1.1. Issue Summary Our daily background processing task—scheduled shortly after end‑of‑day—has stopped triggering reliably at night. This behavior started occurring only after updating to Xcode 26.1.1. Prior to this update, the task consistently ran around midnight, executed for ~10–15 seconds, and successfully rescheduled itself for the next day. Expected Behavior BGProcessingTask should run at/near the scheduled earliestBeginDate, which we set to roughly 2 hours after end-of-day. The task should execute, complete, and then reschedule itself. Actual Behavior On devices running builds compiled with Xcode 26.1.1, the task does not trigger at all during the night. The same code worked reliably before the Xcode update. No system logs indicate rejection, expiration, or background task denial. Technical Details This is the identifier we use: private enum DayEndProcessorConst {    static let taskIdentifier = "com.company.sdkmanagement.daysummary.manager" } The task is registered as follows: When app launched BGTaskScheduler.shared.register(    forTaskWithIdentifier: DayEndProcessorConst.taskIdentifier,    using: nil ) { [weak self] task in    self?.handleDayEndTask(task) } And scheduled like this: let date = Calendar.current.endOfDay(for: Date()).addingTimeInterval(60 * 60 * 2) let request = BGProcessingTaskRequest(identifier: DayEndProcessorConst.taskIdentifier) request.requiresNetworkConnectivity = true request.requiresExternalPower = false request.earliestBeginDate = date try BGTaskScheduler.shared.submit(request) As per our logs, tasks scheduled successfully The handler wraps the work in an operation queue, begins a UI background task, and marks completion appropriately: task.setTaskCompleted(success: true) Could you please advise whether: There are known issues with BGProcessingTask scheduling or midnight execution in Xcode 26.1.1 or iOS versions associated with it? Any new entitlement, configuration, or scheduler behavior has changed in recent releases? Additional logging or diagnostics can help pinpoint why the scheduler never fires the task?

This is a successor to: https://developer.apple.com/forums/thread/814231 I went into a slightly different direction. I generated more AI slop that use NSLock. Then I had the NSLock usage changed to Mutex usage. Now it crashes with: Task 13: EXC_BREAKPOINT (code=1, subcode=0x18d29326c) On one of the mutex closures. With an extended description: warning: TypeSystemSwiftTypeRef::operator(): had to engage SwiftASTContext fallback for type $s7Combine10PublishersO21LineBreakingPublisherE11SplitAtZeroV12Subscription33_D18F5AAE73662968F407B0A79FBD1F8DLLCy_x_qd__GD I put the class, a Subscription nested in its corresponding Publisher operator, in the given file Subscription.txt

Hi, I've now identified a few areas when BGContinuedProcessingTask gets expired by the system no progress for ~30 seconds high CPU usage high temperature Some of these I can preempt and expire preemptively and handle the notification, others I cannot and just need to let the failure bubble up. When the failure does bubble up, I'd like to update the title and subtitle. I'm able to update the title, but the subtitle is fixed at "Task Failed" Is there any workaround? Or shall I file a bug here?

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.

(! status in pluginkit, FinderSyncExtensionHost process missing) macOS Version: 26.3.1 Beta (25D771280a) Xcode Version: 16.3 (17C529) Steps to reproduce: Create a Finder Sync Extension project Build and install to /Applications Enable in System Settings → Extensions → Finder Extensions Extension shows ! in pluginkit output FinderSyncExtensionHost process never starts Context menu never appears in Finder Expected: Extension loads and context menu appears Actual: Extension marked with ! in pluginkit, no process launched pluginkit output: ! com.github.astronautJack.EasyNewFile.EasyNewFileExtension(1.0)