Markup Tool: Support for persistent tool presets (color, stroke, fill settings) I use Markup heavily for work — up to 20 images per day, always with the same settings: red arrow or rectangle, no fill, specific stroke width. The problem has two parts: Part 1 – Markup resets everything: Every time Markup is opened, all settings reset: tool, color, fill, stroke width. This means 3–4 manual steps per image, adding up to 80 unnecessary interactions per day. Part 2 – The default red is unusable: The red in Apple’s color palette is muted and too pale for clear, high-contrast annotations. I have to open the color wheel every single time to manually select a proper, vivid red. The copy/duplicate workaround only helps within one image — as soon as a new photo or screenshot is opened, everything starts over from scratch. Markup has no memory between different images. Switching to a third-party annotation app is not a solution — the entire advantage of Markup is its native integration directly within the Photos app, without switching apps. And Markup cannot be configured in depth through Shortcuts either — color, fill, and stroke width are not controllable there. The attached images: Image 1 shows the entry point in the Photos app. Image 2 shows Markup open with the current color palette. The blue-outlined fields do not indicate colors to be replaced — they mark the position where personally configured tool presets should appear: not individual colors, but fully pre-configured tools with color, stroke width, and fill setting already saved, ready to use with a single tap. My suggestion: Tool presets — configure once, saved permanently, available directly in the Markup toolbar. No need to re-configure color, fill, or stroke width for every new image. iOS already remembers last-used settings in many areas: camera mode, emojis, colors in Notes, Pages, and Keynote. Markup behaves as if it’s being opened for the first time, every time. This inconsistency costs me measurable time every single day.

I'm keeping most information in an actor and I would like to save also a closure in it that I get from func application( _ application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: @escaping () -> Void) Task.init{ await GeoreferenceQueue.shared.setBackgroundCompletionHandler(completionHandler) } } where GeoreferenceQueue is and actor, while the caller is a class. yet I receive error: Passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution of the closure and Sending task-isolated 'completionHandler' to actor-isolated instance method 'setBackgroundCompletionHandler' risks causing data races between actor-isolated and task-isolated uses

Hi everyone, I'm experiencing an unusually long wait time for my TestFlight external build review and wanted to see if others are facing similar issues in 2026. Current Status: Platform: iOS App Version: 1.2.90 (Build 24) Build Type: TestFlight External Testing Current Status: In Review - not "Waiting for Review" Time in Current Status: Over 2 weeks Submission Timeline: Current Submission: Wednesday at 9:49 AM (iOS 1.2.90 Build 24) Previous Submission: March 9, 2026 at 2:20 PM (iOS 1.2.90 Build 11) - Status: Completed (Rejected) Full History: March 9, 2026 2:20 PM - Initial submission (Build 11) March 15, 2026 5:25 AM - Rejection from Apple March 24 - April 15, 2026 - Multiple back-and-forth communications (5 messages total) April 15, 2026 2:22 PM - Last response from Apple Recent (Wednesday 9:49 AM) - Resubmitted new build (Build 24) Current - Still "In Review" after 2+ weeks What I've Tried: ✅ Addressed all rejection issues from the previous review ✅ Submitted a new build with higher build number (11 → 24) ✅ Submitted expedited review request through App Store Connect ✅ Contacted Apple Developer Support via email ✅ Requested phone callback for escalation What Concerns Me: The build has been stuck in "In Review" status for over 2 weeks This is AFTER already going through a full review cycle (rejection + resubmission) Normal review times are supposed to be 24-48 hours, even with the 2026 backlog The previous review cycle took over 1 month (March 9 → April 15) This is completely blocking our beta testing program Questions for the Community: Is anyone else experiencing 2+ week "In Review" times for TestFlight external builds in 2026? Does a previous rejection cause indefinite review delays on resubmission? Has anyone successfully resolved this by canceling and submitting a brand new build? Are there effective escalation paths beyond standard support channels? Could this indicate an account-level review issue? What I Understand: Review times have increased in 2026 due to higher submission volumes Previous rejections can lead to more thorough reviews However, 2+ weeks "In Review" (not even "Waiting") seems abnormal This delay is severely impacting our development timeline and beta testing plans. Any advice or shared experiences would be greatly appreciated! Thanks in advance for your help.

Howdy! I'm in the R&D phase of this project and I need help. I can't find any sources that verify what I want to do is even possible. I need to connect an iPhone or iPad using a USB cord to an external device which will transfer files to the iPhone or iPad. I have an app already made which can organize the files and whatever else I need to do (app is from a similar project). I'll refer to this device as Alfred (for poops and giggles) The plan (if possible) is for Alfred to recognize my app and use its documents folder as the destination of the transfer. The iDevice doesn't have to communicate with Alfred, but that would be a bonus. I don't want Alfred to run on an SOC. My goal is to have it be as simple as possible. No OS, just firmware. If the only way to interact with Apple Devices is Bluetooth or Wifi than so be it. If Matter or Thread could be utilized I wouldn't be apposed. Any help with this project would be greatly appreciated. Thanks in advance.

When interacting with RealityView’s realityViewCameraControls .orbit and setting a new RealityViewCameraContent .cameraTarget, the resulting camera target and camera orbit is incorrect. This can be demonstrated where one finger is orbiting the RealityView, and another pushes a button which changes the camera target. Instead of the camera facing the new target, some point in the scene is the new effective camera target and orbit point. This only occurs when an orbit interaction is currently taking place. If you stop interacting with the orbit, change target, then start orbit interacting again, everything works as expected. Though this example uses two-touches, any change of the camera target has this conflict with orbit interaction. This means interacting with orbit will result in the wrong camera view which is unexpected for users and difficult to reconcile or detect, for developers. Expected: Interacting (orbiting) the scene while setting a new camera target with the buttons on screen (at the same time), the camera’s new target shows centred in view the orbit revolves the new target and continues to match my gestures. Reality: Interacting (orbiting) the scene while setting a new camera target with the buttons on screen (at the same time), the camera’s new target is not centred in view, and camera is now orbiting an unexpected point in the scene, that is not my expected target. One imperfect workaround is to force a rebuild of the view after setting a new cameraTarget. This sets all targets correctly but results in a flicker, loss of orbit controls until re-touch and ultimately is a poor user experience, but is better than the wrong target being shown unexpectedly. Code Sample: import SwiftUI import RealityKit struct RKOribtTarget: View { @State private var target: Int = 0 @State private var rcContent: RealityViewCameraContent? @State private var rkID: UUID = UUID() let root = Entity() let center = ModelEntity(mesh: .generateSphere(radius: 0.05), materials: [UnlitMaterial(color: UIColor(.gray.opacity(0.5)))]) let red = ModelEntity(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .red, isMetallic: false)]) let blue = ModelEntity(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .blue, isMetallic: false)]) let green = ModelEntity(mesh: .generateBox(size: 0.1), materials: [SimpleMaterial(color: .green, isMetallic: false)]) var body: some View { VStack{ RealityView { content in red.position.x = 0.5 blue.position.z = 0.5 green.position.y = 0.5 center.position = .init(repeating: 0.25) content.cameraTarget = target == 0 ? root : blue root.addChild(red) root.addChild(blue) root.addChild(green) root.addChild(center) content.add(root) } update: { content in switch target{ case 0: content.cameraTarget = root case 1: content.cameraTarget = blue case 2: content.cameraTarget = red case 3: content.cameraTarget = green default: content.cameraTarget = root } } .id(rkID) .realityViewCameraControls(.orbit) VStack{ Text("Target") Button("Default") { target = 0 // Force rebuilding view resets orbit target and rotation // But shows a flicker, interaction requires touch reset // Not an ideal workaround // rkID = UUID() } .buttonStyle(.bordered) Button("Blue") { target = 1 // rkID = UUID() } .buttonStyle(.bordered) .tint(.blue) Button("Red") { target = 2 // rkID = UUID() } .buttonStyle(.bordered) .tint(.red) Button("Green") { target = 3 // rkID = UUID() } .buttonStyle(.bordered) .tint(.green) } } } } Xcode Version: Version 26.0 (17A324) iOS Version: iOS 26.5 (23F75) Tested on devices, iPhone 12 Pro, iPhone 15 Pro

Hello, with macOS' and iOS' recent updates (26.4.x), Handoff in my app appears to have become dysfunctional, as I receive the following message in the logs: getContinuationStreamsWithCompletionHandler(), inputStream=(null) outputStream=(null) error=Error Domain=NSPOSIXErrorDomain Code=94 "Bad message" UserInfo={NSLocalizedDescription=Could not set up internal streams} It ONLY works: From a Mac with 15.x to other Macs or iOS devices (on 26.4.x). All other combinations (see below) do NOT work: iOS (26.4.x) > iOS (26.4.x) iOS (26.4.x) > Mac (26.4.x) iOS (26.4.x) > Mac (15.x) Mac (26.4.x) > iOS (26.4.x) The Handoff prompt is shown in the Dock on Mac, in the app switcher on iOS, and in the Dock on iPadOS, but once I click/press it, I get the continuationStreams error. Now, is it my app, or the OS? Thank you kindly, – Matthias

Hi We are building a VPN app (PacketTunnelProvider) and allowing users to install the app through test flight and app upgrade works seamlessly without VPN, but immediately after enabling the VPN, we are not able to get app upgraded with the progress bar in test flight stuck at 90 percent and now app is not usable after that but VPN is still working. We are not noticing the issue on ios 12.4.1 version but facing the issue on iOS 13 versions. On looking through console app during upgradation process we are noticing a below recurring log message. Error acquiring hold on plugins for <bundle_identifier>: Error Domain=PlugInKit Code=14 "plugins are busy" UserInfo={busyPlugInUUIDs=({         XPCExtensionBundleIdentifier = "<bundle_identifier>.tunnel";     } ), NSLocalizedDescription=plugins are busy} Could someone please help us in resolving the issue.

Hello everyone, We are encountering a critical regression introduced in iOS 26.4 that results in permanent workout data loss for users. When invoking HKWorkoutBuilder.finishWorkout(completion:) while the iOS device is locked, the save operation fails completely. However, it fails silently: the completion handler executes but returns both a nil workout and a nil error. Expected Behavior: Before iOS 26.4 finishWorkout resulted in a workout id, and correctly stored the workout data in HealthKit. According to HealthKit data protection documentation, saving data when the device is locked should either succeed (writing to a temporary journal file to be merged upon unlock) or explicitly throw an error such as HKError.Code.errorDatabaseInaccessible. Actual Behavior: Because the framework returns nil for both the object and the error, the application has no way to detect that the save failed. We cannot implement a retry mechanism or queue the save, resulting in silent data loss. Steps to Reproduce: We have built a Minimal Reproducible Example (MRE) that reliably triggers this: Initialize an HKWorkoutBuilder and call beginCollection(withStart:) followed by endCollection(withEnd:). Wrap the finishWorkout call in a short 5-second asynchronous delay, protected by a UIBackgroundTask to prevent app suspension. Lock the physical device during this 5-second window. The finishWorkout completion handler will execute while the device is locked, returning workout == nil and error == nil. Existing Reports: We have filed this via Feedback Assistant (a month ago) and opened a TSI (a week ago), providing the MRE project and a sysdiagnose captured at the time of failure: Feedback ID: FB22396180 TSI Case-ID: 19755043 As we have not yet received a response or a suggested workaround through these official channels, we are reaching out to the community. Has anyone else encountered this silent failure with HKWorkoutBuilder recently? Any insights or escalation help would be greatly appreciated.

I'm facing a persistent location error on real iOS device: Error Domain=kCLErrorDomain Code=1 The operation couldn’t be completed. (kCLErrorDomain error 1.)

Hi Team, We are facing issue in testing the Age verification using Sandbox Account for your test environment. We tried to create region-specific sandbox test accounts as mentioned in the link (https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox) but we dont see an option to select Date of Birth and App Store Territory. After navigating to sandbox apple account setting and we tried to login with created sandbox test accounts(with gmail.com / qa.com/ test.com), its asking for two factor authentication. So, question here is which account should i use, sandbox account / real apple id? To overcome point 2, we created a gmail account and same is created as Sandbox test account, so that we can overcome two factor authentication. Now when we try to click on manage, nothing is happening. As per the link, it should show and option for select Age Assurance or Revoke App Consent. So if you can guide me with exact steps to follow on how to use the Sandbox account, that would be helpful for our app development. Thanks

Issue Description We noticed the app shares a similar binary, metadata, and/or concept as apps submitted to the App Store by other developers, with only minor differences. Next Steps Since we do not accept spam apps on the App Store, we encourage you to review the app concept and submit a unique app with distinct content and functionality. Resources Some factors that contribute to a spam rejection may include: Submitting an app with the same source code or assets as other apps already submitted to the App Store Creating and submitting multiple similar apps using a repackaged app template Purchasing an app template with problematic code from a third party Submitting several similar apps across multiple accounts Learn more about our requirements to prevent spam in guideline 4.3.

I can't seem to find information on this but this is causing a critical bug where the Strong Password suggestion sheet presents on any secure field (UIKit) and clears the others when closing it. This means the user cannot enter a password when there is a secure confirm password field because switching fields clears the other. This looks to be a recent issue but I can't tell when this was introduced or if this is SDK / OS version related. I am finding it in both Xcode 26.2 and 16.4 when running on device (iOS 26.2.1 and XC 26 simulators). Code to reproduce: class ViewController: UIViewController { override func loadView() { let v = UIStackView() v.axis = .vertical v.layoutMargins = .init(top: 16, left: 16, bottom: 16, right: 16) v.isLayoutMarginsRelativeArrangement = true view = v let t1 = UITextField() t1.textContentType = .username t1.placeholder = "Username" v.addArrangedSubview(t1) let t2 = UITextField() t2.isSecureTextEntry = true t2.textContentType = .newPassword t2.placeholder = "Password" t2.clearsOnInsertion = false t2.clearsOnBeginEditing = false t2.passwordRules = nil t2.clearButtonMode = .always v.addArrangedSubview(t2) let t3 = UITextField() t3.isSecureTextEntry = true t3.textContentType = .newPassword t3.placeholder = "Confirm Password" t3.clearsOnInsertion = false t3.clearsOnBeginEditing = false t3.passwordRules = nil t3.clearButtonMode = .always v.addArrangedSubview(t3) v.addArrangedSubview(UIView()) } } No matter what textContentType is used the strong password still forcefully breaks the flow and blocks the user.

Hello, my App DEBRIEF has now already for 15d the status „Waiting For Review“ and nothing is changing. I opened a support ticket under 102880278747 3d ago and got the reply that it should have been checked and it can’t take much longer. I am running ads already for the app and some partners are waiting for the launch. Any Ideas what I can do or is that normal ? What do I need to expect? Apple ID: 6762911498 Bundle ID: com.netcoresolutions.DE-BRIEF

Hello Apple Developer Community, I'm seeing a persistent crash in my iOS app reported via Firebase Crashlytics. The issue only started appearing on devices running iOS 26.3.0 and above (the crash does not occur on lower iOS versions, and it's unrelated to my app's version number). Key points: My app does NOT use any Text-to-Speech (TTS) features whatsoever. No AVSpeechSynthesizer, no Speech framework, no related APIs called from our code. My app is primarily written in Objective-C (with some Swift components possibly via dependencies). The crash stack is entirely within Apple's private TextToSpeech framework, specifically in ausdk::BufferAllocator::instance(). I suspect it might be indirectly triggered by a third-party ad SDK (e.g., Google Mobile Ads, AppLovin, etc.) that could be loading or interacting with accessibility features in the background — but this is just a hypothesis, as I have no direct evidence yet. Here is one representative crash log: Crashed: com.apple.root.user-initiated-qos.cooperative 0 TextToSpeech 0x6bb00 ausdk::BufferAllocator::instance() + 99800 1 TextToSpeech 0xf8c60 ausdk::BufferAllocator::instance() + 677688 2 TextToSpeech 0xf8c60 ausdk::BufferAllocator::instance() + 677688 3 TextToSpeech 0x1a0b9c ausdk::BufferAllocator::instance() + 1365620 4 libswift_Concurrency.dylib 0x628b4 swift::runJobInEstablishedExecutorContext(swift::Job*) + 288 5 libswift_Concurrency.dylib 0x63d28 swift_job_runImpl(swift::Job*, swift::SerialExecutorRef) + 156 6 libdispatch.dylib 0x13f48 _dispatch_root_queue_drain + 364 7 libdispatch.dylib 0x146fc _dispatch_worker_thread2 + 180 8 libsystem_pthread.dylib 0x137c _pthread_wqthread + 232 9 libsystem_pthread.dylib 0x8c0 start_wqthread + 8 The crash occurs on a background cooperative queue (Swift Concurrency). Questions: Has anyone else seen crashes inside ausdk::BufferAllocator::instance() in TextToSpeech on iOS 26.3.0+ even without using TTS in their app? Could a third-party ad SDK be causing the TextToSpeech framework to load unexpectedly (e.g., via accessibility preloading)? Is this a known bug in iOS 26's Spoken Content / Speak Selection features? Any workarounds or fixes from Apple? Any insights, similar reports (especially from Objective-C based apps), or advice would be greatly appreciated! Thanks!

Hello, I am investigating a recurring crash that appears to be originating within the system's network stack. OS Version: iPhone OS 26.1 (23B85) Role: Foreground Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000 Exception Codes: 0x0000000000000001, 0x0000000000000000 Triggered by Thread: 19 Description: The crash is triggered by Thread 19 and occurs deep within libquic.dylib during a QUIC recovery timer event. Based on the backtrace, the failure happens in quic_recovery_pto. The issue seems to occur when a protocol instance schedules a wakeup, leading to a null pointer dereference in the system library. Crashed Thread Backtrace snippet:Thread 19 Crashed: Thread 19 Crashed: 0 libquic.dylib 0x00000001a00a38cc quic_recovery_pto + 72 (quic_recovery.c:1259) 1 libquic.dylib 0x00000001a00a3390 quic_recovery_timer_fired + 132 (quic_recovery.c:1460) 2 libquic.dylib 0x00000001a00a1f8c quic_timer_run + 248 (quic_timer.c:210) 3 Network 0x000000018ec76cbc __nw_protocol_instance_schedule_wakeup_block_invoke + 76 (protocol_implementation.cpp:5847) 4 Network 0x000000018eba34e0 __nw_context_reset_timer_block_with_time_block_invoke + 268 (context.cpp:2224) 5 libdispatch.dylib 0x00000001c84727ec _dispatch_client_callout + 16 (client_callout.mm:85) 6 libdispatch.dylib 0x00000001c845d664 _dispatch_continuation_pop + 596 (queue.c:349) 7 libdispatch.dylib 0x00000001c8470528 _dispatch_source_latch_and_call + 396 (source.c:601) 8 libdispatch.dylib 0x00000001c846f1fc _dispatch_source_invoke + 844 (source.c:966) 9 libdispatch.dylib 0x00000001c8463288 _dispatch_workloop_invoke + 1612 (queue.c:4761) 10 libdispatch.dylib 0x00000001c846c3ec _dispatch_root_queue_drain_deferred_wlh + 292 (queue.c:7265) 11 libdispatch.dylib 0x00000001c846bce4 _dispatch_workloop_worker_thread + 692 (queue.c:6859) 12 libsystem_pthread.dylib 0x00000001ec0623b8 _pthread_wqthread + 292 (pthread.c:2696) 13 libsystem_pthread.dylib 0x00000001ec0618c0 start_wqthread + 8 (:-1) Can anyone provide insights into what might be causing libquic to access an invalid address in this context? Any help or suggestions for further diagnostics would be greatly appreciated.

[SKStoreReviewController requestReviewInScene:] no longer displays the review prompt in debug/development builds on iOS 26.5 beta (23F5043k and 23F5043g). According to Apple's documentation, the review prompt should always appear in debug builds to facilitate testing. This was working in previous iOS versions (iOS 26.4 and older). Steps to reproduce: Run app from Xcode in debug configuration on a device running iOS 26.5 beta (23F5043k or 23F5043g) Call [SKStoreReviewController requestReviewInScene:windowScene] with a valid, foreground-active UIWindowScene Observe that the method executes without error (scene is valid per NSLog) but no review prompt appears Expected: Review prompt should display in debug builds Actual: No prompt appears, despite the scene being valid and foreground-active This worked correctly on previous iOS versions (26.4) so looks like this bug was introduced in 26.5 Beta versions. I have already filed a bug report in Feedback Assistant with number: FB22445620

I'm distributing a Safari Web Extension iOS app via TestFlight (built from a Chrome MV3 extension via xcrun safari-web-extension-converter on Xcode 26.0.1). The extension installs and registers correctly, but its popup never opens when the toolbar item is tapped. The behavior is silent — no error, no flash of UI, no console output. The Safari "ᴀA" menu just closes and the user is back at the article. WHAT WORKS: Extension appears in Settings → Safari → Extensions, can be enabled Permissions can be granted ("Always Allow on Every Website") Extension appears as expected in Safari's "ᴀA" address-bar menu WHAT DOESN'T WORK: Tapping the extension item in the AA menu produces no popup, no error, no visible response of any kind. Same on iPhone and iPad, both on iOS 26. WHAT I'VE VERIFIED VIA IPA INSPECTION: Extension .appex contains: manifest.json, popup.html, popup.js, background.js, content.js, and images/ with all icons _CodeSignature/CodeResources files2 lists 11 entries — every web extension resource is signed manifest declares: "action": { "default_popup": "popup.html", "default_icon": {...} } Extension Info.plist has standard NSExtension dict: NSExtensionPointIdentifier = com.apple.Safari.web-extension NSExtensionPrincipalClass = (My)_Extension.SafariWebExtensionHandler ISOLATION TEST: To rule out my popup code, I replaced popup.html with a 506-byte file containing only a static green box and "Hello World" text — no scripts, no images, no external references. This minimal popup ALSO fails to open with the same silent behavior. So this is not a script error or content issue. MANIFEST DETAILS (relevant excerpts): { "manifest_version": 3, "action": { "default_popup": "popup.html", "default_icon": {...} }, "background": { "scripts": ["background.js"], "persistent": false }, "content_scripts": [{ "matches": ["<all_urls>"], "js": ["content.js"] }], "permissions": ["activeTab", "storage", "scripting"], "host_permissions": ["<all_urls>"] } I previously had "background": { "service_worker": "background.js", "type": "module" } and switched to scripts/non-persistent based on prior forum advice about iOS Safari incompatibility with module-type service workers. No change in behavior either way. ENVIRONMENT: iOS 26 (iPhone and iPad — both affected) Built on macos-15 GitHub Actions runner with Xcode 26.0.1 Distribution via TestFlight Manifest version 3 Extension target produced by xcrun safari-web-extension-converter I cannot easily provide a focused Xcode test project as my entire build pipeline runs on GitHub Actions (no local Mac access at this time). I can share the IPA, build pipeline configuration, and source repository. Has anyone else seen silent popup failures on iOS 26 from converter-built Safari Web Extensions? Is there an Info.plist key, build setting, or NSExtension attribute the converter is missing that's needed for popups to render on iOS 26? Thanks for any insight.

Is there a safeAreaInsets equivalent that only tracks system bars (tab bars, status bars, side bars, toolbars, and navigation bars) and is not affected by notches? I'm asking this because the iPadOS tab bar can appear either on the top, bottom, or left (modally or non-modally) in various configurations, including sidebarAdaptable and when the window size is small on iPadOS; the tab bar's frame is not really reliable in this case, and while the safe area insets works, it also includes the notches / rounded window corners...

I have a brand new iPhone 15 with iOS 17, paired with a watch on WatchOS10. In devices and simulators, the iPhone 15 and Watch 10 device show up as disconnected (with the globe icon I think is what it is?) and if I click on either of them, that icon changes to a spinner, and the main window says "Xcode will continue when the operation completes", but it NEVER completes. This makes the device not usable for development. In addition, I have updated my iPad to iOS17, and it doesn't even show up at all in the devices and simulator list, even though it is enabled for developer mode. I have toggled developer mode off and on (thus rebooting). I have quit and restarted Xcode. I have even rebooted the Mac. Nothing helps. This is incredibly frustrating.

I've just implemented background session downloads, and in testing (with 1044 downloadTasks), I'm seeing some strange behavior that's not 100% reproducible. Sometimes when I background the app, when I foreground it (or the OS does), the URLSessionDownloadDelegate's function urlSession(_:downloadTask:didFinishDownloadingTo:) gets called twice. I'm also logging the URLSessionTaskDelegate's function urlSession(_:task:didCompleteWithError:) and in this case, it does not get called between calls to didFinishDownloadingTo. Both cases are being called with the exactly same task, session and location. The first call copies the location to a semi-permanent destination (and I confirmed that file is correct), and the second call fails on move because the destination already exists. I can obviously work around this fairly easily, but wondering if I'm missing something or if there's a bug. It does appear to happen more reliably when I background for 15 seconds or longer. A second issue which is reproducible is that while backgrounded, some files are completing downloads and never calling the download delegate's urlSession(_:downloadTask:didWriteData:totalBytesWritten:totalBytesExpectedToWrite:) I tried resuming one or all of the tasks in applicationDidBecomeActive as suggested in multiple other forums posts, but neither of those seems to resolve the issue. Again, I can work around this (using a combination of totalBytesWritten and the known size of files which have completed downloads), but I'm wondering if I'm missing something obvious. I actually thought that perhaps the resume() workaround was causing the first issue, but removing it does not have an effect.