I'm a new Cocoa developer (on OS X) and can attest to the mental pain of accepting Interface Builder if you're used to programming other GUI frameworks. Usually I stick my neck out and comment on HN when I know what I'm talking about or I think I have an interesting question, but here I'll speak as a noob, for what that's worth. (I'm speaking so that people who know what they're talking about can get the perspective of somebody who doesn't, in other words. Please don't make fun of me, but corrections would really help.)
The first mental sticking point for people used to other frameworks is that you really must use Interface Builder as a beginner, even if it seems undesirable or unnecessary. Drag and drop an NSFooView in Interface Builder, and it will be nicely initialized and will act the way you expect. Instantiate an NSFooView in code, and you have a debugging task ahead of you, because the defaults you get when you init an object in code are different from the defaults you get when you create it in Interface Builder. It doesn't look or act the same at all. You end up creating the same object in Interface Builder just so you can inspect its attributes and try to set them to be the same in your code, maybe running your Interface Builder code in the debugger to see how the object behaves. (I assume the same is true of UIFooViews, though their default configuration might be closer to what Interface Builder creates since iOS interface objects are newer, code-wise, than the NextStep-derived objects used in Cocoa on OS X.) It's hard work to do things the wrong way. Someone used to another UI framework can put themselves through a lot of misery trying to figure out how to accomplish things in code without the help of Interface Builder, before they realize Interface Builder is an important part of the framework, not just a minor feature of Xcode that you can easily do without.
Another major cause of disorientation is that the learning curve is shaped very differently because of Interface Builder. In a framework that doesn't have a GUI builder, the beginner documentation holds your hand line by line through the code required to create a window, instantiate UI elements, configure them to behave properly, add them to a container, and specify how they're laid out. Why all that? Because you can't do anything without being able to do that! You can't pop up "Hello World!" with a button below it saying "Hi there" unless you can do all of the above!
With Interface Builder you don't have to do any of that in code. It's just drag, drop, done. No need for a twenty-page tutorial that explains containers and layout managers and the event-handling loop.
But here's the thing. There isn't much more to a typical UI framework than containers, layout managers, elements inside the containers, and events. So the "beginner" tutorial in a typical framework holds your hand across all the territory you need to master, and a decent book will explain the things that the tutorial glossed over. By the time you're able to make the button under "Hello World!" change the text to "Ha ha ha fart face" you've learned all the fundamentals, and you can reason things out for yourself. You're self-sufficient! From that point on, the rest of the learning curve consists of reading documentation for the various framework elements you need to use (individual widgets, menus and menu items, layout managers, framework APIs for background tasks, keyboard shortcuts, persistence of preferences, etc.)
Interface Builder, on the other hand, makes it so easy to get a simple application up and running that programmers are assumed to spend a certain amount of time at the static layout level. If you try to jump ahead and create a more complex app (what I think of as a realistically complex application) then you're already leaving beginner territory. If it's your first app, then you're trying to take the curve too fast. Personally, it's been weeks and I don't feel self-sufficient. I don't grok GUI development in OS X at all; I can't fend for myself at all in Cocoa-land; and it feels like I'm shamefully slow at accomplishing these things. Creating widgets at runtime and laying them out dynamically (because I don't know at compile time how many widgets I'll need and of what type -- I SWEAR IT -- I will kill any man who questions it) is just killing me. All of the documentation seems to assume I know what the hell I'm doing much more than I actually do. The response I get from other beginners when I ask about dynamically creating and laying out views is, "You're braver than me!" which isn't true. I'm not brave! I'm a shivering, sniveling noob! I want this to be beginner stuff! But the Interface Builder learning curve is shaped completely differently. What I'm trying to do follows naturally from noob tutorials in other GUI frameworks, because it's really hard to be a noob in other frameworks. In Interface Builder, it's easy to be a noob. How you get beyond that is still a mystery to me, though.
Pre-noob question: what do you mean by "NSFooView"? Googling for it revealed almost nothing, so I take it that you made up the term as a stand-in for some general case. Yes? If so, does NS mean something? Even something that is just a joke or related only to your example? And are you using "Foo" as a reference to the general stand-in phrases "foobar" and "foo = bar"? These questions are sincere, and if you get a chance to set me straight I would seriously appreciate it.
NS is the prefix for Cocoa classes on OS X. It dates back to NextStep. NSFooView is a stand-in for various subclasses of NSView that are the basic UI components in Cocoa. If you open an OS X nib (see below) in Xcode and select "Data Views" or "Layout Views" you'll have a choice of NSView subclasses to add to your UI: NSTableView, NSOutlineView, NSSplitView, and so on. Custom UI components usually subclass NSView.
A nib is a file created by Interface Builder that contains serialized objects that can be reconstituted at runtime. An xib is an XML file that compiles to a nib. An xib is somewhat human-readable and (if you keep the target platform exactly the same) can be somewhat usefully diffed as you modify the interface. I'd like to explain more, but my lack of understanding of the precise nature and use of nibs is part of what makes me a noob.
Thank you. Understanding what abbreviations stand for has always been an obsession of mine, and knowing the origin of "NS" may actually make learning this stuff much easier for me. I really appreciate your taking the time.
Also, because Objective-C doesn't support namespaces like C++, the prefixes sort of serve as a namespace and are there to prevent naming collisions. It's only a convention though, not a requirement.
The first mental sticking point for people used to other frameworks is that you really must use Interface Builder as a beginner, even if it seems undesirable or unnecessary. Drag and drop an NSFooView in Interface Builder, and it will be nicely initialized and will act the way you expect. Instantiate an NSFooView in code, and you have a debugging task ahead of you, because the defaults you get when you init an object in code are different from the defaults you get when you create it in Interface Builder. It doesn't look or act the same at all. You end up creating the same object in Interface Builder just so you can inspect its attributes and try to set them to be the same in your code, maybe running your Interface Builder code in the debugger to see how the object behaves. (I assume the same is true of UIFooViews, though their default configuration might be closer to what Interface Builder creates since iOS interface objects are newer, code-wise, than the NextStep-derived objects used in Cocoa on OS X.) It's hard work to do things the wrong way. Someone used to another UI framework can put themselves through a lot of misery trying to figure out how to accomplish things in code without the help of Interface Builder, before they realize Interface Builder is an important part of the framework, not just a minor feature of Xcode that you can easily do without.
Another major cause of disorientation is that the learning curve is shaped very differently because of Interface Builder. In a framework that doesn't have a GUI builder, the beginner documentation holds your hand line by line through the code required to create a window, instantiate UI elements, configure them to behave properly, add them to a container, and specify how they're laid out. Why all that? Because you can't do anything without being able to do that! You can't pop up "Hello World!" with a button below it saying "Hi there" unless you can do all of the above!
With Interface Builder you don't have to do any of that in code. It's just drag, drop, done. No need for a twenty-page tutorial that explains containers and layout managers and the event-handling loop.
But here's the thing. There isn't much more to a typical UI framework than containers, layout managers, elements inside the containers, and events. So the "beginner" tutorial in a typical framework holds your hand across all the territory you need to master, and a decent book will explain the things that the tutorial glossed over. By the time you're able to make the button under "Hello World!" change the text to "Ha ha ha fart face" you've learned all the fundamentals, and you can reason things out for yourself. You're self-sufficient! From that point on, the rest of the learning curve consists of reading documentation for the various framework elements you need to use (individual widgets, menus and menu items, layout managers, framework APIs for background tasks, keyboard shortcuts, persistence of preferences, etc.)
Interface Builder, on the other hand, makes it so easy to get a simple application up and running that programmers are assumed to spend a certain amount of time at the static layout level. If you try to jump ahead and create a more complex app (what I think of as a realistically complex application) then you're already leaving beginner territory. If it's your first app, then you're trying to take the curve too fast. Personally, it's been weeks and I don't feel self-sufficient. I don't grok GUI development in OS X at all; I can't fend for myself at all in Cocoa-land; and it feels like I'm shamefully slow at accomplishing these things. Creating widgets at runtime and laying them out dynamically (because I don't know at compile time how many widgets I'll need and of what type -- I SWEAR IT -- I will kill any man who questions it) is just killing me. All of the documentation seems to assume I know what the hell I'm doing much more than I actually do. The response I get from other beginners when I ask about dynamically creating and laying out views is, "You're braver than me!" which isn't true. I'm not brave! I'm a shivering, sniveling noob! I want this to be beginner stuff! But the Interface Builder learning curve is shaped completely differently. What I'm trying to do follows naturally from noob tutorials in other GUI frameworks, because it's really hard to be a noob in other frameworks. In Interface Builder, it's easy to be a noob. How you get beyond that is still a mystery to me, though.