I'm new to the iOS platform. I'm not clear on the purpose of the interface builder. It looks like I can avoid using it entirely and just write all the code in objective c. am I right? is there anything that IB can do but obj-c cannot?
It reminds me of visual basic 6.
You can absolutely write all of your code without ever using Interface Builder. IB can, however, make your life a lot easier if you learn to use it.
You can avoid using it, in the same way you can avoid using arrays and just create a ton of variables named thing1, thing2, thing3, etc., and you can avoid using functions by copying and pasting their contents inline. In other words: You don't have to use it, but you'll usually want to.
Interface Builder is unlike Visual Basic in that it's actually a really useful tool that real programmers working for big corporations actually build their apps with.
Nope. Interface Builder exists to make your life easier, but you don't have to use it.
You can also avoid C entirely and write everything in ARM assembly...
InterfaceBuilder is kinda like the compiler. It is a tool you use that [hopefully] makes your life easier. It doesn't generate code, it generates a binary archive that describes your particular interface files. While you can manually do everything in code that you can do in Interface Builder, that would be a silly waste of time.
IB is absolutely used by professionals. All of Apple's applications are built with IB, for example.
As for sharing the file with a co-worker, that should absolutely be done through a revision control system like Subversion, Perforce, or Git. While you could email around your projects -- including xib files -- that is error prone. Far better to use a source control management tool to handle sharing and change tracking.
Anything you can do in interface builder, you can do equally well in code. If you like dragging lines around and building programs like legos, then interface builder is great. If you like text better, then do it in code.
When I write code, I tend to have a Terminal open as well. For example, I use command line subverison even though it is build into xcode. I would not say one way or the other is better, it is just a matter of how you work and how you think. I almost never use interface builder, but that is personal choice.
There are a few things you can only do in code, but those things are fairly rare and can easily be used in conjunction with interface builder.
There are also some things that are better in interface builder. It rarely comes up for me, but any time you have the equivalent of an html form with several different controls I think interface builder is the better choice. I end up with lots of table, web and text views in my programs but not many forms to fill out.
Are you perhaps thinking that Interface Builder is a code generator?
IB doesn't generate code per se. The NIB files it generates are basically serialized objects that are unpacked and instantiated when loaded.
There mere fact that IB makes it easy to position your UI and then previe it, instead of having to painfully write it all out with no way to visualize it without a working app makes it an essential tool.
The real question often is when to use a NIB file and when to programmatically generate your views. The advice I recently saw recommends to use NIB files created in IB whenever a view has subviews.
It is absolutely true that a nib file does NOTHING for you that you couldn't have done, somehow, in code! And indeed, in particular cases, deciding between using a nib file and just creating those instances, in code, can be a tough decision. Nevertheless, at least sometimes, a nib file can be more convenient.
Think of Interface Builder as another way of creating instances. A nib file consists (in your imagination) of class names (such as UIWindow, UIView, UIButton, whatever) along with instructions for how to instantiate these classes and configure the instances (e.g. make this UIButton a Round Rect with the title "Tap Me!").
At some point, if and when the nib is loaded, all those instances are actually created.
So a nib file is a good way to configure a bunch of instances, graphically (especially useful, obviously, when they are UIView subclasses), and bring them all to life in one fell swoop by loading the nib. If you have a big object graph - a UIView full of buttons and fields and stuff - designing and configuring in the nib file makes your code a lot simpler and more maintainable.
Moreover you can load the same nib over and over to get new instances. This is why e.g. designing a UITableViewCell in a nib is such a great approach.