Personally, my applications do not use NIB inside them, but it depends more on how I started developing than anything else. I have moved from developing Macs (where I use Interface Builder almost every day) to iPhone since the release of the first beta SDKs. Initially, there was no Interface Builder, and even when it arrived, you couldnโt do much with it, so I never took the time to really find out about it on the iPhone. It depends more on how I do what I know.
Jeff LaMarche makes a convincing argument in his article โ Don't Be Afraid of an Interface Designerโ so you can use Interface Builder wherever you can, and I encourage new developers to learn how to use it before moving on to creating a software interface. This saves you a huge amount of time for interfaces using standard elements.
Some people claim that there is a performance advantage that can be used using purely software interfaces, but Matt Gallagher has conducted a series of tests and that this acceleration is usually around 5-10%. If you really want to shave this last bit from the time your application starts, you can have the best of both worlds with Adrian Kosmachevsky nib2objc , which generates Objective-C from your NIB files.
However, there are many times that you will need to manipulate the interfaces programmatically, for example, for custom views and animations. This code can exist in parallel with Interface Builder without any confusion. Again, this is a matter of personal preference at the moment, but my recommendation is to use Interface Builder because it can save you.
Brad larson
source share