Introduction

When UITableView cell heights become correct only after scrolling, the table view is usually fixing an earlier layout problem during later layout passes. In most cases the root cause is incomplete Auto Layout constraints, inaccurate estimated heights, or content being assigned after the cell's size was first calculated.

Start With Self-Sizing Cells

Modern self-sizing table cells rely on Auto Layout, not manual height math. The basic setup should look like this.

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

That tells the table view to ask Auto Layout for the final size while using the estimate for initial layout performance.

If estimatedRowHeight is wildly wrong, the first render can look unstable. The table usually repairs itself once scrolling triggers more measurement and reuse.

Constraints Must Form a Full Vertical Chain

Inside the cell, Auto Layout must be able to infer the content view's top-to-bottom size without ambiguity.

That means your subviews usually need:

• a constraint from the top-most view to contentView.topAnchor
• constraints between intermediate views
• a constraint from the bottom-most view to contentView.bottomAnchor

A typical label-based cell looks like this.

1final class MessageCell: UITableViewCell {
2    let messageLabel = UILabel()
3
4    override init(style: UITableViewCell.CellStyle, reuseIdentifier: String?) {
5        super.init(style: style, reuseIdentifier: reuseIdentifier)
6
7        messageLabel.numberOfLines = 0
8        messageLabel.translatesAutoresizingMaskIntoConstraints = false
9        contentView.addSubview(messageLabel)
10
11        NSLayoutConstraint.activate([
12            messageLabel.topAnchor.constraint(equalTo: contentView.topAnchor, constant: 12),
13            messageLabel.leadingAnchor.constraint(equalTo: contentView.leadingAnchor, constant: 16),
14            messageLabel.trailingAnchor.constraint(equalTo: contentView.trailingAnchor, constant: -16),
15            messageLabel.bottomAnchor.constraint(equalTo: contentView.bottomAnchor, constant: -12)
16        ])
17    }
18
19    required init?(coder: NSCoder) {
20        fatalError("init(coder:) has not been implemented")
21    }
22}

If the bottom constraint is missing, the cell often appears to work partially, then corrects later when the system gets another chance to layout.

Content Timing Matters

Another frequent cause is setting or changing the cell content after the table view has already measured it. For example, asynchronous text updates or image loads can invalidate the original size.

In that situation, update the model, then tell the table view to recalculate layout.

tableView.beginUpdates()
tableView.endUpdates()

That forces the table view to re-query heights and re-layout visible cells without a full reload.

If the content change affects many rows, reloadData() may be simpler, but beginUpdates and endUpdates are often smoother for visible dynamic cells.

Check Labels and Preferred Width

Multi-line labels are especially common in this bug.

Make sure:

• 'numberOfLines = 0'
• the label has leading and trailing constraints
• the label is inside the cell's contentView
• no conflicting height constraint forces a fixed size

If you calculate attributed text or set preferred widths manually, do it before height calculation, not later inside a delayed callback.

Asynchronous Images and Dynamic Height

Cells that contain remote images often look wrong at first because the placeholder size and final image size differ.

A good pattern is:

• define an image view with stable constraints
• keep a consistent aspect-ratio rule where possible
• reload or re-layout the row after the image size becomes known

If the image view has no predictable height before the image arrives, the table view cannot guess correctly during the first pass.

Common Pitfalls

The biggest mistake is assuming automaticDimension is enough by itself. It only works when the constraints fully describe the cell's height.

Another mistake is adding subviews directly to the cell instead of contentView. Self-sizing behavior is more reliable when constraints are rooted in contentView.

A third issue is setting an extremely inaccurate estimatedRowHeight, which causes the initial layout to be visibly wrong until the table refines the measurements.

Finally, do not ignore when scrolling "fixes" the issue. That usually means the first layout pass lacked information, and the second pass got it. The fix is to make the first pass complete.

Summary

• Dynamic cell heights depend on automaticDimension plus correct Auto Layout constraints.
• Constraints must form a complete vertical chain inside contentView.
• Use a realistic estimatedRowHeight to avoid bad first-pass layout.
• If content changes after measurement, trigger a layout update with beginUpdates and endUpdates.
• Multi-line labels and async images are the most common sources of height mismatches.
• If scrolling fixes it, the initial layout information was incomplete.