Introduction

Updating a view's height at runtime is a standard Auto Layout task in iOS. The reliable pattern is to keep a reference to the height constraint, change its constant, and then tell the layout system when and how to animate the update. Most broken implementations fail because they recreate constraints repeatedly instead of updating the one that already controls the view.

Create and Keep a Reference to the Height Constraint

The cleanest setup is to store the height constraint as a property on the view controller.

1import UIKit
2
3final class DemoViewController: UIViewController {
4    private let boxView = UIView()
5    private var heightConstraint: NSLayoutConstraint!
6
7    override func viewDidLoad() {
8        super.viewDidLoad()
9
10        view.backgroundColor = .white
11        boxView.backgroundColor = .systemBlue
12        boxView.translatesAutoresizingMaskIntoConstraints = false
13        view.addSubview(boxView)
14
15        heightConstraint = boxView.heightAnchor.constraint(equalToConstant: 120)
16
17        NSLayoutConstraint.activate([
18            boxView.centerXAnchor.constraint(equalTo: view.centerXAnchor),
19            boxView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 40),
20            boxView.widthAnchor.constraint(equalToConstant: 200),
21            heightConstraint
22        ])
23    }
24}

Once you have the stored heightConstraint, updating the height becomes a one-line state change.

Update the Height by Changing constant

heightConstraint.constant = 220
view.layoutIfNeeded()

That is the entire mechanical update. Auto Layout recalculates the view's frame from the changed constraint value.

The mistake many developers make is trying to remove and recreate the height constraint every time. That creates conflicts and makes the layout harder to reason about.

Animate the Change Smoothly

If you want the size change to animate, wrap the layoutIfNeeded() call inside an animation block on the common ancestor whose layout should update.

1func expandBox() {
2    heightConstraint.constant = 220
3
4    UIView.animate(withDuration: 0.3) {
5        self.view.layoutIfNeeded()
6    }
7}

Why layoutIfNeeded() goes inside the animation block:

• Auto Layout computes the old layout before the block
• the changed constraint provides the new target layout
• the animation interpolates between the two

That is the standard UIKit pattern for animating constraint changes.

Interface Builder Version

If the constraint is created in a storyboard or XIB, connect it as an IBOutlet instead of creating it in code.

1import UIKit
2
3final class DemoViewController: UIViewController {
4    @IBOutlet private weak var panelHeightConstraint: NSLayoutConstraint!
5
6    @IBAction private func collapseTapped(_ sender: UIButton) {
7        panelHeightConstraint.constant = 80
8
9        UIView.animate(withDuration: 0.25) {
10            self.view.layoutIfNeeded()
11        }
12    }
13}

This is often the simplest option in interface-builder-based projects.

When the Constraint Belongs to Another View

Sometimes the view whose size changes is inside a container such as a stack view or another layout-managed subtree. The principle stays the same, but call layoutIfNeeded() on the nearest common ancestor that should animate the change. In many view-controller layouts, self.view is still the right place.

If the containing layout has its own rules, such as a UIStackView, make sure the height constraint is not fighting stack view distribution settings or hidden-view behavior.

A Practical Example With Toggle Logic

1func setExpanded(_ expanded: Bool) {
2    heightConstraint.constant = expanded ? 220 : 80
3
4    UIView.animate(withDuration: 0.25, delay: 0, options: [.curveEaseInOut]) {
5        self.view.layoutIfNeeded()
6    }
7}

This pattern scales well because the constraint is the single source of truth for the view height.

Debugging Conflicts

If the height does not change as expected, check these first:

• another height constraint exists on the same view
• the stored outlet or property points to the wrong constraint
• the view is inside a layout system such as UIStackView that imposes different behavior
• 'translatesAutoresizingMaskIntoConstraints is still true for programmatic views'

A height-constraint update is simple when the view has one unambiguous vertical sizing rule. It becomes messy when multiple rules compete.

Common Pitfalls

• Recreating the height constraint every time instead of updating constant.
• Forgetting to keep a reference or outlet to the correct constraint.
• Calling layoutIfNeeded() outside the animation block when you expected an animated change.
• Letting another active constraint override the intended height.
• Forgetting translatesAutoresizingMaskIntoConstraints = false for programmatically created views.

Summary

• Keep a reference to the height constraint.
• Update the height by changing the constraint's constant.
• Call layoutIfNeeded() on the appropriate parent view after the change.
• For animations, put layoutIfNeeded() inside UIView.animate.
• Most issues come from duplicate constraints or from updating the wrong constraint object.