Will be fixed with macOS 15.1, according to this thread: https://forums.developer.apple.com/forums/thread/764435?answerId=806097022#806097022

Because my other thread ( https://forums.developer.apple.com/forums/thread/765433 ) is not getting any response to this pressing matter, please forgive me reviving this older thread. Has there been a change to security-scoped fileURL bookmarks in macOS Sequoia (like a new entitlement, for example)? I've been getting multiple reports of my app just not being able to create security-scoped bookmarks for file URLs, although my code for this has not changed. There are two cases: for some customers, it doesn't work at all, for others, it works (to quote one) "like 40% of the time". There's no discernible pattern to it working or failing (like, internal/external disks, file types, etc). Naturally, I cannot reproduce this issue myself, but I do know that it's not just the Mac App Store version, it also happens for my demo and Setapp versions of the app (which also run in the app sandbox). When the bookmark creation fails, it is accompanied by this line in the logs: Failed to retrieve app-scope key A restart fixes the issue temporarily (most but not all of the time), sometimes even just a relaunch of my app. But that's just an annoying temporary fix, and the issue reoccurs after a while. It definitely seems to be tied to macOS Sequoia - I've not received reports of it not working on older versions of macOS. Thank you for any and all insights, – Matthias

Is there a bug with security-scoped bookmarks on macOS Sequoia? I don't think anything could have changed with entitlements, since it all works on my Macs. I also just got a report about my app Transloader that apparently can no longer hold references to user-selected apps for its Link and File actions (on that user's Mac - again, for me, it all works).

The original issue remains, however, that I'm suddenly getting multiple reports daily of some of my apps (ScreenFloat, Yoink), suddenly being shown as damaged and needing to be re-downloaded from the Mac App Store. Happening on macOS 15, 14, 13, 12, 10.14 so far. What puzzles me is that this is not a Sequoia-only thing, where I'd understand if suddenly my receipt validation code would fail due to changes, but it's happening on older systems, too, where receipt validation has never been a problem before. Perhaps it has to do with this log message a customer shared with me: standard 12:58:40.391649+0200 storelegacy StoreLegacy: Failed to perform in-line receipt renewal for application at path /Applications/Yoink.app : '(null)' I'm starting to think it's not my receipt validation code that's responsible here, as it works on all my Macs, all on different systems, all downloaded from the Mac App Store. So, any pointers highly appreciated - thank you.

But if this is true: " The persistent storage for cached app transactions isn't directly accessible from your app " how could this be a scenario: " someone may have copied a valid app transaction from one Mac, and then tried to install it on another Mac " If I just copy a Mac App Store downloaded app from one Mac to another, and the relevant transaction is not part of the app's bundle, how would it transfer with the copy?

sorry to revive this year-old post, but has this been resolved with subsequent releases of macOS?

Thank you, Quinn. Should I re-post this original question in App & System Services > StoreKit, or can I move it there?

Thank you, I'll try that. I have a few other questions regarding receipt validation: Does Sequoia's MAC address randomization affect receipt validation, when using IOKit to get the kIOEthernetInterfaceClass objects and their addresses? Using AppTransaction, does that require the customer to be always online for it to work? Is the data AppTransaction needs automatically downloaded during the app install from the Mac App Store, or only on first launch (requiring an internet connection)? Once that data has been downloaded by AppTransaction, is it cached until the app's next update, or is that data cleared at some time during the version's life and needs to be re-downloaded (therefore requiring an internet connection during launch)? – Matthias

I cannot say - my customers only report to me about my app failing. Let's assume it's just mine. I haven't changed anything in my receipt validation code in quite a while, so it's weird that all of a sudden these reports come in, is it not? And not just for macOS 15, but for older systems as well?

I see, but I don't want to offer a fixed list of all possible intervals, I just want to be able to restrict the user from being able to select all offered UnitDurations (milliseconds, picoseconds, microseconds, nanoseconds, seconds, minutes, hours) to just two: seconds and minutes. I don't see how I can accomplish this with a DynamicOptionsProvider. Thank you for your help.

Thank you for the info. But I doubt key-loggers are using the RegisterEventHotKey API for every possible combination of special characters. There are so many easier ways to accomplish this. I doubt this change had anything to do with security or user-safety. It's just yet another change where Apple oversteps its bounds to prevent users from configuring and using their own computers the way they want to, if you ask me. Edit: and of course, Apple's own keyboard shortcuts are exempt from this restriction (see screenshot)

Any insights?

Using screencapture seems to have been fixed in macOS 15b5. Of course, now that I've spent a week and a half re-implementing this stuff. Well, I guess I have a fallback now should anyone decide that screencapture is off-limits once and for all. But don't get me wrong, I'm very glad it's working again. Thanks for all your help.

sample project now attached to FB14587060 . (tested it with proper signing, of course, even better, as a Developer-ID Distributed, Notarized App) (can't currently reproduce this issue after every relaunch of the app, but after every restart of the Mac, it asks and asks and asks).

Sequoia b4 asks after every relaunch of the app and every restart of the Mac if I want to "Continue to allow" screen recording permissions for every app I gave it to. This is completely insane and will drive users absolutely raging mad. (FB14587060)