Cocoa Development Tools

Whenever I have some spare time, I continue my exploration of Cocoa/Objective-C development. Lately, there’s been a few blogs telling the world how vastly superior Cocoa is to Swing. Cocoa is a fine toolkit and some APIs are wonderful but there are things, aside from having to maintain those stupid .h files, that I find quite annoying.

Being used to Java IDEs, it’s hard to forget about refactoring. Xcode does not provide any support for this and because of the way I am used to code now, I am frustrated. But I can live without refactoring.

The real gripe I have against Apple’s developer tools is how the Interface Builder works. It is an impressive, easy to use piece of software that lets you build nice UIs very quickly. You can even do databinding in it, which is very useful. Yet, things are getting hectic with events handling.

In the Interface Builder you can connect an element, for instance a button, to an action in a target. Doing so is easy as you simply have to draw a line connecting the button and the target. When you first build your UI, you generate .h and .m files corresponding to the target (usually called a controller, following the MVC pattern.) In the .m file you find the methods you need to implement to respond to actions in the UI. So far so good.

The real problem arises when you have typed some code in the .m file and want to handle more events. You go back to the Interface Builder, connect another component to an action in a target, and… you’re screwed. You have to explicitly tell Interface Builder to re-generate the target’s .h and .m files. If you do so, you must either replace the files altogether or go through a painful process of merging code. That’s right, you are shown a diff/merge tool and must merge by hand. While it might be acceptable for small applications, like the ones I write to learn Cocoa, I can’t fathom the consequences on large projects. The other solution is not to use Interface Builder to connect actions and do everything in the code.

I am disappointed and I sincerely hope I have missed something big here. If some of you have experience in Cocoa development, please tell me I’m wrong :) I have heard a lot of complains against NetBeans’ GUI Builder for instance, because it generates the UI code rather than putting it into an external file, akin to Interface Builder’s .nib files. I understand those complaints but at least NetBeans GUI Builder, or other Java GUI builders for that matter, let me incrementally work on my UI without worrying about diffing/merging the code.

18 Responses to “Cocoa Development Tools”

  1. Pierre says:

    Hello Romain,

    Actually, you did miss something !
    It’s true that Interface Builder can generate code for you, so that you can add an action in it and regenerate the .h files. But usually, you will do it the otherway round :
    modify by hand your .h file by adding your new IBOutlet or IBAction. Then, go back to Interface Builder and re-read the .h file (Classes > Read files…). Interface builder will then merge the differences and will see the new outlets/actions.

    Regards,

    Pierre

  2. Romain Guy says:

    Ok but that’s my point: I don’t want to do this by hand! :)

  3. Cedric says:

    Odd that Apple hasn’t foudn a solution to the reverse-engineering problem, which is pretty easy tosolve: generate base classes and only let users derive from them to add their own customizations.

    Good GUI frameworks were already doing that ten years ago.

  4. Jeff Martin says:

    There’s really nothing to do by hand – you simply add a new method to your Controller.[h,m] and select the InterfaceBuilder Read Classes menu item.

    I’ve spent years in both environments, since our company transitioned from a Cocoa/Nextstep product to a Java product. As you point out, the Java language is more evolved than ObjectiveC, and XCode is behind the curve when it comes to refactoring.

    However, the Cocoa UI library with InterfaceBuilder is still ahead of the curve with its polish, data-binding, action binding and component serialization. I won’t be going back to Mac-only, but we missed it enough to write our own Java UI Builder to simplify our app .

  5. Romain Guy says:

    Jeff: Yes but I still have to manually add the methods in the .h and .m files. I might be stubborn or spoiled but I just don’t understand why Interface Builder can’t do that for me, as VB, VC++, Visual Studio .NET and any Java IDE ever did.

    Note that I did not criticize the Cocoa UI library. There’s a good reason why I’m learning it after all :-)

  6. Jeff Martin says:

    Since the method has to be written by a person, whether in a .m or a .java, I assume you’re really talking about having to manually update the header file?

  7. Romain Guy says:

    Well, that (because I hate header files) but also because I’m lazy and don’t want to write the method declaration by myself. The tool can do it the first time you create the UI, why do I have to change my way of adding new events handler once I generated the .h and .m files? It just looks inconsistent to me.

  8. leopard says:

    I have noy seen it, but IB has apparently been given a major facelift for Leopard. Perhaps Sun could spring for an ADC membership for you Swing guys.

  9. Scott says:

    Interesting perspective. When I write a Cocoa application, I usually start in XCode. Design my controllers and models, with the needed connectors and event handlers. Then I design the UI in Interface Builder, wiring up the events when needed. So I’ve never generated the headers and code files from IB. I always make my changes in Xcode, then tell IB to re-read the header file and re-instantiate the object.

  10. Scott says:

    hehe, I’m too slow on the “Submit Comment” button. Anyway, I see your point. I do a lot of development in Visual Studio and as fas as an integrated development environment goes, XCode + IB has a ways to go (except as you noted when it comes to the visual design of the UI). The debugger leaves a lot to be desired when compared to the VS debugger.

  11. Romain Guy says:

    leopard: The problem is I don’t work at Sun anymore and I’m just a (poor) student :)

    Scott: At least they have a bunch of stuff that make me forget those small inconveniences. I can’t wait for Leopard and Core Animation and Objective-C 2.0 and… :)

  12. Envious Swing Dev says:

    I have also been playing around with Cocoa desktop development the last few months and as a long time Swing developer; I must say I am very envious of the Cocoa tools and frameworks. There are some oddities as Romain highlighted, especially no garbage collection, but all in all it leaves Swing in the dust. The Bindings, Core Data, Core Image, and Core Animation(leopard) stuff built right into XCode and IB are a great productivity boost. Not to mention a robust Document/Application framework. Don’t get me wrong, I love working with Swing especially the power it gives you but I am tired of the long term deficiencies:
    1. Ugly cross platform look and feel.
    2. Missing modern components.
    3. No Document/Application framework (I know its coming)
    4. Netbeans GUI builder not all the way there but I like it.

    It all is similar to the superiority of WebObjects to EJB in regards to server side development.

    Just my opinion

  13. Antonio says:

    I agree with Romain that in terms of conventional IDE features, XCode is a bit behind others development tools. It reminds me that the official Apple Development tool in the early days was the MPW (Macintosh Programmer Workshop), which was essentially a command line based Development Tool, and you wondered why Apple didn’t give a fancy GUI to their own tool. However, as soon as you started mastering programming the Mac, you forgot of any shortcoming of the MPW, as you realized that the Macintosh Toolbox and the MacApp Application Framework blew away by far any other development tool that existed at that time on any platform. The same thing happens today: XCode is not the smartest IDE, but Cocoa is lightyears ahead of anything else in terms od Desktop Application development.

  14. Refactoring is coming in Xcode 3, which is part of Leopard. Interface Builder (which is getting a major update) also supports refactoring. Objective-C 2.0 has garbage collection.

    As for adding actions, all you have to do is type this:
    -(IBAction)myAction:sender;

    It takes five seconds. :) You’d still have to type the actual action name into a text box in Interface Builder anyway, so the difference is pretty minor. You could also just use TextMate and add a tab trigger for it.

  15. Romain Guy says:

    Scott: Hey, thanks for replying. I love your blog :) I’m glad to hear good things about Xcode 3, and I am indeed waiting for Leopard/Objective-C 2.0 before writing a real app in Cocoa. I want garbage collection.

    To get back to the actions topic, I know it’s all I need to type, and I don’t really mind typing it (I’ve spend 7 years typing all my UIs by hand in Swing after all.) I just found it weird that the tool is not able to give me the same experience all the way through the development.

    And I still hate .h files.

  16. I am aggressively looking and paying for COCOA developers for a SO-CAL company. Great career launching opportunity for anyone passionate and versed in Cocoa, Objective C and more….

    Will relocate
    FULLTIME
    Extremely well funded startup
    We want you and your referrals
    Please email resumes to kristan@jivaroinc.com with phone, salary and how much you love Cocoa dev work and exciting teams.
    310.649.2640

  17. Very interesting posts on your site. I keep on coming back for more information. I’ve bookmarked it too for future reference. I hope you dont mind at all.