Introduction

Nib-backed table view cells are a practical middle ground between storyboard-only layouts and fully code-driven UI. The reusable pattern is straightforward once the nib is registered correctly, the reuse identifier is stable, and the cell class owns its own configuration logic.

Create A Cell Class That Matches The Nib

Start with a custom UITableViewCell subclass and a nib whose root object is a table view cell. The nib name, class name, and reuse identifier do not have to be identical, but keeping them aligned reduces mistakes.

1import UIKit
2
3final class ProfileCell: UITableViewCell {
4    @IBOutlet private weak var nameLabel: UILabel!
5    @IBOutlet private weak var roleLabel: UILabel!
6
7    func configure(name: String, role: String) {
8        nameLabel.text = name
9        roleLabel.text = role
10    }
11}

In Interface Builder, set the root view to a table view cell, assign the custom class to ProfileCell, and use a reuse identifier such as ProfileCell. Connect the outlets from the nib to the cell subclass.

Register The Nib Before Dequeuing

The table view does not know about your nib automatically. Register it once, usually in viewDidLoad, before any call to dequeueReusableCell.

1import UIKit
2
3final class PeopleViewController: UIViewController, UITableViewDataSource {
4    @IBOutlet private weak var tableView: UITableView!
5
6    private let people = [
7        (name: "Ava", role: "Designer"),
8        (name: "Noah", role: "iOS Engineer"),
9        (name: "Mia", role: "Product Manager")
10    ]
11
12    override func viewDidLoad() {
13        super.viewDidLoad()
14
15        let nib = UINib(nibName: "ProfileCell", bundle: nil)
16        tableView.register(nib, forCellReuseIdentifier: "ProfileCell")
17        tableView.dataSource = self
18    }
19
20    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
21        people.count
22    }
23
24    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
25        guard let cell = tableView.dequeueReusableCell(
26            withIdentifier: "ProfileCell",
27            for: indexPath
28        ) as? ProfileCell else {
29            fatalError("Could not dequeue ProfileCell")
30        }
31
32        let person = people[indexPath.row]
33        cell.configure(name: person.name, role: person.role)
34        return cell
35    }
36}

This is the core reusable workflow. The table view manages creation and recycling, while your code only supplies row data.

Keep Setup Code In The Cell

A nib-backed cell should expose a small public API, often just one configure(...) method. Styling and one-time visual setup belong inside the cell rather than in the view controller.

1override func awakeFromNib() {
2    super.awakeFromNib()
3    selectionStyle = .none
4    contentView.layer.cornerRadius = 12
5    contentView.layer.masksToBounds = true
6}

If the cell contains transient or asynchronous state, reset it in prepareForReuse():

1override func prepareForReuse() {
2    super.prepareForReuse()
3    imageView?.image = nil
4}

That prevents recycled cells from showing stale content while new data is loading.

Consider Bundle Selection In Reusable Modules

bundle: nil works when the nib lives in the main app target. If the cell comes from a framework or shared UI module, load the nib from the bundle that owns the class.

let nib = UINib(nibName: "ProfileCell", bundle: Bundle(for: ProfileCell.self))
tableView.register(nib, forCellReuseIdentifier: "ProfileCell")

That detail becomes important when reusable UI components are packaged outside the main application target.

Know When A Nib Is The Right Choice

Nib-backed cells are great when visual editing speeds up layout work and the cell shape is reasonably stable. For extremely simple rows, a code-only cell may be faster to maintain. For highly dynamic view hierarchies shared across many contexts, programmatic layout can scale better.

The nib approach is strongest when you want Interface Builder convenience without giving up table view reuse.

Common Pitfalls

• Forgetting to register the nib before dequeuing the cell.
• Using different strings for the nib name and reuse identifier without keeping them in sync.
• Connecting outlets to the wrong object inside Interface Builder.
• Putting cell-specific rendering logic in the view controller instead of the cell class.
• Loading the nib from the wrong bundle when the cell lives in a framework.

Summary

• Create a custom UITableViewCell subclass and a matching nib.
• Register the nib with the table view before calling dequeueReusableCell.
• Keep content binding in a configure(...) method and cleanup in prepareForReuse().
• Use the correct bundle when the nib is packaged outside the main app target.