Every setting in the Interface Builder has a corresponding property in the object. For example, compare the Interface Builder inspector for NSTextField
/UITextField
and the documentation of NSTextField
/UITextField
.
IBOutlet
and the target/action mechanism are not special either: the former just uses Key-Valued Coding to set the outlet to an object, and the latter just uses setTarget:
and setAction:
of NSControl
(or a similar method of UIControl
on iOS.)
What the IB does is to precook these objects with the properties set as you specify in the inspector. When loaded, the data is fed to initWithCoder:
of the class.
So, if you'd like to go IB-less just for fun, all you have to do is to alloc
+init
the UI object, and set all the properties by code. There's nothing more than that (except for special menu items on OS X which is somehow handled implicitly when MainMenu.nib
is loaded, that is.)
There is an open source project called nib2objc
which translates a nib
/xib
to a .m
file with explicit Cocoa calls. That will help you understand what is going on.
On a bit more about nib
files, read Apple's own documentation. The special magic at the loading of MainMenu.nib
is described in this series of blog posts. But this is not really about how you would create UI without the nib in general; it's about how the special menu items are treated by the system.
In any case, internally speaking, there's almost no difference between loading a nib and writing UI codes programatically; both just create UI objects and set the UI properties appropriately. With IB, you set the properties beforehand and the precooked objects are read at the run time. If you do it in your code, the properties are set at run time. But once they are set, the resulting objects are exactly the same. So, there's really not much to learn.