Good news: The issue "NSRulerView is obscuring content in full screen" seems to be fixed with macOS 26.2 Beta. Thanks for the feedback on my bug report, Apple team! ☺️

I'm still unsure if the different color of horizontal ruler views is a bug or the intended design under macOS 26. Therefore, I filed a DTS incident (Apple Developer Technical Support, TSI), asking for a way to customize an NSRulerView's background color...

Okay, let's try to sort this out a bit - I was confused facing a couple of different issues: NSRulerViews are showing inconsistent Backgrounds: With macOS 26 NSRulerViews are showing a very different layout, not only in contrast to prior macOS versions, but also inconsistent between horizontal and vertical rulers. I filed a corresponding bug report (FB20342342) The horizontal ruler view is showing with a solid color. I assume the color is selected based on the first line of the inner view, because with a transparent content view the scrollview's background color is used, otherwise the content view's background color. The vertical ruler view is using a much lighter or transparent version of the content view's background, what I would consider the intended (and expected) behavior. NSRulerView is obscuring content in full screen: Custom apps are facing an incorrect behavior of NSRulerViews when running in full screen: The height of the horizontal ruler is increased, obscuring the top of the clipview. I observed this issue with one of my apps, but was able to replicate it with a minimal sample app, using a scrollable text view with rulers, refer to the attached screenshots. Again, I files a bug report (FB20342122) Window mode: Full Screen:

Hi Quinn! That's what I did and ... surprise! Thank you!

Unfortunately, the filed bug report was not acknowledged by Apple - it is still open, no feedback or status report was given, and macOS 26 "Tahoe" was shipped with the very same issue. @DTS Engineer : Quinn, you should know that I value your contributions in this forum the highest ... but I see a pattern when looking at my bug reports: After migrating from RADARs to the Feedback Assistent, almost all of them are lacking substainable feedback by Apple. Maybe something you can address internally...?

Of course I was referring to "squircles" ... my bad!

Seems to be resolved with beta 5...

I just realized that the attribute "com.apple.provenance" was set for the file in question, too. According to some blog article at eclecticlight.co it might cause the quarantine to be reestablished (only an assumption). Still no idea why a newly created localization file requires quarantine... I've removed this attribute as well - wait and see.

It might be me - most likely it is - but I'm not able to debug my macOS Preview extensions either: I launch the app with the embedded appex from Xcode in debug mode. When trying to attach to the appex process the following error is reported: Domain: IDEDebugSessionErrorDomain Code: 6 Failure Reason: Ensure “AppName Preview” is not already running, and matthias has permission to debug it. User Info: {... } -- System Information macOS Version 15.4.1 (Build 24E263) Xcode 16.3 (23785) (Build 16E140) Timestamp: 2025-05-12T14:07:14+02:00 I'm using a standard user account (no admin) and might miss some obvious steps. Can someone detail the steps to debug a Preview (or Thumbnail) extension with Xcode 16? For legacy Quick Look plugins I was using "qlmanage", but that's not working on extensions... All the best, Matthias

Problem solved! I created a small sample project with a similar construction which just worked: Even async functions could access the class property, while my StoreManager received the following error: Passing closure as a 'sending' parameter risks causing data races between code in the current task and concurrent execution of the closure. By defining StoreManager class as a @MainActor, access to the mentioned property is possible across threads. All asynchronous / delaying work is done in threads, so I'm fine with forcing the StoreManager to the main thread, no performance impact can be observed. I assume (!) my sample code was just working as its functions were located in a UIViewController, residing on the main thread anyway. But that's only an (educated) guess...

Hi Quinn, [quote='820522022, DTS Engineer, /thread/772090?answerId=820522022#820522022'] It sounds like you have a mix of Swift and Objective-C, and some of those clients are in Objective-C. Is that right? [/quote] Exactly! Actually, most of those clients are currently Objective-C classes because StoreKit2 as Swift-only is the main reason to migrate StoreManager. I totally agree to your mention of a "snapshot" - that's what I meant when calling the array a kind of cache, for the lack of better words: It only provides the "point-in-time" state of purchased products, and all clients are notified via NSNotificationCenter when their data was updated. Access to the array property is always in sync calls without blocking / waiting for any asynchronous call to finish.

Just to close this thread: DTS has confirmed the mentioned behavior and there is no solution. Currently, system-wide default UTIs are given priority - a different approach might be to prefer UTIs defined by installed apps. A bug report is required to request an architectural change - how likely this might be. I won't pursuit further as I've filed a very similar request a decade ago regarding macOS...

Apple DTS has confirmed that there is no supported way to programmatically set the active NSColorList in an NSColorPanel. The sort order of color lists will be further addressed following my bug report - I won't hold my breath. The TSI has been refunded...

FYI, the issue of NSColorLists being randomly ordered in NSColorPanel was already reported as an issue in October 2023 (FB13311179), still open and uncommented.

My mistake - I hadn't covered an edge case well (NSString operations with paths). Problem solved.