I have many other problems with Interface Builder beyond the ones here; these are just the ones that immediately came to mind. Likewise, however unsafe I have characterized IB to be in this tract, I assure you, it is far more unsafe than that.
There are a number of places where IB-style stuff encourages unchecked stringly-typed code, and worse, the kind of stringly-typed code that doesn't allow you to use the same constant everywhere to provide some semblance of sanity.
- Cell reuse identifiers.
- Storyboard scene identifiers.
- Segue identifiers.
- Bindings. String keypaths are by their very nature unsafe; we can make them a bit safer in code using some fancy macros that actually make them checked at compiletime, but you can't do this in a nib of course. Data representation change? No problem, your view will just break, fucking silently. 'Cause dynamic, fuck yeah.
- Custom configuration of properties in the Info pane. Not many people use this, but it literally shouldn't exist.
- Even outlets and actions! Whilst refactoring usually picks these up, about half the time in my experience, it will either fail to rename something in the nib, or rename something that it shouldn't have! (such as if two unrelated views have an outlet of the same name, if you rename one using the refactoring tool, sometimes it gets confused as to which ones it should rename).
- Don't forget class names. Usually refactoring picks these up; but it doesn't always. Refactoring has to work 100% of the time, not 85%.
Merging XML files that change dramatically whenever you open them (whether or not you have edited them) is fucking retarded. In fact, it should be a theorem that composing the encoding and decoding functions for xib is the identity! But that is of course a bit much to expect from a company that has no interest in formal methods, or anything verging on sanity.
Of course, IB should from the start have used a stable format that is at least human-readable and human-mergable; it would be a very nice bonus if it were human-editable.
I prefer to have configuration of objects in one place, not two. The typical practice with IB is to configure some in IB, and some in code; I'll grant that this is more a matter of practice than the nature of the tool, so I'm pretty forgiving of this. When I'm forced to use IB, I tend to avoid configuring an object much in IB itself; at its best, IB lets you make a blueprint of a view that you will then configure in code. This is, in simple cases, a pretty sane way to use it I think.
IB tends to have a "just one turtle down" approach to view compositionality, in that it's trivial to make a view, but it becomes a bit more complicated to reuse that view in different contexts. I'll grant that this has been greatly improved by the new container view gadget in the objects palette.
Regardless of your opinion on Cocoa Auto Layout in general, we can all agree that the process of editing constraints in IB is totally fucked. Every time you touch one little thing, all your constraints get befucked. Want to nudge your view a bit? Watch all your hard work disappear because you broke some constraints. You can just not use Auto Layout in IB, I guess, which "solves" this problem to a certain extent. Still a bit unfortunate (but fixable, I think).
Let's say you've got a plain old view in your scene, and you want to change it to a scrollview. One would think that you could go into the inspector and just change its class to UIScrollView. And then, technically, it is in fact a scrollview. But the configuration pane doesn't get that. So you have to actually delete the view and add a real scroll view, losing any layout configs or constraints that you have set. Fuck yeah.