Introduction

UITableView does not have one official callback that means "I am completely done asking for data forever." That is because the table asks for rows lazily as cells become visible, as the user scrolls, and as layout changes.

So the real answer depends on what you actually need to know. Sometimes you want to know when reloadData() has finished laying out visible cells, sometimes when the last currently visible row was displayed, and sometimes when an asynchronous data fetch has finished before the table reload even starts.

Why There Is No Single "Finished" Callback

A table view asks its data source for information in phases:

• number of sections and rows
• cells for visible index paths
• more cells later as the user scrolls
• updated cells again after reloads or batch updates

That means this mental model is important: a table view is not like a one-shot parser that consumes all data once. It is a reusable, on-demand view.

If you are waiting for "finished asking for data," first decide whether you mean:

• finished reloading visible content
• finished displaying the currently visible rows
• finished loading the underlying model from the network or database

Those are different events.

After reloadData(), Use the Next Layout Pass

If your goal is "run code after the table has reloaded and laid out its visible rows," a common pattern is to force layout and then dispatch work to the next main-thread turn:

1import UIKit
2
3func reloadTableAndThen(_ tableView: UITableView, completion: @escaping () -> Void) {
4    tableView.reloadData()
5    tableView.layoutIfNeeded()
6
7    DispatchQueue.main.async {
8        completion()
9    }
10}

Usage:

reloadTableAndThen(tableView) {
    print("Visible cells are now laid out")
}

This does not mean the table will never ask for more data again. It only means the current reload cycle for visible content has completed.

Use willDisplay to Detect Visible Cell Completion

If you want to know when the last currently visible row is about to appear, tableView(_:willDisplay:forRowAt:) is often the right delegate hook:

1class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
2    @IBOutlet weak var tableView: UITableView!
3    var items: [String] = []
4
5    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
6        items.count
7    }
8
9    func tableView(_ tableView: UITableView,
10                   cellForRowAt indexPath: IndexPath) -> UITableViewCell {
11        let cell = tableView.dequeueReusableCell(withIdentifier: "Cell", for: indexPath)
12        cell.textLabel?.text = items[indexPath.row]
13        return cell
14    }
15
16    func tableView(_ tableView: UITableView,
17                   willDisplay cell: UITableViewCell,
18                   forRowAt indexPath: IndexPath) {
19        let lastRow = items.count - 1
20        if indexPath.row == lastRow {
21            print("Last row is being displayed")
22        }
23    }
24}

This is useful for pagination triggers or for hiding a loading spinner after the first real content becomes visible.

Distinguish UI Completion from Data Loading Completion

A very common mistake is using table view callbacks to represent data loading. If the actual requirement is "my network request finished and the model is ready," handle that in the async fetch code before reloading the table.

1func loadItems() {
2    fetchItemsFromServer { [weak self] result in
3        guard let self else { return }
4
5        switch result {
6        case .success(let newItems):
7            self.items = newItems
8            self.tableView.reloadData()
9        case .failure(let error):
10            print(error)
11        }
12    }
13}

The fetch callback tells you when the data is ready. The table view only tells you about rendering and display.

For Animated Updates, Use Batch Completion

If you are inserting or deleting rows with animation, performBatchUpdates gives you an actual completion callback:

1tableView.performBatchUpdates {
2    items.append("New item")
3    tableView.insertRows(at: [IndexPath(row: items.count - 1, section: 0)], with: .automatic)
4} completion: { finished in
5    print("Batch update finished: \(finished)")
6}

This is more precise than trying to infer completion indirectly from other delegate methods when the update is animated.

Common Pitfalls

• Expecting cellForRowAt to be called for every row immediately after reloadData().
• Using table view rendering callbacks as if they were network-loading callbacks.
• Assuming there is one global "done" event even though table views load lazily.
• Forgetting that scrolling can trigger more data requests later.
• Using willDisplay to detect model completion when it only reflects UI visibility.

Summary

• 'UITableView has no single callback meaning it is completely done asking for data.'
• After reloadData(), use layout plus the next main-thread cycle if you need post-reload UI work.
• Use willDisplay when you care about visible-row display events.
• Use async fetch completions when the real event is data readiness, not table rendering.
• Use performBatchUpdates completion for animated insert or delete operations.