Introduction

An empty table should not look like a broken screen. If a search or data load returns zero rows, the user needs a clear "No Results" or empty-state view so they understand what happened and what to do next.

In iOS UIKit, use the table view's backgroundView

For UITableView, the cleanest pattern is often to swap in a placeholder view when the data source is empty:

1import UIKit
2
3final class ResultsViewController: UITableViewController {
4    private var items: [String] = []
5
6    override func viewDidLoad() {
7        super.viewDidLoad()
8        updateEmptyState()
9    }
10
11    private func updateEmptyState() {
12        if items.isEmpty {
13            let label = UILabel()
14            label.text = "No Results"
15            label.textAlignment = .center
16            label.textColor = .secondaryLabel
17            tableView.backgroundView = label
18        } else {
19            tableView.backgroundView = nil
20        }
21    }
22
23    override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
24        items.count
25    }
26}

This works well because the message appears inside the table view area without interfering with your navigation bar or other layout.

Refresh the empty state whenever data changes

The most important rule is that the empty-state view must be updated at the same time as the data source:

1func applyResults(_ results: [String]) {
2    items = results
3    tableView.reloadData()
4    updateEmptyState()
5}

If you only reload the table and forget the empty-state logic, the UI can get stuck showing old state.

This matters for:

• first load
• search filtering
• pull to refresh
• network retry
• deletion of the last item

Any path that changes the backing array should also update the empty-state UI.

Show more than a bare message when helpful

A good empty state often includes context or an action. For example:

• "No Results"
• "Try a different search term"
• a retry button
• a reset-filters button

You can use a custom container view instead of a single label:

1let container = UIStackView()
2container.axis = .vertical
3container.alignment = .center
4container.spacing = 8
5
6let title = UILabel()
7title.text = "No Results"
8title.font = .preferredFont(forTextStyle: .headline)
9
10let subtitle = UILabel()
11subtitle.text = "Try changing your filters."
12subtitle.textColor = .secondaryLabel
13
14container.addArrangedSubview(title)
15container.addArrangedSubview(subtitle)
16
17tableView.backgroundView = container

This gives the user a clear next step instead of only confirming that nothing was found.

Web and React follow the same idea

Even if your platform is not iOS, the design principle is identical: render the table only when there is data, and render an empty state otherwise.

React example:

1function ResultsTable({ rows }) {
2  if (rows.length === 0) {
3    return <div className="empty-state">No Results</div>;
4  }
5
6  return (
7    <table>
8      <tbody>
9        {rows.map((row) => (
10          <tr key={row.id}>
11            <td>{row.name}</td>
12          </tr>
13        ))}
14      </tbody>
15    </table>
16  );
17}

The technical implementation changes by framework, but the UX rule is the same: empty data should produce an intentional screen state, not a blank mystery.

Distinguish "empty" from "loading" and "error"

One subtle but important improvement is to separate three different states:

• loading
• empty
• error

If you show "No Results" before the network request finishes, the UI feels wrong. If the request failed, showing "No Results" hides the real problem.

That means your state model should distinguish:

• 'isLoading'
• 'error'
• 'items.isEmpty'

and render accordingly.

Common Pitfalls

The biggest mistake is showing an empty table with no explanation. Users often read that as broken loading rather than a legitimate empty result.

Another common issue is forgetting to clear the placeholder when results arrive, leaving "No Results" visible behind actual rows.

People also confuse empty state with error state. "No Results" is not the same thing as "Request failed."

Finally, empty states work best when they suggest a next action. A dead-end message is better than silence, but still not ideal.

Summary

• Empty tables should display an intentional empty state rather than a blank screen.
• In UITableView, backgroundView is a simple and effective way to show "No Results."
• Update the empty-state UI every time the backing data changes.
• Distinguish empty, loading, and error states clearly.
• Add helpful context or recovery actions when the user can do something about the empty result.