Congratulations, Scott! That was a very interesting and insightful interview and couldn't have come at a better time as my company is considering developing a Mac version of our flagship product. There are some excellent quotes in that article that I have been sending around the office.

Really great interview. I liked Aaron's comment on role of the NIB files. It's always interesting to read an article where both � the interviewee and the interviewer � understand the topic and the mindset of each other. Thanks a lot, Scott.

One aspect of Cocoa that I've never been able to get my head around is the requirement of putting all the connections and actions and outlets and so on *in the nib file.* From my standpoint, this seems to make it harder to track all this stuff. What if you are more accustomed to writing GUI code by hand, and inspecting your code to find which callbacks/methods/messages are associated with a button? Apple's rigid enforcement of the visual style of GUI development actually increases the learning curve, in my view. It would be nice if Apple provided a text-based approach to coding, as Qt/Trolltech allows--you don't *have* to use the GUI designer.

Apple's approach is analogous to *mandating* that professional web developers use WSYWIG tools in creating websites. Many web developers don't like such tools because the HTML generated by such tools is more bloated than they would write themselves--it also make it harder to do fine-tuning of the HTML.

That was a good read, Scott, thanks for posting. It was very interesting, although I thought Aaron came across a little arrogant in a few spots. I know he was just doing the self-promotion thing - being the "businessman" rather than the programmer, which I thought it hurt his credibility a bit... It was like he was trying just a little too hard, which he hardly needs to given his credentials, but he's probably trying to reach the audience of new iPhone developers coming from other platforms who might not be familiar with him or the book, so I should probably cut him some slack :)

@Kevin: Nobody "mandates" that you use Interface Builder. It's the standard way of doing things because it offers a lot of benefits and provides a huge time savings, but there's absolutely no reason why you can't create your interface programmatically without ever touching IB. It results in a lot more code to maintain, but you are absolutely welcome to do it. You can even create Cocoa programs using just a text editor by writing code and creating make files if you really want to. Seriously - I know people who have done it. You have to really learn GCC and the other tools that are being used under the hood by Xcode, but that's your prerogative if you don't want to do it the easy way.

@Jeff LaMarche: It was like he was trying just a little too hard, which he hardly needs to given his credentials

I can only speak from my own experience, which is that he has never said anything to me that came off as anything but gracious and courteous. In addition, a friend of mine (a former student of mine, actually) spent a week with Aaron at Big Nerd Ranch, and speaks very highly of him.

It probably helps to keep in mind that text doesn't always "read" same for everyone who looks at it. Given that the format here is an interview, I'm inclined to believe that Aaron's answers reflect his own personal experience, and that he's just giving candid opinions instead of a verbal press release.

I really appreciate that because I think it's the reason for doing an interview in the first place. To me, it shows respect for both the interviewer and the reader.

@Kevin Walzer: One aspect of Cocoa that I've never been able to get my head around is the requirement of putting all the connections and actions and outlets and so on *in the nib file.*

As Jeff LaMarche said, Interface Builder is just a convenience. Anything you can do in IB you can do in code. In fact, IB can only set attributes on an object that are exposed by the object's class, and some properties can only be set in code.

Mac programmers use IB and NIB files because they save tons of time and reduce boilerplate code. Some also find it helpful for visualization. The main point of Cocoa is to get you away from spending time on tedious tasks and on to things that are unique about your app.

Many web developers don't like such tools because the HTML generated by such tools is more bloated than they would write themselves

IB actually doesn't generate code. It just sets properties on objects using the same methods you'd use if you were doing it by hand.

For what it's worth, IB could be used to generate classes in earlier versions, but it would only really generate the headers, not the implementation. In any case, I don't think that functionality is available anymore.

@Scott Stevenson For what it's worth, IB could be used to generate classes in earlier versions, but it would only really generate the headers, not the implementation. In any case, I don't think that functionality is available anymore.

I believe the functionality is still available in Interface Builder 3, it's just been made more obscure and difficult to find, and for good reason. Code and headers should be created in Xcode, and the interface should come afterwards, since this is the logical way to do things. You could even say that this functionality has been "deprecated" in IB3.

Well, it's not exactly true that you can live completely without a nib file; getting the main menu to work correctly is harder than it, well, ought to be, and NSApplicationMain() loads a nib by default. Jeff Johnson did a series on Working without a nib, and it's worth adding that (at least for now), NSApplicationMain() is still about equivalent to the following code (according to the NSApplication docs):

[NSApplication sharedApplication]; [NSBundle loadNibNamed: [[NSBundle mainBundle] objectForInfoDictionaryKey:@"NSMainNibFile"] owner:NSApp]; [NSApp run];

Of course, you could always use a minimal MainMenu.nib and create the rest of your interface in code, avoiding the need for the few secret overrides Jeff discovers.

I thought Aaron came across a little arrogant in a few spots.

After seeing this comment, I reread the interview. You are right: there are parts of the interview where I sound rather arrogant. I'm sorry about that.

I was using the opportunity to promote the classes and the book, and sometimes that veers a little close to self-promotion. It was an honest mistake, and I'll be more careful in the future.

(Honestly, I didn't think anyone would actually read the interview. I was on vacation at the beach, the children were napping, and I pounded out the answers and sent them to InformIT.com before the boys awoke. InformIT.com? Who reads stuff on InformIT.com!? )

Aaron:

Do you really feel that Apple snubs the business client with their lack of support for making business objects with Cocoa, or do you think that savvy developers can/should utilize existing C libraries to handle this layer? Or do I just sound naive asking this question? I know they're busy with other stuff like selling music, and they're very successful, but...

I am really interested in knowing what your honest suggestions for hopeful client/server (n-tier) business application developers might be on the Mac platform. I have searched the Cocoa boards for information and frankly, there doesn't seem to be much out there about making connections to databases, developing network stacks, etc. and I'm a bit disappointed by that, but I know it can be done. I have your 2nd edition book and the red Advanced book and have even read most of them - I just need an opportunity to ask the questions in the right forum. I don't live in Cupertino - I live in South Louisiana - just got our first Apple Store a few months ago - and I've been enjoying and recommending the Mac since 2001.

Why don't I want to use Filemaker, you may be asking yourself? My response is that I want to control the interface completely. I want to be able to use all the great Cocoa UI-gui-ness and not be restrained by someone else's idea of a good front-end. I also want the system loosely connected to a centralized database so that if you lose network connectivity by choice or incident, it doesn't hose the whole darned thing. I may also not want to, or be able to, pay the Filemaker developer's tax.

Getting to the point - where can I get some multi-system design architecture development advice for Mac OS X? Core Data, distributed objects, Bonjour, Web Objects, they seem to suggest an architecture...

I've seen the questions posed on the lists - other folks want to use a Core Data-designed client to serve as a local cache and sync the stored data with a centralized database. Possible? Feasible? Recommended?

@Aaron Hillegass

Honestly, I didn't think anyone would actually read the interview.

I think you underestimate your popularity within the Mac-development community. You're right when you say your book is a de facto basis for most knowledge we build on. In the irc.freenode.net channel #macdev, we ask people to buy your book before we answer their "beginner" questions; your name is a household name for most of us.

Nice hat by the way :)