41

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

Bjorn
  • 69,215
  • 39
  • 136
  • 164
  • 9
    "I would prefer to create my interfaces programatically" +1 for this, you rock. –  Oct 28 '12 at 15:38

5 Answers5

39

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.

Conal
  • 18,517
  • 2
  • 37
  • 40
  • 10
    I like the question too. In fact I wonder how the accepted answer is basically that your an idiot if you want to do it this way. I just went xib-less for an iOS app (this tutorial helped a lot: http://vimeo.com/3363949 ) and am now looking to do the same on the desktop. – Lou Zell Dec 14 '10 at 08:56
  • Here's an updated link to the blog posts since the link above just takes you to the main page: http://lapcatsoftware.com/blog/2007/05/16/working-without-a-nib-part-1/ – MattB Mar 07 '13 at 15:03
  • Thanks, @MattB. I've updated my answer to include the direct URL you found. – Conal Mar 07 '13 at 22:24
20

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.

Everett Zufelt
  • 201
  • 2
  • 2
  • I think the documentation is there. It's just not in the howto's which sucks. :/ – Bjorn Sep 25 '10 at 00:08
  • For iOS there's been some success using teacup to build UIs (Austin Seraphin at least has used it successfully). github.com/rubymotion/teacup – colinta May 02 '13 at 23:44
20

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.

Peter Hosey
  • 95,783
  • 15
  • 211
  • 370
  • 12
    Amen. I used to be of that "write everything myself" mindset. Then I learned what it meant to meet project deadlines. It's a real eye-opener. – Rob Apr 04 '09 at 18:06
  • 3
    I triple that. Interestingly, I've had a few developers coming from the Java world recently also say they prefer to code the interface themselves... right up until they understood that IB doesn't generate any code and doesn't need to. Guess the IDE-generated swing code really sucks :-) – Jarret Hardie Apr 04 '09 at 19:51
  • 27
    "You can't write a typo by drag and drop" actually, I've discovered, you can.. I've caused weird application-crashing errors by accidently dragging to the wrong outlet or binding. Interface Builder is okay, but it's not foolproof (not to say creating interfaces by hand is any better, but if nothing else the errors in ObjC are a bit more.. obvious) – dbr May 04 '09 at 01:32
  • 6
    btw, Apple avoids using IB too: http://lapcatsoftware.com/blog/2008/10/20/working-without-a-nib-part-7-the-empire-strikes-back/ – yairchu Jun 02 '10 at 14:58
  • yairchu: Huh? That link doesn't appear to support your claim. Care to explain further? – Peter Hosey Jun 02 '10 at 23:17
  • 1
    I'd gladly use IB if it wasn't so awful to figure out. Granted, I'm trying to learn it on my own - but it seems so counter intuitive. Actually Xcode itself just seems like a horrible IDE. I'm just used to Visual Studio I think. – Jack Marchetti Aug 09 '11 at 20:59
  • Interface Builder is fantastic... as long as you only ever expect the application you're creating to run on an Apple product. If you want an application that runs identically on other platforms as well, then using IB is the way to waste time. – Gerald Dec 21 '11 at 22:08
  • @Gerald: Any interface code you write in Cocoa or Cocoa Touch won't work anywhere else, either. If you use a cross-platform framework like Qt, then yes, you can't use nibs. – Peter Hosey Dec 21 '11 at 22:25
  • @Peter... right, or if you want to write your own cross-platform code in C++ that uses Objective-C(++) just for the interface to Cocoa. In general I agree that if you want to create Mac applications, using IB is *usually* the best approach, but there are also many scenarios where not using it would be the best approach. – Gerald Dec 21 '11 at 23:58
  • 2
    The #1 reason not to use IB is not all the world is Cocoa. If your target includes Windows or Unix, any work you do with Mac-only tools has to be done again anyway. The #2 reason is that not all projects are new. The minimal step to continue using existing code shoudln't start with replacing the entire UI. – ddyer Jan 31 '12 at 18:59
  • @ddyer: Any UI you write in Cocoa code is not going to be shared with any other platforms anyway. You certainly won't use IB to make a non-Cocoa interface, but that wasn't the question. As for #2, I agree with you on that. – Peter Hosey Jan 31 '12 at 19:08
  • My feeling is that IB is very useful if you're developing an app that uses a lot of standard controls, especially if you there is a need to re-arrange those controls as part of the design/dev process. It starts to get in the way for me when I have a lot of custom controls or in cases where standard controls are moved or become hidden/visible as part of the design of the UI. – g-dog Feb 18 '12 at 03:31
  • @PeterHosey: Ad "Document-based" - please would you look at my question at http://stackoverflow.com/questions/10373304/cocoa-minimal-document-based-app - I'm sorry I ask it this way but I was unable to find your contact. – Ecir Hana Apr 29 '12 at 22:33
  • @colinta: Very good point. Austin Seraphin has touched on this a few times on his blog: http://behindthecurtain.us/2012/10/04/rubymotion-rocks/ http://behindthecurtain.us/2013/01/10/rubymotion-and-accessibility/ http://behindthecurtain.us/2013/04/17/inspect-2013/ – Peter Hosey May 03 '13 at 00:16
  • 2
    This didn't answer the persons question at all. Just because you believe that you shouldn't write your own code doesn't mean that others are of a different opinion. In many situations you may need more control over your UI than interface builder gives you and it is simply not possible to get exactly what you want with it. Also, knowing how the UI layer works because you have hand coded it all will help you in understanding how IB works. Similar to a C programmer having some experience/knowledge of how the hardware actually works or a Java programmer having some experience with C++. – Matt Oct 27 '13 at 01:30
  • @Matt: “This didn't answer the persons question at all.” Except for the last two paragraphs, where I answered it. – Peter Hosey Oct 27 '13 at 09:07
  • @Peter Hosey Time for me to put my foot in my mouth. It did briefly mention the general approach to creating GUI apps without IB. – Matt Oct 27 '13 at 14:04
  • 1
    "Don't do it" is not an answer to the question. Leave the politics of why someone should or shouldn't do something to a different question unless it's dangerous. – Michael Gazonda Aug 29 '14 at 22:18
5

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.

Paulo
  • 51
  • 1
  • 1
  • 4
    You can definitely create your own IB elements. http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/IBPlugInGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40004323 – kubi Jun 18 '10 at 21:58
  • Light at end of the tunnel!! Works for IB on iPhone too? – Paulo Aug 09 '10 at 00:16
  • Nice post about this subject: http://cocoawithlove.com/2009/07/custom-views-in-interface-builder-using.html . And i'm not sure yet, but this technique doesn't work on iPhone yet. :( – Paulo Aug 09 '10 at 00:28
  • You can use IB_DESIGNABLE and IBInspectable now as of Xcode 6. IB_DESIGNABLE means that your custom view will render in IB and IBInspectable on a property means that you can set the property's value in IB. – Joel Jan 10 '15 at 03:47
3

Though this is quiet a bit old... I tried many times to do everything only with programmatically. This is hard, but possible.

Update: I posted another question for this specific issue: View-based NSOutlineView without NIB?, and now I believe everything can be done in programmatical way, but it's incredibly hard without consulting from Apple engineers due to lack of information or examples.

Below argument might be off-topic, but I like to note why I strongly prefer programmatically way.

I also prefer programmatic way. Because

  • Static layout tool cannot handle anything dynamic.
  • Reproducing same UI state across multiple NIBs is hard. Everything is implicit or hidden. You need to visit all the panels to find parameters. This kind of job is very easy to make mistake - mistake friendly.
  • Managing consistent state is hard. Because reproducing same look is hard.
  • Automation impossible. You cannot make auto-generated input form.
  • Parameter indirection - such as variable element size chosen by user - is not possible.
  • Aiming small point is a lot harder than hitting finger sized keys at fixed location - funny that this is serious usability issue for developers!
  • IB sometimes screws. Which means it's compilable, and still working, but when I open the source, it looks broken and extra editing becomes impossible. (you may not experienced this yet, but if XIB file goes complex, this must happen)
  • It's image based serialization. The concept is good. But the problem is image-base only. IB doesn't keep the source code for clean boot by replaying the source code. Clean boot is very important to guarantee specific running state. Also, we cannot fix the bugs in source-code. Bug s just will be stacked infinitely. This is core reason why we cannot reproduce the equal(not similar looking) UI state in IB.

Of course these stuffs can be solved by post-processing NIB UI, but if we have to configure everything again, there's no reason to use IB at first.

With text code, it's easy to reproducing the same state - just copy the code. Also easy to inspecting and fixing wrong part - because we have full control. But in IB, we have no control on hard-core details.

IB can't be ultimate solution. It's like a Photoshop, but even Photoshop offers text-based scripting facility. GUI is a moving program, and not a static image or graphic. An IB approach is completely wrong even for visual editing of GUI. If you're one of the Apple folks reading this, I beg you to remove whole dependency to IB completely ASAP.

Community
  • 1
  • 1
eonil
  • 83,476
  • 81
  • 317
  • 516