Introduction

In Interface Builder, true storyboard-backed static table view cells are supported only inside a UITableViewController. If you place a UITableView inside a plain UIViewController, you cannot use the built-in "Static Cells" mode the same way. That is the key limitation behind this question.

What "Static Cells" Really Means

When Apple says a table view uses static cells, it means the cell structure is defined in the storyboard and managed by a UITableViewController. The controller is part of the feature, not just a convenient wrapper.

So this is the important rule:

• 'UITableViewController supports storyboard static cells'
• 'UIViewController with an embedded UITableView does not'

That is why changing the controller class but keeping the same storyboard expectation does not work.

Option 1: Use a Child UITableViewController

If you need other UI around the table but still want storyboard static cells, embed a UITableViewController as a child view controller.

That lets you keep:

• static cell support
• table-specific lifecycle behavior
• surrounding custom UI in the parent controller

Conceptually:

1class ParentViewController: UIViewController {
2    override func viewDidLoad() {
3        super.viewDidLoad()
4        // embed child table controller in a container view
5    }
6}

This is the closest equivalent to "static table view outside UITableViewController" while still using the built-in static-cell feature.

Option 2: Use a Normal Dynamic Table With Fixed Data

Very often, the practical answer is to stop depending on static-cell mode and instead use a normal table view with a fixed data model:

1import UIKit
2
3final class SettingsViewController: UIViewController, UITableViewDataSource {
4    @IBOutlet weak var tableView: UITableView!
5
6    let rows = ["Profile", "Notifications", "About"]
7
8    override func viewDidLoad() {
9        super.viewDidLoad()
10        tableView.dataSource = self
11    }
12
13    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
14        rows.count
15    }
16
17    func tableView(
18        _ tableView: UITableView,
19        cellForRowAt indexPath: IndexPath
20    ) -> UITableViewCell {
21        let cell = tableView.dequeueReusableCell(withIdentifier: "Cell", for: indexPath)
22        cell.textLabel?.text = rows[indexPath.row]
23        return cell
24    }
25}

This is "dynamic" from UIKit's perspective, but if your array is fixed, it behaves like a static settings screen with far more flexibility.

Option 3: Use a Stack View for Form-Like Screens

If the content is truly fixed and not naturally tabular, a UIStackView plus custom views may be better than forcing everything into a table.

That is often cleaner for:

• profile forms
• settings screens with custom spacing
• mixed layouts that are not really row-based

Developers sometimes reach for static table cells when the UI is not actually a table problem at all.

Why UITableViewController Is Special

UITableViewController automatically manages things such as:

• table view ownership
• selection behavior
• content insets and scrolling defaults
• storyboard static-cell integration

When you leave that controller type, you gain layout freedom, but you lose the special-case static-cell support.

Common Pitfalls

The biggest mistake is expecting the "Static Cells" storyboard option to behave the same inside a plain UIViewController. It does not.

Another mistake is forcing a fixed settings layout into a full table view when a stack view or child controller would be simpler.

A third issue is recreating static behavior manually while still assuming UITableViewController conveniences are present.

Summary

• Storyboard static table view cells are supported only with UITableViewController.
• A plain UIViewController with a UITableView does not get that built-in static-cell mode.
• Use a child UITableViewController if you want static cells plus surrounding custom UI.
• Otherwise, use a normal table view with a fixed data source or switch to a stack-based layout.
• The right solution depends on whether the screen is truly a table or just a fixed form-like view.