Interface Builder is bad and getting worse

What do you mean, "IB is a complication"? Yes, it's maybe a little bit clumsy, but it's pretty easy to use once you get the hang of it. I personally use IB for everything and create outlets to my layout constraints for dynamic layout.

It adds unwanted complexity.

Hence your post.

My opinion only of course.

You're free to do as you wish.

But what specifically about IB is more complex than manually coding everything? I find it far easier to graphically create and edit things than to sift through tens or hundreds of lines of code to find what I'm looking for. With IB, there's less of the tweak-and-recompile cycle and absolutely none of the crashes resulting from forgetting the translatesAutoresizingMaskIntoConstraints call (yes, I've made that mistake more often than I prefer to admit 😉).

"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.

Agree with you 100%. It's not the most intuitive (or robust) system out there, but once you get the hang of it, it's a breeze. I get lost trying to find the right line of code that modifies the constraints; I don't know what I'd do if I had to do that every time I wanted to change the layout!

And I don't have to deal as much with those stupid translatesAutoresizingMaskIntoConstraints calls.

Hi,

I do agree that IB isn't great at all, but for many things, not that bad either, provided that you learn how to use it.

I think many people complain about IB are mainly "pure programmers", who have much less understanding of pure design thinking and problems ...

I believe IB and storyboard were created to allow teams to work together, having designers mock up the interface and rules (especially with UIStack, size classes, and so) in IB, then let programmers just hook the code.

Of course, it could be much better, both on usability (hints, a look simulation before you drop something, more meaningful alerts), and there are still a lot of inherent bugs (when you delete a constraint, it actually stays there, greyed out, causing errors and screwing look sometimes, also private framework classes not loading if the framework source isn't in the project, etc).

I propose learning IB if you're going to work with it (aka targetting Apple's devices only), there is practically nothing I can do in code I can't do in IB besides adding/removing items from server or so.

Hopefully this should get better if Apple listened a bit more to compplaints, I've never got any feedback for enhancement proposals, but seems if many people propose the same in Bug Reporter (lol?) it gets considered more quickly.

@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).

IB gives you more feedback on layout that you'll ever get in code. It allows you to see in real time all different devices in all orientatons and split situations.

(I work with my preview pane loaded with each simulator twice, one per orientation ... Designing the interface and getting feedback has never been easier).

Not only there is no special complications, provided you understand design (but I guess it's easier for me as I am originally designer and worked with countless design software, so I feel actually underwhelmed in IB, but I believe even a programmer can get the handle of it in a day, as I am teaching my company's junior staff and they feel at home after a week), but it also allow you to get ahead with future sizes by having "Size Classes" and previews of stripes (1/3rd portrait iPad for ex, which is a very long iPhone basically), you can't do that in code, unless you work only with percentage (which still isn't enough, as you never know if "10%" of the hight is a lot or not).

Hope you give it a try in any free time of yours, it can not only boost your productivity but result in more intuitive and "fluid" interfaces for your users witjout you having to code everything.

@bob133

Agree with you 100%. It's not the most intuitive (or robust) system out there, but once you get the hang of it, it's a breeze.

Believe me, it can be VERY robust (much more than most of the rival solutions from other companies).

I can't tell you how much impressed I was when I found out you can load a whole interface in a private view (I make private/internal SDKs for my game company, and to experiment with Xcode 6/7 new "module", I made a card game in IB only, then imported other games of the company, previously exported as frameworks/module for test purposes only ... then each card on screen, which was a simple UIView, was loaded in IB by one module/game's main class ... I couldn't believe my eyes to see games rendering in IB, and becoming fully playable games while acting as normal view, responding to constraint and sizes).

@bob133

And I don't have to deal as much with those stupid translatesAutoresizingMaskIntoConstraints calls.

Not only, but it helps in many other points:

- Portability: You can duplicate a view very quickly, and modify the class attached to it (pretty good when you have a custom template)

- Memory leaks: Many elements can be controlled purely in IB with no need to have them as property in code, which reduces the risks of memory leaks.

- Rendering Cycle: You respect the rendering cycle, and you avoid any mistake or loop calling to "viewDidLayoutSubviews" and so ... Animations and scaling are also much smoother in respect to rotation and screen slitting, nothing gets out of sync.

"@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.

No need to get on the offensive, there was nothing personal in my comment.

I don' know your background and wasn't painting anything ... I just answered to "I do everything in code" by the contrast "let designers do the interface design, in interface builder, and coders do the coding in code".

That's how it's supposed to be, that's why the tool is made that way, and that's how big projects in every big corporation I worked for re made (in contrast, that's where smaller companies working with old code base do struggle, have hard time sharing/outsourcing code, and end up with a bloody mess).

Like I said, I don't know your background nor how many big corporations or large projects you've been on, so I won't comment nor suggest anything, but that won't change the veracity of my comment.

Yes, bad designers "can" have as bad design as any good developer (I didn't mension that, just the actuality of UI/UX), but thinking that developers can come up with good (or better) design than designers is pretty silly and disconnected from reality.

While one can argue the "taste" and the good/bad in design (such as the flat design and so), there are many concepts of design and HCI that are available only in design courses and one can't really know unless he has a background in design.

Peace.

"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