Support for menus in Storyboards is yanked without ever being deprecated (to my knowledge)? Really? WTF? This is a major step backwards, Apple.
So nice to have to spend a month rewriting my app after WWDC each year. Re-creating a complex menu hierarchy in code is exactly what I wanted to do. Ugh.
Really not a great experience having your app crash on launch with the first build under Xcode 26 due to longstanding supported functionality that you relied upon being removed without notice.
At a minimum, if this functionality is removed, I would expect Xcode to include a conversion tool that would generate the corresponding code (in Objective-C) from an existing root menu within a storyboard.
Even AI (I asked Google's Gemini, as I'm not yet in a position to install macOS 26 to enable the AI features in Xcode) admits that conversion is a difficult, error-prone task and demurs when asked to do it.
Fixing things that are broken by the WWDC beta with no added value to my app (in fact, only higher development/maintenance cost) is not how I envisioned spending my WWDC week.
Really disappointed by this.
The weird thing is, this only seems to occur when running under iOS 26 Simulator. The app built with Xcode 26 actually launches without hitting this issue on the host Mac (macOS 15.5) and a real iPhone (12 Pro) running iOS 26.
Why is the simulator's behavior not aligned with the behavior of real devices? I normally test on real hardware, so it's only by chance that I happened to notice this. The lack of consistency here doesn't seem great, but if inconsistent on-device behavior is the only way I can test my app, then so be it.
Edit: Spoke too soon. I didn't hit the exception until hitting a key on the onscreen keyboard under iOS 26. On macOS 15.5, I'm still able to use the rebuilt app, but I expect I would hit the problem on macOS 26 (will need to test).
Interface Builder has fallen out of favor at Apple which really is a shame.
Are they throwing an exception or just logging a warning? If they are throwing an exception IMO that’s really unacceptable to kill something so core to an app’s functionality without giving a depreciation notice and at least a year (ideally two) years to migrate.
So nice to have to spend a month rewriting my app after WWDC each year. Re-creating a complex menu hierarchy in code is exactly what I wanted to do. Ugh.
yea it’s getting old. Rewrite this. Rewrite that. get nothing in return. Swiftui swiftui swiftui. I think they are more likely to drive veteran developers to a third party frameworks than invest in their new “goodness”
I met with the UIKit team last week and discussed this briefly. They explained some of the challenges that led to this decision, and that they didn’t make it lightly. I might’ve been more receptive to this change had the messaging been better. For instance, if it were explicitly mentioned in a WWDC session or, ideally, at last year’s WWDC—a year before the removal of support. They thought it was mentioned in the release notes this year, but I haven’t found it.
What did they say? I'd love to know why unarchiving a nib became too much of a burden all of a sudden, to the point where they couldn't even give proper notice before removal.
I don't have a Catalyst app that loads the menu bar from a nib but so many changes in recent years pulls us back instead of pushing us forward.
Remember when you could just set restoration identifiers on view controllers and UIKit would restore your entire view controller hierarchy? Now why didn't they apply that same approach to scene based apps? I mean I did it but they're supposed to be the geniuses why are they making every developer repeat that code?
Now they want us to type nibs by hand. What are they going to take away next?