Interface Builder is bad and getting worse

I do everything in code so I can place everything exactly how I want it.

IB is a complication I'd rather not deal with.

It adds unwanted complexity.

Hence your post.

My opinion only of course.

You're free to do as you wish.

"This morning I spent *FOUR F*CKING HOURS* trying to make a @#$# button correctly span the width of a view, without screwing up everything else I delicately placed in the view."

I believe it. Let me guess - Autolayout?

Yeah, life's too short for autolayout. Just let me use coordinates and I'll keep my sanity, thank you very much!

If you don't like autolayout, why didn't you just turn it off? There's no requirement to use it.

I find the constraint based layout had a steep learning curve and bumpy road but now it saves a lot of time.

If you do not, then spend the time you waste in Interface Builder laying out your UI in code.

"@HyperNovaSoftware

I do everything in code so I can place everything exactly how I want it.

IB is a complication I'd rather not deal with.

??? Really?

I'd understand people doing everything in code ... 5 years ago, but now?

That's exactly what gives bad results and interfaces that are completely disconnected from reality in terms of design advancement and current devices thinking.

I'd suggest leaving designers deal with the design, in IB rather than thinking everything can be solved in code. Unless of course you enjoy delivering updates to your clients each time Apple releases a new screen size)."

You don't know my background or abilities so painting with a broad brush is easy.

Designers can come up with user interfaces that are just as bad/good as that of any developer/programmer.

They certainly don't have a lock on interface design.

Because of forum rules, I won't tell you what I suggest you do.

"but thinking that developers can come up with good (or better) design than designers is pretty silly and disconnected from reality."

That's absurd.

I think Interface Builder works fairly well for the most part, mainly when you are not using Autolayout.

Autolayout/Size Classes have this goal that you should only do the UI once, and it should work on all devices. That is a good goal, but in practice you have to handle edge cases. For certain layouts, it is required that a 3.5 inch screen has a slightly different layout than larger screens. Interface Builder and size classes do not give you enough control to easily handle this, although it could because you can wire up size class specific constraints. We are encouraged to use size class specific constraints as little as possible (only when you need them). They could have just allowed us to switch and quickly make device specific constraints.

I'm hesitant to adopt Autolayout in my apps though. Mainly for the following reasons:

1) It isn't obvious when/where you should change constraints for things like orientation changes. You have to be careful that invalidating one constraint doesn't break other constraints and destroy your UI. I've seen this happen in system provided view controllers.

2) When you change constraints for things like orientations changes, the code doesn't look good in your view controller (last time I checked, iPad size classes are the same in both orientations. But you don't always want the same layout in both orientations). Everything can't be configured in IB.

3) Size classes are invented jargon made by Apple. In your brain you translate the jargon of a size class to the device models, which just gives you more things to memorize and more documentation to sift through for something that should come natural. Size classes should probably come in two forms, device based or aspect ratio based.

4) It seems that you have to subclass more often than should be necessary to override size classes.

5) The integrity of the API is compromised. If you create an Xcode project using size classes and auto layout, there is a bug that can prevent you from removing views from the superview (21477829).

6) I'm scared of changes Apple makes to Autolayout from version to version. Just because my Interface looks good in Interface Builder when switching from device size to device size, doesn't necessarily mean it will work on an older version of iOS.

7) You really need to test your constraints thoroughly on all device models or in the simulator before you ship your app (if you support multple iOS versions, times it by 2). Doing this in the simulator is painfully slow. Even if you own every device, still adding days (or weeks) of work. I've seen Interface Builder display layouts when previewing that look correct. Ran the app, and it wasn't correct. But Autolayout isn't supposed to add work. It is supposed to lighten the load.

Now if you carefully program your frames manually, you can look at the code and see what it means. You don't have to translate jargon. It's not perfect, but for me there is a whole lot less to worry about. If I have a text view full screen on a view controller, in the view did layout subviews method, the code is very clear and readable.

I've been fighting with autolayout since 7.1.1 came out.

What I'm doing used to be a piece of cake. Now I'm jumping over hoops trying to remove the mysterious 20 points it automatically tries to add for me at the borders. Downloading 7.2 right now and FINGERS CROSSED.

If 7.2 doesn't fix it I'm done coding till next year.

Interface Builder was not designed.

Well, maybe 1.0 was, back in the ancient times, under NeXT.

The modern Interface Builder though is hobbled by concepts that IMO were quickly surpassed by other, easier concepts. SuperCard had a better layout system in the late 90's, that properly scaled pretty much anything for any resolution. LiveCode still isn't there, but it's a **** of a lot better than IB.

REALBasic/Xojo is better than IB.

I prototype everything in Unity. Their new UI system (as of 4.6) is freakin' awesome.

Building a UI in a 3D game engine shouldn't be my go-to tool for UI development.

I sincerely hope someone at Apple reads this and thinks about it.

-Chilton