I have no trouble with thinking about objects in memory that I create through code. But when I look at a XIB, it has things in it like "File's Owner" and "First Responder" and "Application" that I'm not sure what they do. And when interfacing with a XIB, I'm not ever sure if that thing I'm looking at is instantiated in the XIB, or if I have to make it myself, and so on.
I suppose I could have gotten over those mental hurdles eventually, but I chose not to. I prefer thinking about objects that I make myself, and I avoid Interface Builder whenever possible.
Even if you just wrap your head around File's Owner, you're 80% of the way there. Essentially, what it boils down to is this: it's a proxy object that gets set when NSBundle's loadNibNamed:owner:options: is called (which is called behind-the-scenes by UIViewController, which is where you'll usually be interacting with nibs). So, in Interface Builder, you change the class of File's Owner to whatever class should be managing the nib and it will give you access to all of that class's IBOutlets.
Like you, I prefer to create a lot of my UI programatically. But in a lot of cases it's just so much more efficient (from a time management perspective) to lay everything out in Interface Builder.
I have no trouble with thinking about objects in memory that I create through code. But when I look at a XIB, it has things in it like "File's Owner" and "First Responder" and "Application" that I'm not sure what they do. And when interfacing with a XIB, I'm not ever sure if that thing I'm looking at is instantiated in the XIB, or if I have to make it myself, and so on.
I suppose I could have gotten over those mental hurdles eventually, but I chose not to. I prefer thinking about objects that I make myself, and I avoid Interface Builder whenever possible.