We recently updated our app to utilize the work-around suggested by Kevin Elliott. We're happy to report this work-around operates correctly with a USB drive on an iPad running iPadOS 18.6. Thus, we marked his answer as "accepted". Specifically, our app now uses asCopy:NO when initializing UIDocumentPickerViewController. Our code then calls NSFileManager, which copies the selected file as a security-scoped resource to a local (i.e., private) folder in NSTemporaryDirectory(). Our app then processes this local file as before. We added a new phase to the beginning of our progress meter, which informs the user their selected file is being copied to the device. We appreciate Kevin's insight on this topic and his ability to point us in the right direction! As requested, we updated FB16131472 to show the asCopy:YES variant is still broken on iPadOS 18.6.2.

Thank you for responding! We'll look into your suggestion. Our app utilizes AppleArchive to back up and restore data via UIDocumentPickerViewController. We implemented the variant of UIDocumentPickerViewController that copies the archive file because we had the impression Apple recommended (or required) this variant when reading archives from an external drive. We requested Developer Technical Support in February 2025. At that time, we were told there was no workaround. In March 2025 we received a follow-up response from DTS, but it didn't point us in a worthwhile direction. As described in this thread, we filed FB16131472 back in December 2024 regarding iPadOS 18.2. We recently ran the sample code supplied with FB16131472 using iPadOS 18.6, and got the same incorrect results as in iPadOS 18.2. Should we file a separate bug report, or extend FB16131472 with iPadOS 18.6 info?

We confirmed this bug still exists in iPadOS 18.6. It appears Apple has no interest in following their own Human Interface Guidelines regarding long load times: https://developer.apple.com/design/human-interface-guidelines/loading# https://developer.apple.com/design/human-interface-guidelines/progress-indicators UIDocumentPickerViewController doesn't provide any UI feedback (eg., spinner or progress meter) while slowly copying the selected file from the USB drive, nor does UIDocumentPickerViewController disable the UI buttons after the selection. These two shortcomings result in this iOS framework bug.

We confirmed this bug still exists in iPadOS 18.6.

This bug also appears when running on macOS Sequoia 15.2 as an Apple-silicon Mac App (Designed for iPad) built with Xcode 16.2. We filed a bug since this occurs on the latest available version of iPadOS (18.2) and macOS (15.2) when built with the latest Xcode (16.2): https://feedbackassistant.apple.com/feedback/16136753

We ran our test code on iPadOS 18.2 when built with Xcode 16.2. UIDocumentPickerViewController produced the same incorrect behavior so we filed a bug: https://feedbackassistant.apple.com/feedback/16131472 Note: [UIDocumentPickerViewController initForExportingURLs: asCopy:YES] has as similar bug as [UIDocumentPickerViewController initForOpeningContentTypes: asCopy:YES]; namely, it doesn't disable the widgets after the Save button is tapped. Thus, the user can try to save the file in multiple locations on the USB drive -- generating undefined results on the USB drive.

We ran our test code on iPadOS 18.2 when building with Xcode 16.2. We are happy to report the AppleArchive code now fails gracefully in lieu of crashing. Similarly, the WWDC21 'EncryptingAndDecryptingDirectories' Swift sample project now fails gracefully in lieu of crashing when executed on macOS Sequoia 15.2 when built with Xcode 16.2. In other words, the refactored streaming code is performing correctly (as best we can tell). We'd like to know if we need to limit our app's backup/restore data feature to iPadOS 18 and later. Does Apple have plans to fix the AppleArchive crash in iPadOS 16 or 17?

Unfortunately, we're not set up to test the bleeding edge iOS 18. In the past we've been burnt by bugs in the initial releases of iOS, which prevented us from updating our apps for our customers using older versions of iOS. Our customers place a premium on dependable, reliable productivity software so they're unlikely to upgrade to iOS 18 until it's proven to be stable. Unlike Apple, we're a small company with limited resources. We'll gladly test iOS 18 for this bug if Apple sends us a complementary Mac and iPad so we can install Apple's bleeding edge tools without affecting our existing work computers.

We haven't filed a bug yet as we were told to post on the forums first. Unfortunately, we're not set up to test the bleeding edge iOS 18. In the past we've been burnt by bugs in the initial releases of iOS, which prevented us from updating our apps for our customers using older versions of iOS. Our customers place a premium on dependable, reliable productivity software so they're unlikely to upgrade to iOS 18 until it's proven to be stable. Unlike Apple, we're a small company with limited resources. We'll gladly test iOS 18 for this bug if Apple sends us a complementary Mac and iPad so we can install Apple's bleeding edge tools without affecting our existing work computers.