UIDocumentPickerViewController provides corrupt copy of file when user taps multiple times on file

We're trying to implement a backup/restore data feature in our business productivity iPad app using UIDocumentPickerViewController and AppleArchive, but discovered odd behavior of [UIDocumentPickerViewController initForOpeningContentTypes: asCopy:YES] when reading large archive files from a USB drive.

We've duplicated this behavior with iPadOS 16.6.1 and 17.7 when building our app with Xcode 15.4 targeting minimum deployment of iPadOS 16. We haven't tested this with bleeding edge iPadOS 18.

Here's our Objective-C code which presents the picker:

NSArray* contentTypeArray = @[UTTypeAppleArchive];
UIDocumentPickerViewController* docPickerVC = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypeArray asCopy:YES];
docPickerVC.delegate = self;
docPickerVC.allowsMultipleSelection = NO;
docPickerVC.shouldShowFileExtensions = YES;
docPickerVC.modalPresentationStyle = UIModalPresentationPopover;
docPickerVC.popoverPresentationController.sourceView = self.view;
[self presentViewController:docPickerVC animated:YES completion:nil];

The UIDocumentPickerViewController remains visible until the selected external archive file has been copied from the USB drive to the app's local tmp sandbox. This may take several seconds due to the slow access speed of the USB drive. During this time the UIDocumentPickerViewController does NOT disable its tableview rows displaying files found on the USB drive. Even the most patient user will tap the desired filename a second (or third or fourth) time since the user's initial tap appears to have been ignored by UIDocumentPickerViewController, which lacks sufficient UI feedback showing it's busy copying the selected file.

When the user taps the file a second time, UIDocumentPickerViewController apparently begins to copy the archive file once again. The end result is a truncated copy of the selected file based on the time between taps. For instance, a 788 MB source archive may be copied as a 56 MB file. Here, the UIDocumentPickerDelegate receives a 56 MB file instead of the original 788 MB of data.

Not surprisingly, AppleArchive fails to decrypt the local copy of the archive because it's missing data. Instead of failing gracefully, AppleArchive crashes in AAArchiveStreamClose() (see forums post 765102 for details).

Does anyone know if there's a workaround for this strange behavior of UIDocumentPickerViewController?

Did you file a bug about this already?

If not, I recommend that you retest on iOS 18 and, if it’s still a problem there, file a bug.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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.

UIDocumentPickerViewController provides corrupt copy of file when user taps multiple times on file
 
 
Q