How many experienced Cocoa programmers rely on Interface Builder to connect their applications?

Question

In IB, you can create instances of controllers, create links to user interface elements, and define targets. It is also possible to do this programmatically. I wonder what (most) experienced Cocoa developers prefer?

In many other environments, I would not have to work too long with interface builders (lowercase), but Apple tools are clearly their own class. However, do they carry on or are tools for beginners? And why?

I think it’s clear that they are the right choice for assembling and composing the user interface. But what about binding interface elements and controller objects?

Answer 1

Experienced Cocoa developers make extensive use of Interface Builder. These are inexperienced people who, as a rule, do not trust him, because UI developers for other environments usually suck, so they assume that Interface Builder is similar to this. Not this. Cocoa and Interface Builder are closely related. It is difficult to develop an application without using Interface Builder - to the extent that if you look at the Cocoa -Dev mailing list archives, you will see many frustrated developers new to Cocoa asking how they can avoid using IB. Answer from both Apple and Cocoa's veteran developers are the same: just use it.

Think I'm full of shit? Open any Cocoa professionally made app. Seriously, any Apple application, any third-party Cocoa application. Now go to the "Resources" folder. Poke around and you will see everywhere around.

As for how much IB is too much - there is a point where the connections will be established by the code. In general, the connection of user interface elements and controllers is usually done in IB, and even the connection between controllers and controllers is often also, although this is very important. Essentially, it boils down to less effort to create and maintain. The big exception to the dominance of IB, ironically, are user views. When you have a custom view that is used only once, it’s just not worth creating IBPlugin for it. In this case, as a rule, the controller connects to the view in IB, and then the controller connects the view to everything that it needs.

Answer 2

This mainly depends on their background as a developer and what you can consider “experienced.”

I saw people refuse to even open IB.

My opinion is that to create an application that is not like every educational application from the era of iPhone 3G, you need to use IB, and also avoid it and try to create a good application to make full use of the code. a waste of time and can make your code difficult to read if it doesn't execute perfectly.

Answer 3

As the Apple documentation says, the less code you write, the less you should support, and I think this is a very good point.

You constantly associate controllers with user interface elements, this is what is called an MVC scheme.

Answer 4

Any experienced Mac or iPhone developer will use IB for almost all of their front-end connections and as an inversion of control object creation manager. By placing its posting in the NIB instead of code, it does not load until it is requested and is easier to manage.