Я бы абсолютно считал это «представлением» (с точки зрения MVC). Это из группы логики, которая (наряду с .xib) обрабатывает 1 конкретный вид информации, а не управляет некоторым аспектом общей логики приложения.
Я также считаю UIViewController принадлежащим к части "view" MVC по той же причине. Конечно, если вы поместите в контроллеры представлений гораздо больше бизнес-логики, чем необходимо для поддержки одного представления, то ваш контроллер представлений представляет собой некоторую смесь MVC. Например, если ваш контроллер представления выбирает, какая сцена приложения будет следующей, тогда ваш контроллер представления участвует в логике контроллера, и он на самом деле не следует MVC. Тем не менее, ваш контроллер представления вынужден выполнять большую часть работы, связанной с одним представлением, поскольку существует только одно представление, за которое он отвечает, и что работа с представлениями выполняется практически в UIViewController, а не в UIView.
Так что, когда вы спрашиваете о позиции класса представления ячейки в MVC, если он выполняет работу с одним представлением, тогда это «представление». Если вы смешиваете работу контролера или работу модели, то вы запутали разделение обязанностей, которое поддерживает MVC.