This is a tricky one. I have a shipping product which, when compiled under Xcode 14.3.1 works as expected on Sonoma. If the same project is recompiled with Xcode 15, the subclass of NSTextView will not display correctly (text is same color as background). I am also using a custom NSLayoutManager (to draw invisibles). Unfortunately, there is an intermittent aspect to this. I use this subclass in several places and it works on my setup on the main editor, but not with some customers. Then I found a different use of the same subclass that does not work for me. When it does not work, it is consistent for that user. I have manually marked the textViews as using TextKit 1, with no change. I also tried the Clips Bounds to yes, again no change. If I change the class to NSTextView, the text displays properly, but I lose existing functionality. There appears to be some undocumented behavior change in Xcode 15 (or when linking against Sonoma SDK) that for subclasses of NSTextView (stored in XIB files). I know that there is a push to move toward TextKit 2, but it seems TextKit 1 support was possibly changed as well. The text is there and I can edit it, double click, copy and paste it, it is just invisible, when compiled with Xcode 15 (also 15.1). It has to be something very subtle that the subclassed TextView from one XIB will work, but from another XIB will not. Does anyone have any insight into the potential change with TextKit 1 implementation? Thanks.

The documentation still says NSApp.setActivationPolicy(.regular) is supported, but not NSApp.setActivationPolicy(.accessory). Obj-c header says that after 10.9, there are no restrictions on this (i.e. you can change policy to and from accessory). I've been targeting 10.11, so no problems expected.While working on a project with the beta/initial releases of Xcode 8/Swift 3, it all seemed to go fine. I came back to work on the project now and it all seems to have gone south. Now, when I switch the app via NSApp.setActivationPolicy(.accessory) and later try to change it back via NSApp.setActivationPolicy(.regular), it fails. The result of setActivationPolicy(.regular) is false.Am I correct that header notes are supposed to be the most accurate description of APIs in question?Did Apple change the behavior of this API again?Did Apple subtly change the behavior of this API just for Swift?Thanks

Big Sur toolbar seems to prefer size of toolbar items to be set to automatic. Unfortunately, there doesn't seem to be a way to do this programmatically (using NSToolbarDelegate & NSToolbarItem), it seems to only be available when creating the toolbar with Xcode XIB editor. I have several places in my app that use dynamically created NSToolbars and would like to find a way to address some of the display problems (as well as warnings) under future macOS releases because of this sizing issue. Is there a way to set the size of NSToolbarItems to be automatic programmatically?

Is there a trick to successfully installing macOS Big Sur on an ext. drive and the drive not getting corrupted when switching back to Catalina on the internal drive? I understand the issue (64411484), about being on the same APFS container, but don't the internal and external drives each have their own container? Everything is fine until I try to switch over to Catalina, either on a T2 Mac or a non-T2 Mac. Then the entire Big Sur volume is corrupted. Are there more explicit install instructions available from Apple given the known bugs? I would really like to be able to have a stable setup that isn't corrupted each time I need to switch back to Catalina. Any tips or suggestions are appreciated.