-max-100.jpg.webp)
Коли у 2019-му Apple презентувала SwiftUI, його подали як універсальну мову побудови інтерфейсів для всіх платформ — від iPhone до Vision Pro. І справді, декларативний підхід, прев’ю «на льоту» у Xcode та спільні модулі для iOS, macOS, watchOS і tvOS швидко підкорили розробників. Проте ранній захват змінився розчаруванням: щойно виникала потреба у трохи складнішому полі вводу або веб-компоненті, доводилося повертатися до UIKit / AppKit або шукати сумнівні сторонні бібліотеки. У підсумку тисячі програмерів так і не зважилися писати суто на SwiftUI, відкладаючи “повну міграцію” на потім. Враховуючи важливість цієї теми для розробників далі в статті Ябко розглянемо, що принесуть ці оновлення.
Нарешті власний редактор збагаченого тексту
Найфрустраційнішим «сліпим кутом» фреймворку був rich-text input. Відобразити напівжирний чи курсивний фрагмент SwiftUI umів, а от прийняти такий текст від користувача — ні. Автори нотатників, месенджерів, блог-клієнтів змушені були вбудовувати UIViewRepresentable, обгортати UITextView, писати тонни бридж-коду або користуватися кастомними атрибутами, що ламали живі прев’ю. За даними Bloomberg, у watchOS 12 / iOS 26 ситуація радикально зміниться: Apple додає вбудований редактор збагаченого тексту зі стандартним API. Достатньо однієї декларативної конструкції — і додаток одразу підтримує зміни шрифту, розміру, вставку посилань чи списків. Важливо, що новий компонент зберігає «нативний» вигляд: на iPad він підхоплює панель форматування, на macOS — меню зі звичних ⌘B та ⌘I.
Чому це велика новина?
- Консистентність. Користувач отримує однакові елементи керування у всіх програмах, а не різнопланові тулбари.
- Менше коду. Зникає необхідність підтримувати UIKit-обгортки, а отже менше багів і швидший реліз.
- Прев’ю без хаосу. Xcode Canvas коректно відображає результат, бо вся ієрархія залишилася у SwiftUI-світі.
full.jpg.webp)
Веб-вікно без містка на UIKit
Друга болюча тема — WebView. Показати умовний help-центр, статтю з блогу чи інтегрувати платіжну форму в межах програми було легше на Flutter, ніж на «рідному» SwiftUI. Доводилося використовувати WKWebView через UIViewControllerRepresentable, та ще й писати окремі обгортки для macOS. Тепер WebKit-репозиторій засвітив новий API — SwiftUI EmbeddedWebView. За задумом Apple достатньо оголосити WebContent(url:yourURL) або WebContent(html:rawHTML), і компонент сам підбере рідний рендерер: WK — для iOS/tvOS, WK+AppKit — для macOS.
Що отримують розробники:
- Скорочення часу на MVP. Вставити політику конфіденційності чи маркетингову сторінку — питання однієї строфи.
- Єдиний стиль. WebView уживається з напівпрозорими панелями visionOS-подібного дизайну без ручного тюнінгу.
- Безпека за замовчанням. Усі політики sandbox, Intelligent Tracking Prevention та Private Relay під’єднуються автоматично.
Ефект для екосистеми
Дві маленькі деталі можуть зрушити гору, яку розробники обходили п’ять років. Якщо тепер можна робити сучасні нотатники, месенджери чи медіа-клаєнти, не залишаючи декларативний ландшафт, попит на SwiftUI сплесне. Це, у свою чергу, означає:
- Більше якісних універсальних додатків. Одна кодова база обслуговує iPhone, iPad, Mac, Apple Watch та Apple TV, тож функції синхронізуються без відмінностей у логіці.
- Швидші оновлення. Без старих «містків» менше ризику поламати UI при виході нових версій систем.
- Єдине візуальне ядро. visionOS-подібний дизайн приходить безпосередньо в екосистему App Store, що робить взаємодію інтуїтивнішою для користувача.
Що далі?
На WWDC-2025 Apple, ймовірно, покаже ще кілька кроків у бік «повного SwiftUI». Аналітики чекають оновлення List із віртуалізацією великої кількості рядків та гнучкішого Layout-протоколу для складних решіток. Але вже зараз стає ясно: купертинці почули зворотний зв’язок і готові перетворити свій декларативний фреймворк із перспективної концепції на справді універсальний інструмент. І якщо ви відкладали перехід на SwiftUI — саме час оновити Xcode та дати фреймворку другий шанс.
