Hacker Newsnew | comments | show | ask | jobs | submitlogin

I can't imagine anyone actualy using IB, at last for anything but the most basic app. It just frustrates me no end, and I am pretty sure most people just create all the elements programmatically.



Since Cocoa programming on the Mac, sometimes in the cocoa-dev list the question "how do I design interfaces in code instead of using IB?" popped up, and the general consensus was always: "why do you want to do that? You are fighting against the environment. Use IB".

-----


I've tried designing UIs without IB. I went thorough years of mailing list archives, several questions on StackOverflow and I don't know how many blog posts. Trust me, writing an app without IB is a stupid, stupid idea. IB is central to Cocoa development.

-----


I guess not.

-----


Not seeing the problem with IB here. I use it extensively for generic UI elements, with custom views and windows, use it to target the FirstResponder, use it to hook up actions, connect controllers, and to bind objects together - all of things IB (and now Xcode 4) were made to handle.

I am curious as to what you don't like abou it?

-----


Where should I begin?

- It's incredibly brittle. Good luck if you need to make significant changes to your hierarchy, or change that NSOutlineView of yours to an NSTableView. You'll have to rebuild and re-hook up all of the connections on an object. With no warnings or errors if anything is wrong. In HTML, you can just copy and paste, change some tags, and make some adjustments. Now HTML isn't ideal for application layout - but another markup language could be (MXML isn't bad).

- Doesn't play well with source control. Only one user can work on a .nib at once. Just yesterday another programmer and I both made changes to UI. Of course, it was completely unmergeable by machine or by hand - what do you expect when you have GUI generating a 7000-line file for relatively simple UI. So one of us had to re-do several hours of work. This isn't a problem with, say, HTML.

- Most significantly, it only solves a small part of the problem. It completely falls down when you're dealing with dynamic / variable UI - you'll have to resort to code anyway. And a lot of the layout you need to do is actually inside cells - say, trying to build a source list like iTunes, or a table view with icons inside of it. IB can't help here at all. Then, you end up laying out the actual UI in code. And what code it is:

NSDivideRect(cellFrame, &imageFrame, &textFrame, ICON_INSET_HORIZ + ICON_TEXT_SPACING + imageSize.width, NSMinXEdge); imageFrame.origin.x += ICON_INSET_HORIZ; imageFrame.size = imageSize;

		textFrame.size.width -= ([self sizeOfBadge].width + ROW_RIGHT_MARGIN);
Are you serious? This is 2010. You should not need to be manually calculating the positions of UI elements. There should be a layout language. HTML, MXML, whatever.

IB encourages you to use a very low level of abstraction. There's a lot of repetition, and the closed nature of the tool means it's very difficult to build up higher levels of abstraction. But then again, I guess Objective-C loves loves making programmers repeat themselves.

There's a reason most professionals don't use dreamweaver to make websites, either. And they are much the same.

-----




Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: