UIKit — що це, ключові поняття та архітектура

Автор: IT Sectr Опубліковано: 2026-04-30 Час читання: 10 хв

UIKit — це фреймворк для побудови графічних інтерфейсів у додатках iOS та macOS. Набір включає UIView, UIViewController, елементи керування та систему Auto Layout, дозволяючи створювати адаптивні та інтерактивні екрани. За даними Apple Developer Documentation (2025), UIKit містить понад 200 класів для роботи з вікнами, в'юхами, анімаціями, жестами та текстом — це основа всіх додатків під iPhone та iPad.

Головне

  • UIKit — це фреймворк Apple для побудови інтерфейсів на iOS, iPadOS та macOS з імперативним підходом до керування в'юхами.
  • UIView — базовий клас для всіх візуальних елементів: кнопок, текстових полів, зображень та контейнерів.
  • UIViewController керує життєвим циклом екрана: від завантаження в'юхи до звільнення пам'яті.
  • Auto Layout описує положення елементів через систему констрейнтів, адаптуючи інтерфейс під різні розміри екранів.
  • Делегати та dataSource — ключовий патерн для таблиць і колекцій, що розділяє дані та їх відображення.

Що таке UIKit?

UIKit — це фреймворк від Apple, що надає класи для створення та керування користувацьким інтерфейсом на iOS, iPadOS та macOS (через Mac Catalyst). Він працює поверх Core Animation, Core Graphics та Quartz Core, абстрагуючи низькорівневе відтворення у високорівневі об'єкти — кнопки, мітки, зображення та контейнери. UIKit з'явився разом з iPhone OS 1 у 2007 році та залишається основним фреймворком для iOS-розробки поряд з SwiftUI.

Фреймворк слідує імперативному підходу: розробник створює екземпляри класів UIButton, UILabel, UIImageView, задає їх властивості (колір, шрифт, положення) та додає в ієрархію в'юх через addSubview. Кожна зміна інтерфейсу виконується явно — жодної магії оновлень за лаштунками. Це відрізняє UIKit від декларативних фреймворків на кшталт SwiftUI, де опис стану автоматично перемальовує інтерфейс.

Основні класи UIKit

Фреймворк включає кілька категорій класів. UIView — базовий елемент, від якого успадковуються всі візуальні компоненти. UIWindow — контейнер верхнього рівня, через який в'юхи відображаються на екрані. UIViewController — контролер, що керує набором в'юх та реагує на повороти екрана, появу клавіатури та системні сповіщення. UIApplication — точка входу, що обробляє події дотику та натискання кнопок.

Для тексту використовуються UILabel (статичний текст), UITextField (однорядкове введення), UITextView (багаторядкове введення). Для кнопок — UIButton, включаючи системні, кастомні та з іконографією SF Symbols. Для навігації — UINavigationController, UITabBarController та UISplitViewController. Всього в UIKit понад 200 публічних класів.

Архітектура UIKit: шари та ієрархія в'юх

Архітектура UIKit будується на шарах: кожен шар відповідає за свій аспект відображення. На найнижчому рівні знаходиться Core Graphics — рушій відтворення шляхів, тексту та зображень. Вище — Core Animation, що керує композицією шарів (CALayer) та анімаціями між станами. UIKit надбудовує поверх них об'єктно-орієнтований API: UIView, UIViewController та UIResponder.

Кожен додаток має ієрархію в'юх (view hierarchy) — дерево, коренем якого виступає UIWindow. Під ним — кореневий UIViewController, його в'юха, а всередині — вкладені subviews. Події дотику поширюються по ланцюжку responder chain: від найбільш вкладеної в'юхи до батьків і далі до UIApplication. Якщо жоден об'єкт не обробив дотик, він ігнорується.

UIView та CALayer

Кожен UIView містить шар CALayer, що відповідає за рендеринг пікселів на екрані. В'юха керує дотиками та accessibility, шар — графікою: shadow, cornerRadius, border, transform. Розділення дозволяє винести важку графіку на окрему нитку (render server), не блокуючи main thread. Apple рекомендує працювати з CALayer безпосередньо, якщо потрібно більше 200 в'юх на екрані — це знижує навантаження на CPU.

Responder Chain в деталях

Ланцюжок responder починається з об'єкта, який першим отримує подію дотику. Якщо він не обробляє подію (метод touchesBegan не перевизначено), подія передається наступному responder у ланцюжку: next, superview, next responder, UIViewController, UIWindow, UIApplication, App Delegate. Це дозволяє перехоплювати глобальні жести та клавіатурні події на рівні сцени, не додаючи обробник у кожну в'юху.

Життєвий цикл UIViewController

Кожен UIViewController проходить через строго визначену послідовність подій. Життєвий цикл включає фази: ініціалізація, завантаження в'юхи, поява на екрані, оновлення макету при повороті, приховування, вихід з екрана та звільнення пам'яті. Розробник перевизначає відповідні методи для виконання свого коду на кожному етапі.

swift
class ProfileViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        setupUI()
    }

    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)
        loadUserProfile()
    }

    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        clearCache()
    }
}

У viewDidLoad налаштовується інтерфейс — створюються сабв'юхи, задаються констрейнты, підписуються делегати. У viewWillAppear виконуються операції перед показом: завантаження свіжих даних з мережі, оновлення значень. viewDidDisappear — місце для відписки від сповіщень та очищення тимчасових даних. Виклик super обов'язковий у всіх перевизначеннях, інакше ланцюжок подій порушиться.

Керування пам'яттю та viewDidUnload

У старих версіях iOS існував метод viewDidUnload, що викликався при нестачі пам'яті. Починаючи з iOS 6 метод видалено — тепер UIKit автоматично вивантажує в'юхи контролера, коли вони не видимі. Розробнику достатньо встановити всі посилання на в'юхи як weak, щоб ARC коректно звільнив пам'ять при отриманні попередження від системи.

Переходи між контролерами

UIKit підтримує два типи переходів: segue (через Storyboard) та програмна навігація через UINavigationController. Програмний перехід виглядає так: navigationController?.pushViewController(detailVC, animated: true). При цьому життєвий цикл detailVC проходить у звичайному порядку — viewDidLoad викликається один раз, viewWillAppear — щоразу при показі.

Auto Layout та адаптивна верстка

Auto Layout — це система позиціонування елементів, заснована на математичних відношеннях (констрейнтах). Замість жорстко заданих координат X та Y розробник описує правила: «кнопка знаходиться праворуч від мітки з відступом 16pt» або «в'юха розтягується по ширині екрана з відступами 20pt ліворуч та праворуч». Система вирішує отриману систему рівнянь у runtime, адаптуючи інтерфейс під будь-який розмір екрана.

Констрейнты можна задати в Interface Builder (через drag-and-drop) або програмно на Swift. Кожен констрейнт — це екземпляр класу NSLayoutConstraint з параметрами: firstItem, firstAttribute, relation, secondItem, secondAttribute, multiplier, constant. Активувати констрейнты потрібно через isActive = true або масово через NSLayoutConstraint.activate().

Safe Area та Layout Margins

З появою iPhone X (2017) Apple ввела Safe Area — область екрана, вільна від notch, закруглених кутів та індикатора home bar. Констрейнты повинні прив'язуватися до view.safeAreaLayoutGuide, а не до view. Layout Margins додають внутрішні відступи в'юхи, за замовчуванням 8pt або 16pt залежно від контексту. Використання safeAreaLayoutGuide гарантує коректне відображення на всіх поколіннях iPhone та iPad.

Анімація констрейнтів

Auto Layout підтримує анімацію через зміну констант констрейнтів. Достатньо оновити constant констрейнта та викликати UIView.animate з layoutIfNeeded всередині блоку анімації. Система плавно перераховує положення всіх в'юх в ієрархії. Цей прийом використовується для блоків, що розкриваються, адаптивної панелі клавіатури та зміни орієнтації екрана.

Робота з таблицями та колекціями

UITableView та UICollectionView — два потужних інструменти UIKit для відображення списків та сіток. UITableView підходить для вертикальних списків з однією колонкою (чат, налаштування, стрічка новин). UICollectionView — для сіток, горизонтальних списків, каруселей та кастомних розкладок (галерея, продукти, календар). Обидва класи використовують патерн делегування для розділення даних та зовнішнього вигляду.

Джерелом даних виступає протокол UITableViewDataSource з обов'язковими методами numberOfRowsInSection та cellForRowAt. Делегат UITableViewDelegate обробляє натискання на комірки, висоту рядків та події скролу. Механізм reuse identifier перевикористовує комірки, що пішли за край екрана, що критично важливо для продуктивності на великих списках.

swift
class ContactsViewController: UITableViewController {

    private let contacts = ["Анна", "Борис", "Віктор"]

    override func viewDidLoad() {
        super.viewDidLoad()
        tableView.register(UITableViewCell.self,
                           forCellReuseIdentifier: "cell")
    }

    override func tableView(_ tableView: UITableView,
                          numberOfRowsInSection section: Int) -> Int {
        return contacts.count
    }

    override func tableView(_ tableView: UITableView,
                          cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "cell",
                                                 for: indexPath)
        var content = cell.defaultContentConfiguration()
        content.text = contacts[indexPath.row]
        cell.contentConfiguration = content
        return cell
    }
}

Приклад показує мінімальний контролер для відображення масиву рядків. Комірка конфігурується через UIListContentConfiguration — сучасний API (iOS 14+), що замінив застарілі textLabel та detailTextLabel. Реєстрація класу комірки в viewDidLoad обов'язкова, інакше додаток впаде з винятком у runtime.

UICollectionView та Compositional Layout

Починаючи з iOS 13, Apple рекомендує UICollectionViewCompositionalLayout для побудови складних розкладок. Розробник описує секцію, групу, елемент та їх розміри декларативно — виходить сітка з довільною геометрією: стрічка, сітка 2x2, карусель, орнамент. Compositional Layout замінив застарілий UICollectionViewFlowLayout для всіх нових проектів. У поєднанні з DiffableDataSource оновлення колекції зводиться до одного виклику apply(snapshot), а анімація змін виконується автоматично.

Приклади коду на Swift

Нижче наведено два практичних приклади використання UIKit в реальних завданнях: створення кастомної в'юхи з тінню та закругленням, а також обробка жесту свайпу для видалення елемента зі списку.

swift
extension UIView {
    func applyCardStyle() {
        layer.cornerRadius = 12
        layer.shadowOpacity = 0.15
        layer.shadowRadius = 8
        layer.shadowOffset = CGSize(width: 0, height: 2)
        layer.masksToBounds = false
    }
}

@objc private func handleSwipe(_ gesture: UISwipeGestureRecognizer) {
    guard let swipedView = gesture.view else { return }
    UIView.animate(withDuration: 0.3) {
        swipedView.alpha = 0
        swipedView.transform = CGAffineTransform(translationX: 300, y: 0)
    } completion: { _ in
        swipedView.removeFromSuperview()
    }
}

Розширення applyCardStyle додає тінь та закруглення будь-якій в'юсі — корисно для карток продуктів, профілів та сповіщень. Метод handleSwipe з анімацією видаляє елемент, якщо користувач провів по ньому вправо. Обробник додається на в'юху через addGestureRecognizer з конфігурацією UISwipeGestureRecognizer(direction: .right). Встановлення masksToBounds = false важливе, щоб тінь не обрізалася межами в'юхи.

Для більш складних інтерфейсів використовуйте UIStackView — контейнер, що автоматично розподіляє вкладені в'юхи по горизонталі або вертикалі. Stack View спрощує верстку: не потрібно задавати констрейнты для кожного елемента, достатньо одного констрейнта для самого стека.

Поширені запитання

У чому різниця між frame та bounds у UIView?

Frame — прямокутник у координатах superview (позиція + розмір). Bounds — прямокутник у власних координатах в'юхи (завжди починається з 0,0). Frame змінюється при rotate та scale, bounds — ні.

Як звільнити пам'ять від невикористовуваних в'юх?

UIKit автоматично вивантажує в'юхи прихованих контролерів. Розробнику достатньо оголошувати властивості в'юх як weak var, щоб ARC міг звільнити пам'ять при попередженні системи.

Чи варто використовувати Storyboard у 2026 році?

Для нових проектів Apple рекомендує SwiftUI. Якщо проект на UIKit — використовуйте XIB для окремих екранів або програмну верстку через SnapKit. Storyboard створює merge conflicts та уповільнює збірку.

Як реалізувати темну тему в UIKit?

Використовуйте UIColor з підтримкою traitCollection: UIColor { $0.userInterfaceStyle == .dark ? ... : ... }. Активуйте темний режим в Info.plist ключем UIUserInterfaceStyle.

Чим UIStackView кращий за ручні констрейнты?

UIStackView автоматично розраховує позиції та розміри вкладених в'юх на основі alignment, distribution та spacing. Це скорочує код констрейнтів на 60–80% та спрощує адаптацію під різні екрани.

Підсумки

  • UIKit — основний фреймворк Apple для побудови інтерфейсів iOS, iPadOS та macOS з імперативним підходом.
  • UIView керує відтворенням та дотиками; його графічну частину обробляє шар CALayer, що працює на окремій нитці.
  • UIViewController проходить строгий життєвий цикл: від viewDidLoad до звільнення пам'яті з можливістю перевизначити кожен етап.
  • Auto Layout замінює жорсткі координати системою констрейнтів, адаптуючи інтерфейс під будь-які екрани та орієнтації.
  • UITableView та UICollectionView з reuse identifier забезпечують продуктивність на великих списках та підтримують сучасний Compositional Layout.
  • UIStackView спрощує верстку послідовностей в'юх, скорочуючи код констрейнтів на 60–80%.
  • Для нових проектів Apple рекомендує SwiftUI, але UIKit залишається актуальним для підтримки старих iOS та складних кастомних інтерфейсів.

Ми розробимо мобільний застосунок під ключ

IT Sectr створює застосунки для iOS та Android для стартапів і бізнесу з 2017 року. Ми проконсультуємо вас і запропонуємо найкраще рішення.

Обговорити проект

Читайте також