Yes, it shows 5/20 on App Store Connect as that was the last time I've changed the pricing, that was displaying correctly. I've changed the tier initially on 5/16, then again on 5/18 (because nothing changed) and again on 5/20, because nothing changed still. Exact dates and changes are available in the ticket. My though process was that perhaps the change didn't come through correctly, because App Store Connect was having issues on 5/17. I've validated the pricing by checking: https://apps.apple.com/us/app/<app-id> On the Mac App Store itself Using SKProduct in the production app (SKProduct.price was simply the old tier) All three showed the old pricing tier for 7 days after initial change. I've checked again today 5/24 and now it is correct on all three channels. Seems like I should've had patience to wait one more day. I don't think it will be helpful to provide the data returned from SKProductsResponse now that the pricing is correct again, but just in case, what kind of data are you expecting? The fields returned in SKProduct? I assume these were all equal to how they are now, except for the price field.

Does anyone see the same problem on macOS 14.7.1? I've received multiple reports from users that macOS 14.7.1 cannot create new bookmarks or resolve existing bookmarks. Same error message: Error Domain=NSCocoaErrorDomain Code=256 "Failed to retrieve app-scope key" UserInfo={NSDebugDescription=Failed to retrieve app-scope key} All users updated from macOS 13.* Ventura to macOS 14.7.1 Sonoma, which triggered the issue Restarting Mac does not fix the issue Clearing all app data does not resolve the issue One user reported that using bookmarks on a new macOS user account works correctly. This leads me to believe that the macOS keychain for their user account is broken. See also https://developer.apple.com/forums/thread/46583 Does upgrading from macOS 13 to macOS 14.7.1 break the keychain?

[quote='815593022, Nickkk, /thread/764435?answerId=815593022#815593022, /profile/Nickkk'] Today I too was contacted by a user who updated from macOS 13 to 14.7.1 and was quite desperate since my app couldn't resolve or create bookmarks anymore. Restarting the Mac didn't help. Thankfully you already reported the same issue so I suggested to update to 15.1.1, which finally solved the issue. [/quote] So far it only seems to happen for users that update from macOS 13. Very strange! I've received multiple confirmations that any of these solutions resolve the issue: Create a new user account (old account will stay bugged) Reset the macOS keychain for the (bugged) user account Update to 15.1+ Resetting the keychain is a bit technical and may cause data loss, so I recommend users to contact Apple Support for help with that.

Thanks for confirming you're seeing the same issue. The difference between responsive scrolling enabled vs disabled is indeed small. You can override scrollWheel(with:) in a custom NSScrollview and output event.scrollingDeltaY and event.momentumPhase. You'll notice a jump when the Phase changes from .none (gesture) to .began (stopped gesture). The final .none event has a zero value for scrollingDeltaY. But the view scrolls way more than expected. ... Event 0.016 -17.0 .none Bounds 0.016 -17.0 Event 0.016 -20.0 .none Bounds 0.016 -20.0 Event 0.016 -26.0 .none Event 0.000 0.0 .none Bounds 0.016 -59.0 <- jump Event 0.018 -29.0 .began Bounds 0.016 -19.5 Event 0.014 -31.0 .changed Bounds 0.016 -18.5 ... The problem is that by overriding scrollWheel(with:) responsive scrolling is implicitly disabled. So these values may not be the same without override (the jump is larger when checking screen recording + responsive scroll). But it is clear that the inertia logic is not smooth when switching from gesture to momentum. Not sure if that's due to "stepped" scrolling (interesting link!) but the custom WebKit implementation is indeed much smoother.

Same issue on macOS 15 Sequoia. CTRunDraw does properly draw the underline on macOS 14 and below, or when using Xcode 15 or below. Using Xcode 16 + macOS 15 CTRunDraw does not draw an underline.

Thanks for your reply, here's the report number: FB17100576 If you need additional info please let me know. Unrelated to the issue: I'd like to express my frustration with the reporting process. I have reported several issues using Feedback Reporter in the past, but almost none of them get an acknowledgement or any reply. Some issues have been fixed, but the reports are still open without any interaction. So I no longer feel like reporting issues, as it appears the work I put into it is not valued. Why bother? In the past personal TSIs were available and very helpful. Now when I try to contact support directly I'm referred to the dev forums to report it, such that other devs can read it. So I report here publicly and I'm again referred to the private Feedback Assistant, where I have to copy and paste what I've already written above. It's an incredibly frustrating experience. I've reported issues to other companies and the difference is night and day, offering personal replies and confirmations. Not sure if I'm the only one dissatisfied, but just wanted to give some feedback. Hope it can be improved.

Thank you for looking into it, very much appreciated. I'm not sure if the errors from the logs you posted are related to the underlying issue. Those same error/exception logs always show up when resolving the first bookmark after app launch, regardless of whether that bookmark resolves/fails. And they also show up on macOS 15. Here are the debug logs for a bookmark that was created before updating to 14.7.5: default 11:20:08.512031+0200 <app-name> Resolving bookmark: <private> debug 11:20:08.512159+0200 <app-name> bookmarkRef=<0x600001b2c660 <private>> options=0x400 relativeToURL=(null) propertiesToInclude=(null) repIsStaleP=0x16db12a58 errorRefP=0x16db12898 debug 11:20:08.512214+0200 <app-name> Client beginning scoped bookmark resolution. debug 11:20:08.512233+0200 <app-name> Resolution request message is prepared and about to be sent to the agent. debug 11:20:08.512612+0200 <app-name> 0x6000036935c0 rule ^Contents$ added (weight 0, flags 0x12) debug 11:20:08.512650+0200 <app-name> 0x6000036937a0 rule ^(\.LSOverride|\.DS_Store|Icon |\.SoftwareDepot\.tracking)$ added (weight 0, flags 0x9) debug 11:20:08.512666+0200 <app-name> entering /Users/user/Desktop/<app-name>.app debug 11:20:08.512703+0200 <app-name> entering /Users/user/Desktop/<app-name>.app/Contents debug 11:20:08.512713+0200 <app-name> leaving /Users/user/Desktop/<app-name>.app/Contents debug 11:20:08.512721+0200 <app-name> leaving /Users/user/Desktop/<app-name>.app debug 11:20:08.512881+0200 <app-name> open(/Users/user/Desktop/<app-name>.app/Contents/MacOS/<app-name>,0x0,0x1b6) = 34 debug 11:20:08.512919+0200 <app-name> open(/Users/user/Desktop/<app-name>.app/Contents/MacOS/<app-name>,0x0,0x1b6) = 35 debug 11:20:08.512933+0200 <app-name> 0x60000369a620 is a thin file (arm64) debug 11:20:08.512943+0200 <app-name> close(34) err: 0 debug 11:20:08.513209+0200 <app-name> 77006 signing bytes in 5 blob(s) from /Users/user/Desktop/<app-name>.app/Contents/MacOS/<app-name>(arm64) debug 11:20:08.513361+0200 <app-name> failed to fetch /Users/user/Desktop/<app-name>.app/Contents/_CodeSignature/CodeRequirements-1 error=-10 debug 11:20:08.513381+0200 <app-name> SecStaticCode network default: YES debug 11:20:08.513437+0200 <app-name> close(35) err: 0 default 11:20:08.513464+0200 <app-name> [0x600002a93930] activating connection: mach=true listener=false peer=false name=com.apple.scopedbookmarksagent.xpc debug 11:20:08.513870+0200 ScopedBookmarkAgent (peer pid=1119) new peer connection. default 11:20:08.513921+0200 ScopedBookmarkAgent [0x14d005080] activating connection: mach=false listener=false peer=true name=com.apple.scopedbookmarksagent.xpc.peer[1119].0x14d005080 debug 11:20:08.513986+0200 ScopedBookmarkAgent (peer pid=1119) peer sent message. message_type=reso debug 11:20:08.514010+0200 ScopedBookmarkAgent Handling resolution of a scoped bookmark. debug 11:20:08.514027+0200 ScopedBookmarkAgent Collection file descriptor missing or unresolvable, inferring app scope. debug 11:20:08.514072+0200 ScopedBookmarkAgent bookmarkRef=<0x14d106ad0 <private>> options=0x8000400 relativeToURL=<private> propertiesToInclude=(null) repIsStaleP=0x16bd09420 errorRefP=0x16bd092d8 debug 11:20:08.514137+0200 ScopedBookmarkAgent CFURLCreateByResolvingBookmarkData failed with error [Error Domain=NSCocoaErrorDomain Code=259 "app-scope or collection-scope key doesn't match the key in the bookmark" UserInfo={NSDebugDescription=app-scope or collection-scope key doesn't match the key in the bookmark}]. debug 11:20:08.514167+0200 ScopedBookmarkAgent (peer pid=1119) sent reply to peer. debug 11:20:08.514213+0200 <app-name> Received agent reply. debug 11:20:08.514225+0200 <app-name> No resolved path present in agent reply, aborting. default 11:20:08.514254+0200 <app-name> [0x600002a93930] invalidated after the last release of the connection object default 11:20:08.514313+0200 ScopedBookmarkAgent [0x14d005080] invalidated after getting a no-senders notification - client is gone debug 11:20:08.514594+0200 <app-name> Bundle: <private>, key: <private>, value: (null), table: FoundationErrors, localizationNames: (null), result: The file couldn’t be opened because it isn’t in the correct format. debug 11:20:08.514767+0200 <app-name> Bundle: <private>, key: <private>, value: (null), table: FoundationErrors, localizationNames: (null), result: The file couldn’t be opened because it isn’t in the correct format. debug 11:20:08.516128+0200 <app-name> Bundle: <private>, key: <private>, value: (null), table: FoundationErrors, localizationNames: (null), result: The file couldn’t be opened because it isn’t in the correct format. default 11:20:08.516151+0200 <app-name> Resolving bookmark fail: Error Domain=NSCocoaErrorDomain Code=259 --- <private> This seems related to r.140342863 — Has the app scope key changed in 14.7.5? The key from the old bookmark does not seem valid anymore. Logs for a new bookmark that succeeds, and the raw bookmark data in case it's useful are available here: https://gist.github.com/floorish/37f972c5411fa61025fbfbe114a84b35 I haven't tried resolving without security scope, but that is not useful in this case since the app already knows the path(s) which are stored separately. The app needs read/write access to these locations and the user may have imported multiple locations. It is possible to restore access by using the open panel again, but that is exactly what I want to prevent. Bookmark data is supposed to give persistent access to a user opened location, isn't it? -- Regarding the issue reporting process: I'll keep this short since I don't want to lose focus from the original issue. I understand it and I just wanted to give my feedback. I really do appreciate you being here and actively interacting with posts, in particular this one, that's much appreciated. But it's hit or miss, some posts are just ignored, either here or in Feedback Reporter.

Thanks for the info! It's not entirely clear to me when exactly this issue can occur, so I have a few more questions if you don't mind. I have not received any bookmark related issue reports from users updating to 14.7.3 and 14.7.4. That could be a coincidence, but I assumed that the ScopedBookmarkAgent worked correctly since 14.7.3. I've also updated a VM from 14.4.0 to 14.7.5 and the app scope key was changed, so the self repair was apparently triggered. Does this mean that the underlying issue (or some other issue) is back again in 14.7.5? Or was it never really fixed? Is self repair considered an expected flow or is it a last-resort fallback mechanism in case there is still an unexpected bug? In other words: since self repair appears to be necessary for some users in 14.7.5, does that mean there is an unexpected issue that needs to be fixed? Is it expected that the self repair may be necessary again for users when updating to future macOS 14.*.* versions? Does the same apply for macOS 15.1+ ? If self repair and therefore a key reset is expected then I have to seriously consider not using the App Sandbox. Because it will be very inconvenient if users have to potentially open their locations manually again on each macOS update. -- I'm aware of the "isStale" mechanism, but those bookmarks are automatically recoverable by an app without user interaction. So I still consider that "persistent" access — it's actually a really nice feature.

Thanks for taking the time to explain in more detail. So if I understand correctly 14.7.4 contains the key copy code, but 14.7.5 does not anymore. Therefore if a user skips over 14.7.4 they'll (potentially or always?) get a new key. If a user is on 14.7.4 or above the key is already in the correct keychain, so no key change is expected anymore. So far I've received issue reports after the following updates: 13.7.4 -> 13.7.5 13.7.4 -> 14.7.5 14.7.* -> 14.7.5 (not certain if previous version was 14.7.4 or below) If I assume that 13.7.4 includes the key copy code similarly to 14.7.4, then those reports coming from 13.7.4 are a bit unexpected since the existing key should've been copied. But to be honest I've received fewer reports than I initially expected, so that is a relief. [quote='833730022, DTS Engineer, /thread/779247?answerId=833730022#833730022'] which does create more scenarios which could force you to recreate the keychain. [/quote] I was pretty reassured until that :) Should I be worried about this? What would be a scenario that would trigger that? When this happens I assume that existing bookmarks are not valid anymore. So allowing the user to reopen/recreate the bookmarks would be the only solution?

[quote='834012022, DTS Engineer, /thread/779247?answerId=834012022#834012022'] but you'd already have the same problem today if you manually transferred data and did not move the keychain. [/quote] Understood. It looks like the data protection keychain should transfer when it's synced by iCloud, but not if it's local only — is that correct? Thanks again for sharing your knowledge.

OK that might indeed cause some confusion for users. Hopefully that can be improved in a future update. Thanks, appreciate the support!