The biggest issue is that the QLThumbnailGenerator returns no errors and even returns a representation. So we cannot determine if the representation is valid.

I can also confirm this is only partially fixed in iOS 26 beta 9. It still fails with the same error on some types. For example .strings files: Error returned from iconservicesagent image request: <ISTypeIcon 0x132fcec80> Type: com.apple.xcode.strings-text, Config: (null), Digest:B14B8732-EB60-3CDD-BC18-A1318AC72611 - <ISImageDescriptor: 0x132a3eda0> (220.00, 220.00)@2x v:1 l:5 a:0:0:0:0 t:0:0:0:0 s:2 ps: 0 digest: F75CCEBC-2BD0-3469-89C9-7EAC3379AB72 error: Error Domain=NSOSStatusErrorDomain Code=-609 "Client is disallowed from making such an icon request" UserInfo={NSLocalizedDescription=Client is disallowed from making such an icon request}

@yjogol can confirm iOS 26 beta 9 has this fixed, tested on an iPad mini 5. Folder icons are not rendered though.

Please close this issue since it’s fixed now and it’s going off topic.

Thanks a lot Kevin and all the team. Can confirm the option is there in the beta and works properly and even the FIFinderSyncController.showExtensionManagementInterface() brings the expected panel again.

Finder Sync Extensions seem to be exclusive, the first that applies to a directory stays and no more can be registered to that directory. Since iCloud uses its own Finder Sync Extension, no other can register there. Even worse, the first macOS 15 Sequoia beta does not run any third party Finder Sync Extension, as far as I can test.

Thanks a lot for the detailed explanation Kevin. For mi this is a case close.

Same here. Updated to Xcode 15.4 (from 15.2 I believe).

Sorry Quinn didn't received the notification about the new post. I remember reproducing the crash before but I'll try to reproduce it again tomorrow just to be sure. If you say it does not terminate the app that must be the case, and if it's so, then this is not an issue in cases where the app should be doing that disk intensive tasks. I'm unable to attach a zip here so I've uploaded some xcdiskwritepoint containing the logs: https://d.keka.io/xcdiskwritepoint.zip Thanks for taking the time.

To be clear, a good solution for this will be to get something similar to UIApplication.didReceiveMemoryWarningNotification so we can at least prevent the crash and cancel the operation with an explanation to the user.

Not really, just a template about how to symbolicate and read crash logs. I'm going to contact them again, since I failed to reply the last time and this is still a big issue. Since the last time, I'm now seeing a new limit of 17.18 GB. The lower end device that reported the issue is an iPhone 13 that has a maximum of 512 GB and on the newer side an iPhone 14 Pro Max that has a minimum of 128 GB, so between 128 - 512 we can get that limit. This means nothing, really, since the 1073 MB limit was reported from an iPhone 15 Pro Max that has at least 256 GB.

For macOS 13.0 and iPadOS 16.0 or newer you can use onContinuousHover, although it does not seem to work with the mouse button held down. public func onContinuousHover(coordinateSpace: CoordinateSpace = .local, perform action: @escaping (HoverPhase) -> Void) -> some View

Same here, Xcode 15.0.1, macOS 13.6.1 🥲

4 years later. I'm filling a feature request in the Feedback Assistant. Please consider doing the same if you want this to be fixed.

Similar to https://developer.apple.com/forums/thread/705472, I had to create new certificates and resign all binaries. Probably this was caused by an expired certificate.