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.