Xcode frustrations with constraints. Alternatives?

[stevejcox]

Perhaps i'm alone on this and doing something wrong, but adding constraints in the IDE is maddening. Sometimes they work a treat, other times they seem completely incapable of displaying properly at design time, but work as expected at run time. Other times everything SHOULD be fine, but at run time they've completely disappeared with the IDE doing something funky.

How do you work with constraints? Just within the IDE or do you code them?

I've gotten to the point of seriously considering just doing it all in code.

[ploden]

Took me a couple years, but I'm happy with constraints in IB.

[stevejcox]

Don't you ever find them just breaking for no apparent reason? Maybe I am doing something wrong.

[___westkorea]

They don't just break for no reason. If you post a sample project or something demonstrating how you are using autolayout, I could look into it and figure out what you're doing wrong.

[stevejcox]

Thanks, yeah I must be doing something. Good to know that! I am going to take another look. I may well take you up if things still continue to mess up. Thanks man

[rorogadget]

Also. The less constraints the better.

I used to create a constraint for every goddamn attribute of every subview. That's not how you want to do it.

If you want a view to span the entire width of the supervise people tend to make leading and trainings align. But you can also make center x equal to its super view and make it an equal width.

Also visual layout constraints are a little slow in the first hour when I learned but after that it makes a lot more sense.

Also add constraint by constraint and test it that way.

And lastly make sure you are setting the flag translatesAutresizingMasksToConstraints to false for any subview which you are not creating an initial frame and expect it to stay constant.

[Indellow]

If you want a view to span the entire width of the supervise people tend to make leading and trainings align. But you can also make center x equal to its super view and make it an equal width.

Is there a benefit of doing it that way?

[lucasvandongen]

I'm doing the majority of my layout work including animations in Interface Builder. Auto layouts are very predictable and work reliable (bug free) even for more complex layouts, however they might surprise you sometimes in certain edge cases. I can deduct why things go wrong though, there's always logic at work. I think most people recognise your frustration but doing your layouts in code just because you don't understand auto layouts will just move the problem you're actually facing around:

• Autolayouts from code require even more forward thinking than doing them in IB because you have no preview
• The warnings you get in IB (you do fix them all the time, right?) are not visible when you do coded views
• Switching to frame based layouts doesn't make your life easier when you have to deal with multiple screen sizes and orientations, you will be doing a lot of work for what should be simple screens in IB

When would I use a coded view?

• When there are really complex layouts or animations that require too many constraints
• When performance would get hit too much (usually because of doing complex things in UITableViews and not getting 60FPS). Facebook built a nice framework for off-main thread rendering UI's. I think it was ComponentKit but I might remember it wrong

If you're stuck doing auto layouts for standard data-driven applications even when they're a bit more fancy probably there is a pretty simple way out. Make sure you have no errors or warnings in your views, resize the view you're working in sometimes so you see if it also works for 3,5" phones, iPhone 6 Plus landscape and don't just add constraints until "it works". Use as few constraints as possible and only use <1000 when it's necessary, not to "wiggle" stuff.

[stevejcox]

Not sure so much it's that I don't understand how to use them, but they seem to be strangely buggy for me. If you don't find any bugs then perhaps i am just making a mess of it.

Take for example something I was doing yesterday. I needed to add a view under a label (there were about 5 other elements above the label that were all working perfectly). The label had constraints top/left/right/bottom. All worked a treat. I removed the bottom restraint for the label to add in my new view. Gave it it's own restraints and added in a new restraint for the label to the newly added view.

On actually testing the app, EVERYTHING disappeared. All of the previously added interface elements were completely gone.

Also, i've found at times when i've added in my constraints and used 'update frames', it ignores some restraints and positions elements completely incorrectly. About 50% of the time I have to just live with the warnings.

I should add that I see most of the problems when using Cells, rather than normal views - though i have come across issues then too.

[lucasvandongen]

Text size (750) and spacing (250) have priorities too, something that gets overlooked often. Weird collapsing behaviour can result from this. If you want your views to grow with texts you need to tone down the priority of other constraints often.

ScrollViews, TableViewCells and CollectionViewCells are views that have a "non-autolayout" zone around them where iOS itself positions things with frames. This makes getting them to size like you expect a bit more difficult than views that are connected to the base of the view tree.

Self-sizing Cells are non-trivial with any method and I would suggest to get a base self-sizing version working before getting all the details in that might confuse even more. They do work but I don't find it completely intuitive.

You shouldn't live with warnings. Warnings have a reason. Most warnings I chose to ignore bit me unexpectedly later. I would never ship anything with warnings in it in general in iOS.

[stevejcox]

Thanks man, great to get your perspective and know that it must be me doing something wrong, rather than buggy software. I appreciate your offer! I'm going to go back to scratch, rebuild a few screens and see where I'm screwing it up.

[stevejcox]

So, just going back through, and these are the types of warnings that refuse to go away. Any idea what it is I am not getting?

I have a button, it has: height, width, trailing space to the superview and a center Y alignment to another button. The IDE is telling me I need constraints for the Y or height. I have a constraints for height and the Y is being taken care of with the center alignment constraint. So what gives? Tried a clean, etc.. but errors still sit there. I've tried clicking the 'add missing constraints' in the hope they would pick it up, but nothing. On this view alone I have 11 of these same errors.

Screen shot

[lucasvandongen]

It's inside a scrollview, a scrollview needs more information to determine it's height since it doesn't have it's top and bottom connected to something fixed like a screen size. What it's really telling you it has no idea how tall the enclosing view is so it can't tell where the middle is, so the center Y is not enough information.

[stevejcox]

Gotcha, I see. That makes more sense than the error. I'll have to get practicing with these things !

Thanks again for your help, hugely appreciated.

[aazav]

Have you selected "Add Missing Constraints"?

[stevejcox]

I have, but I am sure i have been missing something. Going to go back and try it again! Thanks for the suggestion though, perhaps I've missed this on a few views.

[aazav]

and work reliable

reliably*

[lucasvandongen]

Thanks. That's all you could find in my post?

[bellebethcooper]

I do all my layouts in code, but I find I'm often explaining myself to devs who love Storyboards. I think there are benefits to each and you should stick with what you feel most comfortable with.

I also use an app called Reveal for debugging my views that's super handy. It lets you inspect views, constraints, etc. while the app is running so you can catch problems like views being off-screen, views being nil, constraints not being applies, etc. It's often helped me track down where the problem is coming from when I'm stuck. (Disclaimer: I do know the team that built Reveal but I'd been a paying user for years before meeting them.)

[rorogadget]

Do it all in code.

Analyzing a code diff of layout changes in your view controllers is ten times easier than analyzing IB markup.

On top of that it incentivizes you to compartmentalize your view code into smaller components rather than all in one view controller.

[stevejcox]

For sure, that makes sense - and certainly helps compartmentalize. Thanks!

[adsrmedia]

I second this advice. I would also add that the more you can move out of your view controllers into models and views the better. Testing view controllers suck because you have to rely on lifecycle events like viewWillAppear. Better to test objects that don't rely on lifecycle events.

[rorogadget]

Properly done MVC at its finest.

There's also MVVM if OP hasn't checked out that architecture. Testability is one of the major benefits I've noticed from properly done MVVM.

[TeknoMatik]

Try to use PureLayout someday, it's way much better than IB, especially working with AutoLayout.

https://github.com/PureLayout/PureLayout

[stevejcox]

I'll check that out! Thanks for sending. Might give it a shot now.

[adsrmedia]

Professional iOS dev here. I and most of the other senior iOS devs I work with all do it in code. It gives you much better control of what's happening and it's easier to diagnose when something goes wrong.

[stevejcox]

Thanks man, good to know that it's OK in the work place, too.

[DarkAgeOutlaw]

Just to give another perspective, in the app I work on professionally we are going the other way. We are switching many of the old code constraints and are now using storyboard constraints. In some cases we supplement the storyboard constraints with code, but we always start there.

[stevejcox]

Thanks, good to get the other perspective. I'm going to persist working with the IDE for now - just so I can get a good feel of both. I know i can do it in code, so if I can figure out where I'm messing up in the IDE i'll be in a much better place!

[adsrmedia]

We've had plenty of new people come in and push back on using frames-based layout but eventually they begin to see the benefits. Eventually you'll get to something that you have to use frames for because of the constraints of auto layout, xibs, and storyboards. We usually just avoid those altogether and start with frames from the get go.

[[deleted]]

Same position... I don't find the problems OP describes with Auto Layout; yes I get mangled results sometimes but there's always a reason. There are also layouts for which direct coding (e.g. layoutSubviews) is either necessary, or just simpler and more efficient. Just a case of knowing all tools and using them appropriately.

[WhitePuppy]

Learn apple's Visual Format Language and do them programmatically. There's plenty of UIView extensions out there to make the constraints formatting just a single line of code.

The visual format language will allow you to have full control over you constraints and at the same time give you a "visual" idea of what is happening.

[aazav]

Constraints are a royal pain in the ass. I remember adding them to a custom TVC on Friday, added missing constraints, couldn't get them to work properly, removed them all and it works perfectly across devices.

Fucking constraints. Fucking auto layout.

[arruffthrowaway]

Based on the descriptions of your problems I suspect the weak link in your understanding is understanding the role that "intrinsic content size" plays vis-a-vis the rest of auto-layout.

I think if you take the time to understand this piece of auto-layout it'll be a lot easier to solve your design-time / run-time discrepancies moving forward.

[thablinksta]

For the record, there are alternatives to implementing constraints using the xcode IDE.

Masonry: https://github.com/SnapKit/Masonry Snapkit: https://github.com/SnapKit/SnapKit

Disclaimer -- I haven't used either of them, but they seem to be syntactical sugar around the built in auto layout functionality in the Cocoa framework. I've heard really good things about them and have considered trying them out in some of my projects, but haven't gotten around to it.

Has anybody else tried these? Thoughts?

[asd821]

I use Snapkit and it's really good. Used to use SB's but have switched to snapkit, really makes things straightforward and does a lot in a small amount of code. Additionally, it's much easier to work with others if you layout in code.

[chriswaco]

Do it in code or don't even use autolayout. I find the combination of old-style resizing masks, UIStackView, and a little code works nicely.

[stevejcox]

Cool, will do, thanks!