Why Work Without a Nib?
You can’t merge changes to nib files on different version control branches.
[…]
Unlike source code, nibs have no place for comments written by the developer.
[…]
A couple years ago I was working on an app that was itself around 10 years old. I wanted to fix a bug, and that required a change in a nib file, but when I made the change, that somehow caused another problem even worse than the one I was trying to fix. It was a total mystery. Ultimately, we just had to declare that nib file off-limits, untouchable, in order to avoid the problem caused by modifying the file. This is a terrible position to be in as a developer.
No matter how outdated the source file, no matter how many deprecations and build errors, you can always at least read the old source code and try to refactor it to work again. The same is not true of nibs. Old nibs can become completely unrecoverable, and you just have to trash them and start over from scratch. You may not even be able to use them as a model for the new UI. Remember Interface Builder 3 Plugins? Any nib with an IBPlugin dependency is now garbage.
Previously: Working Without a Nib, Decoding Old Nibs: a Sad Tale of Vendor Lock-in and Abandonment.
Update (2017-10-24): Arek Holko:
XIBs/storyboards are kinda technical debt. Quick and easy to create, hard to maintain.
Update (2017-10-25): Mark Damon Hughes:
These NIB files “work”, in that they deserialize into objects, but there’s no way to edit them. Where possible, I now do most UI work in code; this isn’t great fun, I end up with a ton of builder functions to avoid repetitive code blocks, but it’ll still compile and work in 10 years.
Update (2017-10-27): James Shore:
You say, “no coding necessary!” I hear, “we built a crappy DSL accessed via point-and-click with no version control or testing API.”
2 Comments RSS · Twitter
Well, I'm certainly in full agreement with Jeff.
I know I'm being dramatic, but the whole NIB/XIB idea/workflow really just needs to go away. It's so 1990's NeXT and seems to have almost entirely fallen apart at the seams over the last few years.
By now, we've learned so much from the web frameworks about how to compose UI's (React, Vue, et al), that I'm kind of surprised that revamping/addressing this sooner hasn't been a higher priority for Apple's framework devs and maintainers (and maybe even the C-level).
I may be on the outs here, but dragging and dropping controls like that seems so pedestrian now in the age of type-safe languages and responsive UI layouts. With a little inspiration from the web world, I really do think that Apple could create something that'd let native developers have all of the power and flexibility of the way UI composition (replacing XIB files) and responsive layouts (media queries) too.
Admittedly, I mostly work on web projects myself, but any time I do open up Xcode and tinker, UIBuilder is absolutely the worst/most frustrating part of the experience - it's stunning to see how old, creaky, unreliable and backwards it is.
