Introduction

When a UITableViewCell height set in storyboard seems to do nothing, the problem is usually not storyboard itself. Table views can get row height from several places: storyboard, explicit code, auto layout, and delegate methods. To fix the issue, you need to identify which source is currently winning and make the layout constraints support the height you expect.

Understand the Priority Order

Row height can be influenced by:

• the table view rowHeight property
• 'tableView(_:heightForRowAt:)'
• automatic dimension with constraints
• estimated row height settings
• storyboard prototype cell configuration

If you implement heightForRowAt, that value usually overrides the storyboard prototype height.

Example:

func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
    return 120
}

If this method exists, changing storyboard row height will not matter.

Fixed Height Setup

If you want a fixed height for every row, keep the setup simple and set it in code or storyboard, but not in multiple competing places.

1override func viewDidLoad() {
2    super.viewDidLoad()
3    tableView.rowHeight = 88
4}

This is usually enough when every cell shares the same height and there is no dynamic content.

Dynamic Height Setup with Auto Layout

If the cell should grow based on its content, use automatic dimension and fully constrained subviews.

1override func viewDidLoad() {
2    super.viewDidLoad()
3    tableView.rowHeight = UITableView.automaticDimension
4    tableView.estimatedRowHeight = 88
5}

For this to work, the cell’s content must have an unbroken vertical constraint chain from top to bottom of contentView.

Typical requirement:

• top constraint from first subview to content view
• vertical spacing between subviews
• bottom constraint from last subview to content view

Without those constraints, Auto Layout cannot determine the cell’s final height reliably.

Storyboard Height May Be Only a Placeholder

For self-sizing cells, the height you see in storyboard is often just a design-time preview, not the runtime answer. If runtime height is computed by Auto Layout, storyboard height is not authoritative.

That surprises many developers because Interface Builder makes the prototype look correct while the live table view ignores that preview size.

Check for Conflicting Delegate Code

If storyboard height changes do not appear, search for table view delegate methods first.

func tableView(_ tableView: UITableView, estimatedHeightForRowAt indexPath: IndexPath) -> CGFloat {
    return 60
}

Even estimated height methods can influence scrolling behavior and make the issue look like a wrong fixed height.

Also check for code in viewDidLoad, willDisplay, or table view subclasses that modifies rowHeight.

Constraint Problems Inside the Custom Cell

If automatic dimension is enabled but rows are still the wrong size, inspect the custom cell layout. A common issue is missing bottom constraints, ambiguous label heights, or hard-coded frame assumptions.

Example cell configuration:

1final class MessageCell: UITableViewCell {
2    @IBOutlet private weak var titleLabel: UILabel!
3    @IBOutlet private weak var bodyLabel: UILabel!
4
5    override func awakeFromNib() {
6        super.awakeFromNib()
7        bodyLabel.numberOfLines = 0
8    }
9}

Setting numberOfLines = 0 is necessary for multi-line labels, but it is not sufficient on its own. The label also needs constraints that let it expand vertically.

Debugging Checklist

A practical debugging sequence:

1. Remove heightForRowAt temporarily.
2. Decide whether height is fixed or automatic.
3. If fixed, set one explicit rowHeight.
4. If automatic, set UITableView.automaticDimension.
5. Inspect the cell’s vertical constraints and content hugging rules.

That isolates the source of truth quickly.

Common Pitfalls

The most common issue is forgetting that heightForRowAt overrides the storyboard setting. Developers keep changing storyboard values while runtime code is returning a different number.

Another problem is enabling automatic dimension without enough constraints inside the cell. The table view cannot infer a correct height from incomplete layout rules.

Storyboard row height also misleads people when it is only acting as a design-time preview rather than the runtime size.

Summary

• Storyboard row height is only one possible source of truth for cell height.
• 'heightForRowAt usually overrides storyboard settings.'
• For fixed-height cells, set one explicit rowHeight and keep the setup simple.
• For dynamic cells, use UITableView.automaticDimension with complete constraints.
• Debug by removing conflicts first, then checking the cell’s vertical constraint chain.