How do I create Cocoa interfaces without Interface Builder?

Question

I would prefer to create my interfaces programatically. Seems as if all the docs on Apple Developer assume you're using Interface Builder. Is it possible to create these interfaces programatically, and if so where do I start learning about how to do this

I thought the relevant document for this, if possible would be in this section: http://developer.apple.com/referencelibrary/Cocoa/idxUserExperience-date.html

Answer 1

I would prefer to create my interfaces programatically.

Why? Interface Builder is easier and faster. You can't write a typo by drag and drop, and you don't get those oh-so-handy Aqua guides when you're typing rectangles by hand.

Don't fight it. Interface Builder is your friend. Let it help you.

If you insist on wasting your own time and energy by writing your UI in code:

Not document-based (generally library-based, like Mail, iTunes, iPhoto): Create a subclass of NSObject, instantiate it, and make it the application's delegate, and in the delegate's applicationDidFinishLaunching: method, create a window, populate it with views, and order it front.

Document-based (like TextEdit, Preview, QuickTime Player): In the makeWindowControllers method in your subclass of NSDocument, create your windows (and populate them with views) and create window controllers for them, making sure to send yourself addWindowController: for each window controller.

Answer 2

Hmmm... I am trying to make an API that is cross platform. I don't care if anybody calls me crazy or stupid, but it can be done. I would like to use cocoa (instead of glut), as cocoa is native for the mac. For windows, the windows API. For the mac side, I need to do it programmatically. Will not listen to any criticism, so don't say anything. Any answers, please reply.

Answer 3

I like the question, and I'd also like to know of resources for going IB-less. Usefulness (the "why") is limited only by imagination. Off the top of my head, here are some possible reasons to program UIs explicitly:

• Implementing a better Interface Builder.
• Programming dynamic UIs, i.e., ones whose structure is not knowable statically (at compile/xcode time).
• Implementing the Cocoa back-end of a cross-platform library or language for UIs.

There is a series of blog posts on working without a nib and a recent description by Michael Mucha on cocoa-dev.

Answer 4

In fact IB becomes totally unusefull when you start to write your own UI classes. Let say that you create your own button that use an skin system based on a plist. Or you create an dinamic toolbar that load and unload items based on user selection.

IB doesn't accept custom UI elements, so more complex UI can't use him. And YES you will want to do more complex things that the UIKit gives you.

Answer 5

As a completely blind developer I can say that IB is not compatible with VoiceOver (the built-in screen-reader on OS X).

This means that without access to robust documentation on using Cocoa without IB I cannot develop apps for OS X / iPhone in Cocoa, which means I (ironically) cannot easily develop apps that are accessible to the blind (and all others) on OS X / iOS.

My current solution, which I would prefer not to use, is Java + SWT, of course this works for OS X, not so much for iOS.