I am seeing the same problem with iOS 16, including with the release candidate. I am getting a slightly different error message, probably because we are trying to get the thumbnails from within our own app. For files stored in iCloud (ubiquitous container) I am seeing this error: Error Domain=QLThumbnailErrorDomain Code=3 "No thumbnail in the cloud for file:///private/var/mobile/Library/Mobile%20Documents/iCloud~com~pixite~Zinnia/Documents/Journals/Untitled%2011.zinnia/pages/0B10F371-94FB-4658-9333-04C9C9D81163.zinniapage" UserInfo={NSErrorFailingURLKey=file:///private/var/mobile/Library/Mobile%20Documents/iCloud~com~pixite~Zinnia/Documents/Journals/Untitled%2011.zinnia/pages/0B10F371-94FB-4658-9333-04C9C9D81163.zinniapage} For files in local storage, I see this error: Error Domain=QLThumbnailErrorDomain Code=0 "Could not generate a thumbnail" I also filed a bug at the beginning of August (FB11011263) but have received no response. Before that I opened a DTS ticket about it, and they eventually just told me to file a bug. So apparently they know it is a bug on their end. This is actually completely crippling our app on iOS 16, because the users can't tell which of their documents are which without working thumbnails.

And I should note that when using iCloud (ubiquitous container), we get a different thumbnail error when we initially create the document: Error Domain=NSCocoaErrorDomain Code=4101 "Provider returned unsupported error" UserInfo={NSDebugDescription=Provider returned unsupported error, NSUnderlyingError=0x2811fd920 {Error Domain=CKErrorDomain Code=11 "<CKError 0x102f0d760: "Unknown Item" (11/2003); server message = "Record not found"; op = B21EB1404E50EF3F; uuid = 46519FDB-FB10-48FF-B736-93650812BA45; container ID = "com.apple.clouddocs">" UserInfo={ContainerID=com.apple.clouddocs, NSDebugDescription=<CKError 0x102f0d760: "Unknown Item" (11/2003); server message = "Record not found"; op = B21EB1404E50EF3F; uuid = 46519FDB-FB10-48FF-B736-93650812BA45; container ID = "com.apple.clouddocs">, OperationID=B21EB1404E50EF3F, RequestUUID=46519FDB-FB10-48FF-B736-93650812BA45, errorKey=ckvneous, ServerErrorDescription=Record not found, CKErrorDescription=Error fetching record <CKRecordID: 0x101231ae0; recordName=documentContent/73A97D26-23B8-46CD-B326-51DCC94477EC, zoneID=iCloud.com.pixite.Zinnia:__defaultOwner__> from server: Record not found, NSLocalizedDescription=Error fetching record <CKRecordID: 0x101231ae0; recordName=documentContent/73A97D26-23B8-46CD-B326-51DCC94477EC, zoneID=iCloud.com.pixite.Zinnia:__defaultOwner__> from server: Record not found, NSUnderlyingError=0x2811ff360 {Error Domain=CKInternalErrorDomain Code=2003 "<CKError 0x102f31be0: "Unknown Item" (2003); server message = "Record not found"; op = B21EB1404E50EF3F; uuid = 46519FDB-FB10-48FF-B736-93650812BA45; container ID = "com.apple.clouddocs">" UserInfo={ContainerID=com.apple.clouddocs, OperationID=B21EB1404E50EF3F, NSDebugDescription=<CKError 0x102f31be0: "Unknown Item" (2003); server message = "Record not found"; op = B21EB1404E50EF3F; uuid = 46519FDB-FB10-48FF-B736-93650812BA45; container ID = "com.apple.clouddocs">, RequestUUID=46519FDB-FB10-48FF-B736-93650812BA45, errorKey=ckvneous, ServerErrorDescription=Record not found, CKErrorDescription=Error fetching record <CKRecordID: 0x101231ae0; recordName=documentContent/73A97D26-23B8-46CD-B326-51DCC94477EC, zoneID=iCloud.com.pixite.Zinnia:__defaultOwner__> from server: Record not found, NSLocalizedDescription=Error fetching record <CKRecordID: 0x101231ae0; recordName=documentContent/73A97D26-23B8-46CD-B326-51DCC94477EC, zoneID=iCloud.com.pixite.Zinnia:__defaultOwner__> from server: Record not found}}}}}

For anyone else struggling with this error, the problem is that Mac requires the build number to be higher across versions. Here is the relevant text: Important: For macOS apps, build numbers must monotonically increase even across different versions. In other words, for macOS apps you cannot use the same build numbers again in different release trains. iOS apps have no such restriction and you can re-use the same build numbers again in different release trains. From this tech note: https://developer.apple.com/library/archive/technotes/tn2420/_index.html#//apple_ref/doc/uid/DTS40016603-CH1-HOW_THESE_NUMBERS_WORK_TOGETHER Confusingly, it did let me reuse a build number one time, but then balked after that.

Just to follow-up on this, the CFURLEnumerator version of this does actually work correctly, so I think there is a bug in FileManager.DirectoryEnumerator. I'll be filing a feedback.

I am experiencing the same crash, and have submitted a feedback with a crash report. FB14607400

I think that particular trace is from a slightly older version, and that line was: return metadataQuery.results.compactMap { ($0 as? NSMetadataItem)?.url } We have since changed it to the version below, thinking that if a mutation was occurring in another thread that copying it first might avoid the crash (it didn't help): let results = metadataQuery.results return results.compactMap { ($0 as? NSMetadataItem)?.url }

Is the issue that results is not a real Swift array, but rather a bridged mutable ObjC array that is getting mutated concurrently in another thread? If so, how would we avoid this crash? The docs for results say: Accessing this property implicitly disables updates, and enables updates again once the resulting array is deallocated. So my assumption was that other threads should not be mutating it while I am accessing it.

We create the queue like this: dispatchQueue = DispatchQueue(label: "com.XXX.XXX.DocumentBrowserQuery", qos: .utility, autoreleaseFrequency: .workItem) workerQueue = OperationQueue() workerQueue.name = "com.XXX.XXX.workerQueue" workerQueue.qualityOfService = .utility workerQueue.maxConcurrentOperationCount = 1 workerQueue.underlyingQueue = dispatchQueue metadataQuery.operationQueue = workerQueue

I attached the entire implementation of our DocumentBrowserQuery to FB14607400, in case that is helpful.

First off, thank you so much for all the info you have provided. This has been incredibly helpful. I may be able to change getAllResults() to be an async method, in which case I can just do an async dispatch to dispatchQueue instead, which feels pretty safe. I will look into that. Barring that, what if I manually called disableUpdates() before accessing results? I know that results is already supposed to be doing that automatically, but is that maybe not happening somehow? Or do you think it is properly doing that, and the concurrency issue lies elsewhere?

Just to followup on this, changing the code to only access the NSMetadataQuery.results from its operationQueue seems to have fixed the crash. Previously we were consistently getting 5-15 crash reports per week for this issue. But in the 17 days since we released the new version, we haven't seen any crashes from this.

I have filed this as a feedback: FB20372585

I realize that I missed including the warnings about inaccessible directories, which are printed immediately before the first error I included above: warning: /Users/natetemp/Library/org.swift.swiftpm/configuration is not accessible or not writable, disabling user-level cache features. warning: /Users/natetemp/Library/org.swift.swiftpm/security is not accessible or not writable, disabling user-level cache features. warning: /Users/natetemp/Library/Caches/org.swift.swiftpm is not accessible or not writable, disabling user-level cache features.