Introduction

Custom table view cell height in UIKit can be either fixed, computed per row, or derived automatically from Auto Layout. The right choice depends on whether your content is predictable or variable, and many layout bugs come from mixing those approaches without a clear rule.

Fixed Height for Uniform Rows

If every cell in the table should have the same height, set a constant height through the table view delegate.

1import UIKit
2
3final class UsersViewController: UIViewController, UITableViewDelegate {
4    @IBOutlet private weak var tableView: UITableView!
5
6    override func viewDidLoad() {
7        super.viewDidLoad()
8        tableView.delegate = self
9    }
10
11    func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
12        return 72
13    }
14}

This is simple and predictable. If the design has identical rows with fixed-size content, a hard-coded height is often perfectly fine.

Different Heights for Different Row Types

Many screens mix cell styles, such as a compact summary row and a larger detail row. In that case, return a height based on your row model.

1import UIKit
2
3enum RowKind {
4    case summary
5    case detail
6}
7
8final class FeedViewController: UIViewController, UITableViewDelegate {
9    @IBOutlet private weak var tableView: UITableView!
10
11    private let rows: [RowKind] = [.summary, .detail, .summary]
12
13    override func viewDidLoad() {
14        super.viewDidLoad()
15        tableView.delegate = self
16    }
17
18    func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
19        switch rows[indexPath.row] {
20        case .summary:
21            return 60
22        case .detail:
23            return 120
24        }
25    }
26}

This is better than scattering row-number checks throughout the code. Heights should follow the meaning of the row, not its temporary position.

Self-Sizing Cells with Auto Layout

If the content length changes, such as multi-line labels or dynamic text sizes, self-sizing cells are usually the better solution. Apple’s Auto Layout guidance for self-sizing cells is to set rowHeight to automatic dimension and provide an estimated height.

1import UIKit
2
3final class MessagesViewController: UIViewController {
4    @IBOutlet private weak var tableView: UITableView!
5
6    override func viewDidLoad() {
7        super.viewDidLoad()
8        tableView.rowHeight = UITableView.automaticDimension
9        tableView.estimatedRowHeight = 88
10    }
11}

For that to work, the cell’s subviews must have a complete vertical constraint chain from the content view’s top to bottom.

Example custom cell:

1import UIKit
2
3final class MessageCell: UITableViewCell {
4    @IBOutlet private weak var titleLabel: UILabel!
5    @IBOutlet private weak var bodyLabel: UILabel!
6
7    override func awakeFromNib() {
8        super.awakeFromNib()
9        bodyLabel.numberOfLines = 0
10    }
11
12    func configure(title: String, body: String) {
13        titleLabel.text = title
14        bodyLabel.text = body
15    }
16}

If the label can grow vertically and the constraints are correct, the table view computes the cell height automatically.

When to Avoid heightForRowAt

Once you adopt self-sizing cells, avoid returning fixed heights from heightForRowAt unless you intentionally want to override Auto Layout. If you force a number there, you are telling the table view to stop asking Auto Layout for the real answer.

Use heightForRowAt when:

• height is fixed
• height depends on row type in a known way

Use automaticDimension when:

• content length changes
• Dynamic Type should resize text cleanly
• labels, images, or stacks can expand vertically

Mixing both without a clear reason often creates confusing bugs.

Performance Considerations

Self-sizing is powerful, but it is not free. The more complicated the cell hierarchy and constraints, the more work Auto Layout must do while scrolling.

Practical rules:

• provide a realistic estimatedRowHeight
• keep the constraint graph simple
• avoid expensive work in layoutSubviews
• configure reusable cells fully so old state does not affect measurement

Most apps should still choose self-sizing when the content is genuinely dynamic. The performance cost of correct sizing is usually lower than the maintenance cost of manual height math.

Common Pitfalls

The biggest mistake is turning on automaticDimension without giving the cell a complete vertical constraint setup. The table view cannot infer a height from incomplete constraints.

Another mistake is implementing heightForRowAt and expecting self-sizing to still decide the final height. The delegate method wins.

Developers also forget estimatedRowHeight. The table may still work, but scrolling and initial layout become less smooth because the system has poor estimates.

Finally, do not compute dynamic height by measuring text manually unless you have a strong reason. UIKit and Auto Layout already solve that problem well when the cell is constrained properly.

Summary

• Use heightForRowAt for fixed or clearly rule-based cell heights.
• Use UITableView.automaticDimension for content-driven heights.
• Self-sizing cells require a complete vertical Auto Layout chain inside the content view.
• Do not mix self-sizing and forced delegate heights accidentally.
• A good estimated height improves perceived scrolling performance.