Should views be created using NIBs or code in iPhone?

Question

Are there any performance, development drawbacks or advantages when designing views using Interface Builder?

Answer 1

Why did nobody mentioned translation. We have a project in 11 locales - this will give a number of nib*(#locales) - it's just not acceptable (more than a hundred nibs for a project of 10 UIs).

Answer 2

Speaking for myself, I found interface builder horribly obtuse when I was trying to learn how to develop for the iPhone. The workflow you're supposed to use still doesn't make much sense to me. The interface builder is faster for finicky interface layouts than hand-coding.

The disadvantage with generating the GUI programmatically in your UIViewControllers is that you've blurred the difference between Views and Controllers in the MVC pattern. If you can keep the GUI generation to the loadView method, you can still keep a decent boundary between code the generates information and code that displays information.

In short: I much prefer generating GUIs by overriding loadView in the UIViewController subclasses.

Answer 3

From what I've seen until now, generating views with XIBs is VERY easy. But since I've not been developing on iPhone a long time, I can only direct you to this article that shows a sample XIB converted to Objective-C code.

http://arstechnica.com/apple/guides/2009/04/iphone-dev-convert-xib-files-to-objective-c.ars

Interface Builder anyday! :)

I'm sure there are no significant performance gains by directly coding the view.

Answer 4

Never look at the Code generation of NIB using the tool. But look at the Note by apple.

Note: Although you can create an Objective-C application without using nib files, doing so is very rare and not recommended. Depending on your application, avoiding the use of nib files can involve overriding large amounts of framework behavior to achieve the same results you would get using a nib file.

Answer 5

One drawback is that it is easy to miss wiring up an outlet or action, and troubleshooting this can be painful. Two positives are that positioning, aligning, and anchoring UI elements is much, much easier, and elements redraw themselves when the phone is rotated (which is an animation process you would otherwise need to handle yourself with programmatic elements).

Answer 6

Often you want to use Interface Builder; there are several reasons why you would want to do this over programmatic interfaces:

• it is the more accepted way of creating user interfaces, due to its simplicity and visual advantages that you can't achieve as easily by simply using code.
• it helps your applications to conform to the iPhone Human Interface Guidelines, through the use of the markers etc, which Apple encourage developers to follow, in order to maintain consistency and usability across iPhone applications.

Despite this, the main reason why programmatic interfaces are sometimes more favourable over using Interface Builder is for interface elements that need to be created several times - for example, creating n UIImageViews - based on a variable that cannot be replicated in Interface Builder. Programmatic interfaces allow for this flexibility and are usually more efficient in this case.

Note that NIBs/XIBs do also take up memory, and if all of your interfaces are placed in your main NIB file, it will not only increase memory usage by your application (for resources which may not be needed instantly anyway) but it will increase loading time. That being said, however, the normal workaround to this problem is not to use programmatic interfaces, but to place different groups of interface elements in different NIB files, placing the immediately required interfaces in the main NIB file, which gets loaded when the application starts, and other groups of interface elements in other NIB files which get loaded when required.

In short, the general way to go is to use Interface Builder, except for when you need to create a variable amount of elements that cannot easily be dealt with in Interface Builder.