@alanfromtewksbury  Hello! Would you agree to share what you found about IODPDevice? Don't have M1 to test, so it would help a lot. My app is using IODisplayCreateInfoDictionary from IODisplayConnect, but if I iterate to IODPDevice, what's the structure I will found? Thanks

Big Sur 11.4 has been released, and I've got the same issue with one of my apps. This app includes an Helper Tool (a bundle), that is embedded in the LoginItems subfolder. Before updating to 11.4, if user granted Full Disk Access to the main app, the Helper Tool got Full Disk Access too, as stated here by eskimo: https://developer.apple.com/forums/thread/107546 But now, it's not working anymore. The Helper Tool doe not inherit from the main app, either the Full Disk Access but also the authorisations like Automation for Finder. Did someone find a solution to this?

Big Sur 11.4 has been released, and I've got an issue with one of my apps. This app includes an Helper Tool (a bundle), that is embedded in the LoginItems subfolder. This helper tool is launched thanks to the SMLoginItemSetEnabled API. Before updating to 11.4, if user granted Full Disk Access to the main app, the Helper Tool got Full Disk Access too, as stated by eskimo. But now, it's not working anymore. The Helper Tool does not inherit from the main app, either the Full Disk Access but also other authorisations like Automation for Finder. Did someone find a solution to this?

Thanks for you reply. I've received 3 reports from users about the Full Disk Access issue (and also Automation inheritance that is broken). However, restarting the Mac did not fix the issue, and I'm testing the app on a different Mac, with only one copy of the app :(

Whooo just discovered there's something wrong with the Trash! When I use the Finder to move files to the Trash, they don't go to /Users/myusername/.Trash (as usual) but in /Users/myusername/Library/Group Containers/group.com.apple.Photos.PhotosFileProvider/File Provider Storage/photospicker/.Trash That's why my code is not working. Can't find a way to get rid of this bug...

NSPrefersDisplaySafeAreaCompatibilityMode should not be required for most regular apps. If you use standard API to go fullscreen, there's nothing to do on your side. The app will be displayed just below the notch. But I agree, there's a lot of confusion.

I can confirm that latest beta does not allow to bookmark the root folder "/" for later access. This leads to an error "The file couldn’t be opened.". Do you know if this will be fixed before the RC version of macOS?

Thanks for your detailed answer, and your workaround. I hope you'll find a way to fix this issue ASAP 🙏

Excatly the same issue with the same code used for years. Tested on macOS 26.0, 26.1 and 26.2 RC. My app is sandboxed, and access to the files is made through the NSOpenPanel first (Macintosh HD folder). Same log message and behavior: takes a long time. Can a DTS engineer tell us what's going wrong?

By the way, I've tested the QLPreviewView and It's also affected by the same issue! So instead of using QLPreviewPanel, we could generate the thumbnail with QLThumbnailGenerator and then display the result in our app? It seems a lot of work for something Apple should fix 😅