Как SwiftUI-2025 устраняет две самые болезненные проблемы фреймворка

Когда в 2019 году Apple представила SwiftUI, его позиционировали как универсальный язык для создания интерфейсов на всех платформах — от iPhone до Vision Pro. И действительно, декларативный подход, превью в реальном времени в Xcode и единые модули для iOS, macOS, watchOS и tvOS быстро завоевали сердца разработчиков. Но начальный восторг вскоре сменился разочарованием: стоило понадобиться чуть более сложному полю ввода или встроенному веб-компоненту — приходилось возвращаться к UIKit / AppKit или использовать сомнительные сторонние библиотеки. В итоге тысячи программистов так и не решились полностью перейти на SwiftUI, откладывая «полную миграцию» на потом. Учитывая важность этой темы для разработчиков, в статье Ябко разбираем, что принесут новые изменения.

Наконец-то собственный редактор форматированного текста

Самым раздражающим «слепым пятном» фреймворка долгое время был ввод rich-text. Отобразить жирный или курсивный фрагмент SwiftUI умел, а вот принимать такой текст от пользователя — нет. Авторы заметок, мессенджеров и блог-клиентов были вынуждены встраивать UIViewRepresentable, оборачивать UITextView, писать тонны bridge-кода или использовать нестандартные атрибуты, что ломало превью в Xcode. По данным Bloomberg, в watchOS 12 / iOS 26 ситуация кардинально изменится: Apple добавит встроенный редактор rich-text с нативным API. Достаточно одной декларативной конструкции — и приложение получает поддержку изменения шрифта, размера, вставки ссылок и списков. Новый компонент при этом сохраняет «нативный» вид: на iPad активируется панель форматирования, на macOS — меню с привычными ⌘B и ⌘I.

Почему это важно?

• Единообразие. Пользователь видит одни и те же элементы управления во всех приложениях, а не разрозненные тулбары.
• Меньше кода. Не нужно больше поддерживать UIKit-обертки — меньше багов, быстрее релиз.
• Предпросмотр без хаоса. Xcode Canvas отображает результат корректно, потому что вся иерархия остается внутри SwiftUI.

Веб-окно без «моста» на 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 и дать фреймворку второй шанс.