Что делать, если ячейка не создается в UITableView

Что проверяют

Есть ли у вас система в отладке UIKit. Правильный ответ начинается не с перечня причин, а с развилки: метод создания ячейки не вызывается вовсе или вызывается, но результата не видно. Проверок в каждой ветке немного, и их ждут наизусть.

Как отвечать

Поставьте точку останова в tableView(_:cellForRowAt:) и посмотрите, заходит ли туда управление.

Если не заходит, ищите здесь:

• dataSource не назначен: забыли tableView.dataSource = self либо связь в конструкторе интерфейса отвалилась;
• numberOfRowsInSection возвращает ноль, потому что данные ещё не пришли или заполняется не тот массив;
• после загрузки не вызван reloadData, либо вызван не на главном потоке;
• у таблицы нулевой размер: нет ограничений разметки, нулевой фрейм, вложенность в контейнер без высоты.

Если заходит, но экран пуст:

• ячейка не зарегистрирована под тем идентификатором, который запрашивают. Вариант метода с for indexPath в этом случае не возвращает nil, а роняет приложение с сообщением про идентификатор;
• высота строки нулевая: при автоматической высоте содержимое contentView не привязано и к верхней, и к нижней границе;
• контент есть, но не виден: цвет совпал с фоном либо настраиваются свойства, которых у современной конфигурации ячейки уже нет.

Про UITableViewDiffableDataSource скажите отдельно: там пустой экран обычно означает, что снимок не применён или собран с повторяющимися идентификаторами.

Где спотыкаются

Сразу лезут внутрь cellForRowAt, хотя управление туда ни разу не зашло. Половина случаев решается на уровне источника данных и обновления таблицы.

Второе: обновляют данные из фонового потока после сетевого ответа. Таблица перерисовывается непредсказуемо, а иногда приложение падает без внятного места.

Третье: считают, что регистрация нужна всегда. Для прототипа из конструктора интерфейса она не нужна и даже вредна: ручная регистрация перекроет прототип, и настроенные в нём элементы пропадут.