Xcode 26 Beta 5 XIB Compiler outputs NIBs with dependency on class that isn't available pre-macOS 26

I see the exact same weird class name in a 'purple' warning message when running one of my projects:

Attempting to unarchive Swift class 'AppKit.NSScrollPocket.(unknown context at $19bd29ed8).BackdropView' with unstable runtime name '_TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView'.
The runtime name for this class may change in the future, leading to non-decodable data.

You can use the 'objc' attribute to ensure that the name will not change:
"@objc(_TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView)"

If there are no existing archives containing this class, you should choose a unique, prefixed name instead:
"@objc(ABCMyModel)"

The purple error line is on instantiation of a Storyboard. I have no idea which element in the Storyboard is responsible for this warning, which makes it hard to make an example project for a Feedback.

Do you see the same kind of warning or something completely different?

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

At my side it turns that removing a NSTouchBar from the Storyboard 'solves' the problem in two completely different projects. Unfortunately I didn't succeed yet in making a clean example project that proves this for a Feedback, so apparently the problem is NSTouchBar and something else.

I manage to reproduce it with a fresh Xcode project. Adding a NSTouchBar and NSOutlineView to a Storyboard was sufficient to get the weird runtime warning.

FB19543241

@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!)

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.

@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.

First workaround found: build using Xcode 26 Beta 5 on macOS 15.6. For some lucky reason when the XIB is compiled on macOS 15, no dependency on NSScrollPocket is injected in the output NIB. 🫠

The runtime warning (not error) I see, seems indeed to be caused by one or more NIBs that contains the infamous _TtCC6AppKit14NSScrollPocketP33_EC3F85FAB7755D56E669206D2B17725B12BackdropView class reference. Compiled storyboards results in a collection of NIBs, and I saw a few that contains each 2 references to said weird class. After removing the NSTouchBar objects from the storyboard, the resulting NIBs only contained 1 reference, without causing a runtime warning.

If Apple doesn't solve this runtime warning then I think I just ignore it until it's solved or when I can give up support for NSTouchBar.

Has anyone notified Apple Engineering about this regression? We're getting very close to a GM release of both Xcode and macOS 26 and this is a show-stopping bug for older codebases.

If there's a bug in a legacy framework that isn't the newest, shiniest, whiz-bang thing, it can languish for years because nobody at Apple cares.

@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.

@FxFactory Thanks. It's infuriating that this kind of thing gets through QA because Apple turns right around and tells anyone who will listen that the billions of dollars they steal from third-party developers are needed to support all the APIs and tools that they offer. Tools that are frequently crippled and broken.

The only way I've ever had any success getting Xcode/compiler bugs addressed is by emailing the head of the Developer Tools team directly and copying Craig on those emails. If you make a big enough visible stink at the company, you can get things seen.

Update: I can confirm that it's sufficient to compile on any Mac running macOS 15.x. The architecture doesn't matter (which would have been extremely surprising.)

The runtime warning I saw seems to be fixed in macOS 26 beta 7