> В чем разница UIView и UIViewController в iOS и зачем нужен UIViewController (iOS, Swift)

Короткий ответ

UIView - это визуальный элемент, который отвечает за отрисовку контента и обработку касаний. UIViewController - это контроллер, управляющий жизненным циклом view, его иерархией, навигацией и реакцией на изменения состояния (например, поворот экрана или появление на экране). UIViewController нужен, чтобы отделить логику управления от отображения и обеспечить переиспользуемость и тестируемость кода.

Подробное объяснение

UIView - это экземпляр класса, наследующего от UIView (или его подклассов, например UILabel, UITableView). Он содержит:

• frame/bounds и transform
• layer для отрисовки
• систему constraints
• обработку touches (через touchesBegan и т.д.)

UIView не знает, когда он появился на экране, как реагировать на смену ориентации, как управлять навигацией. Это чисто презентационный слой.

UIViewController - это объект, который:

• управляет одним корневым view (свойство view)
• реализует жизненный цикл: viewDidLoad, viewWillAppear, viewDidDisappear и т.д.
• обрабатывает rotation, appearance, memory warnings
• управляет child view controllers (например, в UINavigationController или UITabBarController)
• связывает модель и view (часто через delegation или closure)
• отвечает за навигацию (present/dismiss, push/pop)

Зачем нужен UIViewController:

1. Разделение ответственности - view не должен знать, откуда пришли данные и что делать при нажатии кнопки.
2. Управление жизненным циклом - контроллер знает, когда view появилась, исчезла, когда можно начинать анимации или останавливать таймеры.
3. Переиспользование - один и тот же view можно использовать в разных контроллерах, а контроллер - с разными view (через loadView).
4. Навигация и композиция - контроллеры образуют иерархию, что позволяет строить сложные экраны из простых.
5. Тестируемость - логику контроллера можно тестировать без реального view (например, через mock).

На практике

В реальном проекте вы почти никогда не создаёте UIView напрямую для экрана. Вы создаёте подкласс UIViewController, в viewDidLoad настраиваете иерархию subviews, задаёте constraints, подписываетесь на события. Сам view - это просто контейнер, который контроллер создаёт автоматически (или вы переопределяете loadView для кастомного view).

Типичный паттерн - UIViewController + отдельный UIView (например, MyScreenView), где view отвечает только за layout и отрисовку, а контроллер - за data source, actions и навигацию.

Также важно понимать, что UIViewController - это не просто "контроллер в MVC". В iOS он выполняет роль и presenter, и coordinator, и частично view model (если не использовать MVVM). Поэтому его часто называют "толстым" - и это нормально для платформенного подхода.

Пример кода

SWIFT
final class ProfileViewController: UIViewController {
    private let profileView = ProfileView() // кастомный UIView

    override func loadView() {
        view = profileView
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        profileView.onEditTap = { [weak self] in
            self?.openEditScreen()
        }
    }

    private func openEditScreen() {
        let editVC = EditProfileViewController()
        navigationController?.pushViewController(editVC, animated: true)
    }
}

final class ProfileView: UIView {
    var onEditTap: (() -> Void)?

    private let editButton = UIButton(type: .system)

    override init(frame: CGRect) {
        super.init(frame: frame)
        setupLayout()
    }

    private func setupLayout() {
        addSubview(editButton)
        editButton.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            editButton.centerXAnchor.constraint(equalTo: centerXAnchor),
            editButton.centerYAnchor.constraint(equalTo: centerYAnchor)
        ])
        editButton.addTarget(self, action: #selector(handleEditTap), for: .touchUpInside)
    }

    @objc private func handleEditTap() {
        onEditTap?()
    }
}

Как отвечать на собеседовании

Начните с чёткого разделения: view - это "что рисуется", контроллер - "кто управляет". Затем перечислите ключевые обязанности контроллера: жизненный цикл, навигация, обработка событий. Подчеркните, что UIViewController - это не просто обёртка над view, а полноценный элемент архитектуры, который решает задачи, не связанные с отрисовкой.

Если спросят про альтернативы - упомяните, что в SwiftUI роль контроллера частично берёт на себя сам view (через @State, @ObservableObject), но в UIKit без UIViewController не обойтись.

Что проверяет интервьюер

• Понимание разделения ответственности между view и controller.
• Знание жизненного цикла UIViewController и типичных ошибок (например, работа с view до viewDidLoad).
• Умение объяснить, зачем нужен контроллер, а не просто "так принято".
• Понимание, как контроллеры взаимодействуют с навигацией и композицией.
• Способность привести практический пример, где без контроллера нельзя обойтись.

Типичные ошибки

• Ответ "UIViewController - это просто класс, который содержит UIView" - слишком поверхностно.
• Смешивание понятий: "UIViewController управляет отрисовкой" - это делает view, контроллер управляет состоянием.
• Игнорирование жизненного цикла - если кандидат не упоминает viewDidLoad/viewWillAppear, это красный флаг.
• Утверждение, что UIViewController можно заменить на UIView, если "добавить туда логику" - это антипаттерн, который ломает архитектуру.
• Непонимание, что контроллер - это не обязательно "толстый" объект, но он всегда отвечает за координацию.