Post

Replies

Boosts

Views

Activity

Reply to Xcode 26 XIB ignores difference between NSView frame and alignment rectangles
This looks like a bug in AppKit... even if you manually re-adjust all your UI, this will only fix the appearance on macOS 26. On prior versions of macOS, many UI widgets will look smaller than they should be, all as a side effect of AppKit no longer interpreting frame rectangle vs alignment rectangle. Unclear if the fix would be to have the XIB compiler actually spit out the correct rectangles so as to maintain visual consistency with all versions of macOS.
Jul ’25
Reply to Xcode 26 XIB ignores difference between NSView frame and alignment rectangles
Posting this here as a summary for the three people left writing native macOS apps using AppKit, who might stumble here from a search. macOS 26 has brought us the yearly facelift that – as tradition – brings no break-through features or discernible improvement to usability (quite the opposite, this time around). This year’s diktat from Marketing has also brought a regression that affects how AppKit reconstructs and displays UIs in XIB/NIB files. (Haven't checked if this exists on UIKit too.) If you had carefully laid out your controls to be aligned without the assistance of auto-layout, reopening these files with Xcode 26 will show all controls to be misaligned. This same problem is sadly visible at runtime too. AppKit has removed the crucial distinction between frame rectangles and alignment rectangles. You would be spared from this problem only if your controls were participating in auto-layout by having at least one constraint, or by calling -[NSView setTranslatesAutoresizingMaskIntoConstraints:YES] and setting constraints programmatically. The most obvious solution is to slowly add constraints to all your XIBs. It makes sense if your app uses simpler view hierarchies. For complex hierarchies, auto-layout never was a viable option. The more constraints you add to your XIB the slower it becomes, until the point where adding a single widget or constraint will take seconds. Assuming they ship with this regression (still there as of Beta 4) the solution for large XIBs is to painfully realign and resize all controls while leaving them on the older springs-and-struts layout system. This luckily can still be done fast in Xcode. The downside? All your controls will look correct on macOS 26 but will be both misaligned and probably look too small on previous versions of macOS. For the latter problem you can thank the fact that they changed the size of controls so that a small button or popup menu on macOS 26 is taller and wider than on previous versions 🤷‍♂️ (my previous post was incorrect on this point) Here we are in 2025 with NextStep-era UI still being the only one you can preview and layout reliably both in Xcode and at runtime. They never allowed auto-layout to become great. Having used it both programmatically and visually, it's been left 90% done to make room for SwiftUI, now 6 years old and nowhere near usable without massive problems and frustration. I wouldn't be surprised if more apps switch to non-native UI frameworks just to stay away from this. Taking a step back from this particular regression, the broader picture is that Apple keeps externalizing upkeep costs to its third-party developers with a yearly facelift that feels more and more superficial, adding busywork to our schedule, forcing rewrites and redesigns, and bringing no rewards. Even if you jump through all of these hoops, your software gains no new features that might actually be considered valuable to users. Best of luck!
Jul ’25
Reply to Xcode 26 XIB ignores difference between NSView frame and alignment rectangles
If your NIBs already have auto-layout constraints, they will look and work OK on macOS 26. The problem I described only affects views that are laid out without any constraints, using the Autoresizing Mask, or Inferred (Autoresizing Mask). The issue is that for complex UI, the "old stuff" is really the only one that performs well both when making changes through the Xcode Editor, and at runtime.
Jul ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
Hi @elemans I am not loading a Storyboard so the error I see on the console is less verbose, and only mentions failure to instantiate that class: Could not instantiate class named _TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView because no class named _TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target) Time for both of us to file a bug. Update: filed as FB19530323
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
@elemans That checks out... all my affected XIBs have NSOutlineViews... but oddly enough I also have XIBs with NSOutlineViews that do not trigger the problem. Judging by the scoping on that class, this is someone playing with a Swift-based addition to AppKit that forgot how everything fits and works together (with tape and glue!)
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
Bad news... I downgraded to Xcode 26 Beta 4 hoping it would output NIBs that work pre-macOS 26, but it didn't. Not quite sure how this regression works, but it might be that the regression was there earlier, but the XIB must have some currently unknown characteristic to suffer from it. It could be that the editor itself is injecting this dependency during normal user actions, in a way that the XIB > NIB compilation cannot actually remove.
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
@elemans Downgrading to Xcode 16.4 does eliminate the dependency on NSScrollPocket. Is this a viable workaround? For some, perhaps. Apple has created an undesirable situation where the new macOS 26-specific .icon files edited via Icon Composer are only understood and compiled to the Assets catalog (and legacy .icns files to back-deploy) by Xcode 26. Downgrading to Xcode 16.x means you can't output a macOS 26 app with new icons for the macOS 26 Public Beta they feel compelled to release (bad idea) and you lose what very little progress has been made in the macOS SDK regarding @Sendable conformance annotations in a handful of frameworks. So you’re back to adding @retroactive @unchecked Sendable statements and cursing that other mess that is Swift Concurrency. Xcode 16.5 also means downgrading to the macOS 15 SDK. In C/C++/Obj-C you can bracket statements that use symbols found only in the macOS 26 SDK with #if defined(MAC_OS_VERSION_26_0) but while Swift adds a new keyword per week, hell no #if os(...) doesn't support versions so it can't help in keeping the same code compilable against different versions of the same platform SDK 🤷‍♂️ The cumulative experience of developing native apps for macOS has never looked this uncoordinated. Good luck! Still hoping someone posts an incantation that magically gets rid of NSScrollPocket in the archived NIB.
Aug ’25
Reply to Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26
@bdkjones Filed bug, even used one of my tech support incidents, heard nothing back yet. Your best bet right now is to find an Intel Mac capable of running macOS 15.6 and Xcode 26 Beta 5. When XIBs are compiled to NIBs on those, no unwanted dependency is injected into the output. There is a possibility the workaround doesn't really depend on using an Intel Mac. It could be the key is simply to compile on macOS 15 rather than 26. I just haven't bothered to try because one method to save the day was all I needed. We already "volunteer" so much of our time helping Apple with their yearly release cycle. If you have success on Apple silicon + macOS 15, please let us know.
Aug ’25