Updated September 2026: the nib2objc project is a 2010 relic — archived on GitHub, no longer maintained — but the Interface-Builder-vs-code debate it engaged with still shows up in every iOS codebase, so the post is kept with a look at what it means now.
This was my attempt to answer the eternal dichotomy between developers arguing about the relative benefits of creating user interfaces via Interface Builder or via pure Objective-C code: use both. Design in Interface Builder, then convert the NIB into plain Objective-C with nib2objc.
How it worked
Not many people knew that the ibtool utility bundled with Interface Builder and Xcode can inspect the contents of NIB files (or XIBs) and produce XML property lists. nib2objc transformed those plists into NSDictionary instances and walked them over and over until it could emit code like this:
UIView *view6 = [[UIView alloc] initWithFrame:CGRectMake(0.0, 0.0, 320.0, 460.0)];
view6.frame = CGRectMake(0.0, 0.0, 320.0, 460.0);
view6.alpha = 1.000;
view6.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
view6.backgroundColor = [UIColor colorWithWhite:0.750 alpha:1.000];
view6.clearsContextBeforeDrawing = NO;
UIButton *view9 = [UIButton buttonWithType:UIButtonTypeRoundedRect];
view9.frame = CGRectMake(167.0, 65.0, 72.0, 37.0);
view9.alpha = 1.000;
view9.autoresizingMask = UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleBottomMargin;
view9.contentHorizontalAlignment = UIControlContentHorizontalAlignmentCenter;
[view6 addSubview:view9];With this in place I could design in Interface Builder and still keep the final layout as code, which is usually what I wanted for UITableViewCells. At the time it only handled UIKit classes; extending it to AppKit looked feasible but never happened.
Reading this in 2026
The project lives on as an archived repository: akosma/nib2objc (~1,100 stars, last push 2012). It will not compile against modern SDKs, so treat it as a period artifact. The instinct behind it, however, won the argument: SwiftUI is essentially “Interface Builder with a real language” — declarative view definitions that live in source control and diff cleanly, exactly the trade-off nib2objc was hacking around. XIBs and storyboards still exist, but ibtool itself is the part of the toolchain that survived best: Apple still ships it with Xcode.
The 2010 post has been lightly edited above; the sample output is verbatim.
Leaking Memory!!!I found this piece of code to be incredibly usufel as I have adapted to check to see if there are any pixels remaining in an image I am drawing onto. Could have never figured it out without this. The only problem I have is that the code as it stands leaks memory pretty bad.It probably doesn’t show up much with one touch or button press, but repeated taps (As in my app where I am testing to see if there are any pixels remaining in the contextRef) really show up. You can see the leak pretty well by using the memory monitor in Instruments.I think part of the problem is the deallocation of the bitmapData. I don’t think I am wise enough to figure out where this is supposed to be done. I know that I can slow the leak by using:return [NSData dataWithBytesNoCopy:data length:dataSize freeWhenDone:YES];instead of:return [NSData dataWithBytes:data length:dataSize];The weird thing is when I use NSData dataWithBytesNoCopy I lose access to the buffer in the iPhone Simulator although It works OK in on the actual device. I think that may be an unfortunate bug with dataWithBytes or something.I think there must be a better way of making sure that the original void * bitmapData that is malloc’d is released.Any thoughts?Thanks!