Introduction

This message is the standard Auto Layout warning you see when iOS has been given a set of constraints that cannot all be true at the same time. UIKit resolves the conflict by breaking one of them at runtime, which keeps the UI on screen but often produces clipped views, jumps, or layout that only fails on certain devices.

What the Warning Actually Means

Auto Layout builds a system of equations from your constraints. If the equations conflict, the solver chooses a constraint to break so it can continue.

A simple example is giving a label both a fixed width and edge constraints that already determine its width.

1let label = UILabel()
2label.translatesAutoresizingMaskIntoConstraints = false
3view.addSubview(label)
4
5NSLayoutConstraint.activate([
6    label.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16),
7    label.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -16),
8    label.widthAnchor.constraint(equalToConstant: 300)
9])

On a narrow screen, those constraints may be impossible together. UIKit logs the warning and breaks one.

The Most Common Causes

Over-Constraining a View

You can usually determine a dimension in one of two ways: fixed size, or edges relative to a container. Using both at once is often redundant and can become contradictory.

Missing Priority Strategy

Not every constraint should be required. If multiple layout goals compete, some should have lower priority so the solver knows what may flex.

Intrinsic Content Size Conflicts

Labels, buttons, and images bring their own intrinsic size into the system. Long localized text and dynamic type frequently expose layouts that looked fine with short placeholder strings.

Autoresizing Mask Translation

If translatesAutoresizingMaskIntoConstraints stays true on a view that also gets explicit constraints, UIKit creates extra constraints for you, which can collide with the ones you intended.

How to Debug It Properly

The runtime log prints the list of conflicting constraints. Read it carefully and map each constraint back to the line of code or storyboard object that created it.

The most useful debugging step is a symbolic breakpoint on UIViewAlertForUnsatisfiableConstraints. That pauses execution at the moment the warning is generated, which is much faster than reading long logs after the fact.

You can also use Xcode's View Debugger to inspect the runtime hierarchy and see which constraints are active.

Use Priorities Intentionally

If a view should prefer a width but may shrink, do not make that width required.

let preferredWidth = label.widthAnchor.constraint(equalToConstant: 300)
preferredWidth.priority = .defaultHigh
preferredWidth.isActive = true

Now the system can satisfy the edge constraints first and only relax the preferred width when necessary.

Content hugging and compression resistance priorities matter too, especially for labels in horizontal stacks.

titleLabel.setContentCompressionResistancePriority(.required, for: .horizontal)
subtitleLabel.setContentCompressionResistancePriority(.defaultLow, for: .horizontal)

This tells Auto Layout which label should keep its content and which one may shrink first.

A Better Pattern for Adaptive Layouts

Instead of pinning everything rigidly, let the container define position and let content define flexible size where appropriate.

1NSLayoutConstraint.activate([
2    label.leadingAnchor.constraint(equalTo: view.layoutMarginsGuide.leadingAnchor),
3    label.trailingAnchor.constraint(equalTo: view.layoutMarginsGuide.trailingAnchor),
4    label.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 20)
5])
6
7label.numberOfLines = 0

This usually adapts better to dynamic text and device variation than hard-coded widths.

Storyboards and Stack Views

Many warnings come from Interface Builder layouts that mix manual constraints with stack view behavior. If a stack view manages an arranged subview, avoid adding conflicting size or position constraints unless you truly need them.

Also test with:

• long localized strings
• accessibility font sizes
• compact and regular width classes
• iPad multitasking sizes

Most Auto Layout bugs only show up under one of those conditions.

Common Pitfalls

A common mistake is ignoring the warning because the simulator still shows something that looks acceptable. UIKit is recovering by breaking a rule, not telling you the layout is healthy.

Another mistake is fixing the symptom by deleting random constraints. The right fix is to decide which constraints are actually required and which ones should be flexible.

Developers also forget translatesAutoresizingMaskIntoConstraints = false, which adds invisible constraints they never intended to create.

Summary

• The warning means your active constraints cannot all be true simultaneously.
• UIKit recovers by breaking one constraint, which can hide layout bugs until runtime.
• Use a symbolic breakpoint and the runtime constraint log to find the real conflict.
• Prefer flexible priorities over rigid, redundant constraints.
• Test with dynamic text, localization, and multiple screen sizes to catch real failures.