Привет! Меня зовут Антон Долганов, я старший iOS-разработчик в Контуре. Большую часть времени я работаю над инфраструктурными модулями, чтобы наши приложения были быстрыми, стабильными и легко развивались.

Следить за новинками платформы — также важная часть моей работы. Ведь чтобы инфраструктура не тормозила развитие продуктов, нужно заранее понимать, что изменится в iOS, какие риски появятся, и какие возможности можно будет использовать.

Каждый год в июне Apple проводит WWDC (Worldwide Developers Conference) — ключевое событие для разработчиков, где представляют новые версии iOS, macOS и других платформ. Именно здесь впервые анонсируют главные изменения, будь то новый дизайн, API или системные функции.

После анонса Apple выпускает бета-версии iOS, давая разработчикам целых три месяца (июнь–сентябрь) на тестирование и адаптацию приложений перед финальным релизом. Это критически важное окно, за которое можно:

• Найти и исправить критические баги.

• Адаптировать UI под новые стандарты.

• Обновить зависимости и инфраструктуру.

• Подготовить релизную версию приложения до выхода новой версии iOS у пользователей.

Но как правильно использовать это время? С чего начать и какие подводные камни можно встретить на пути? В этой статье я расскажу пошаговый подход нашей команды к подготовке приложений к новым версиям iOS. В качестве примера разберём версию iOS 26, но наш метод применим к любым будущим обновлениям.

iOS 26: почему это больше, чем просто обновление

Каждый год Apple выпускает новую версию iOS, но iOS 26 — это не просто очередной апдейт. Это масштабное преобразование дизайна и функциональности, требующее особого внимания разработчиков. Главная причина — совершенно новый визуальный язык Liquid Glass.

Liquid Glass — это глубокая трансформация интерфейса, вдохновлённая visionOS. Что нас ждёт:

• Полупрозрачные элементы с эффектом объёмного стекла, создающие ощущение глубины.

• «Плавающие» меню, которые теперь выглядят как элегантные таблетки вместо плоских панелей.

• Полностью обновлённая система иконок, виджетов и шторок.

Зачем готовиться к выходу новой версии iOS?

Казалось бы, если приложение уже работает стабильно, зачем тратить время на адаптацию под новую iOS? Разве Apple не гарантирует обратную совместимость? На практике всё сложнее. Новые версии iOS приносят не только фичи, но и риски.

Breaking Changes

Порой новая iOS ломает наши приложения. Причём Apple действительно старается сохранять совместимость, но каждый год в iOS появляются изменения, которые могут: 

• Сломать UI, например, из-за нового дизайна вроде Liquid Glass, особенно если ваше приложение использует кастомные UI-компоненты, они могут не просто выглядеть чужеродно в новой системе — некоторые элементы интерфейса могут вообще перестать работать корректно.

• Заблокировать ключевые функции (устаревшие API перестают работать).

• Испортить пользовательский опыт (неожиданные баги в навигации или анимациях).

• Если критичные баги обнаруживаются у пользователей, падение рейтинга и негативные отзывы неизбежны.

Исторический пример:

В iOS 14 компонент Text стал по умолчанию многострочным, что сломало вёрстку в некоторых приложениях, особенно если они использовали кастомные UI-компоненты. Разработчикам пришлось вручную исправлять отображение. 

Источник: Habr — SwiftUI на iOS 14: преодолевая баги

Проблемы с публикацией в App Store

• После выхода новой iOS увеличивается число отказов при ревью из-за несовместимости.

• В App Store Connect появляются предупреждения о необходимости обновить приложение.

Исторический пример:

iOS 13 и отказ от UIWebView: Apple объявила UIWebView устаревшим, что привело к массовым отказам приложений, использующих этот API. Разработчикам пришлось срочно переходить на WKWebView, иначе приложения не проходили ревью.

Источник: developer.apple — Updating Apps that Use Web Views

Возможности и конкурентоспособность

С выпуском новой версии iOS разработчики получают доступ к улучшенным возможностям платформы и современному дизайну. Чем быстрее вы внедрите эти новые функции и обеспечите их поддержку в своем приложении, тем выше шансы опередить конкурентов и удержать внимание пользователей.

Исторический пример:

Пользователи iOS обновляются значительно быстрее, чем многие думают: iOS 7 была установлена на 35% устройств уже в первый день, а iOS 14 достигла 90% установки всего за семь месяцев. По состоянию на январь 2025 года iOS 18 установлена на 68% iPhone.

Источник: techcrunch — iOS 18 hits 68% adoption across iPhones

План действий

Каждый июнь наша команда с нетерпением ждёт WWDC. Мы собираемся вместе для совместного просмотра либо следим за анонсами по отдельности, но в любом случае всё новое и интересное попадает в фокус обсуждения. Уже на следующей еженедельной iOS-встрече мы разбираем:

• Какие нововведения выкатили?

• Что сломается у нас в первую очередь?

• Какие нововведения стоит применить в первую очередь?

Именно на WWDC происходит первый контакт с новым iOS-обновлением — с новым дизайном, API, изменениями в системных компонентах и прочими «подарками». Так было и с iOS 26 и визуальным стилем Liquid Glass, с которым сразу стало понятно, что скучно не будет.

После WWDC Apple выкатывает первую бету iOS и среду разработки Xcode-beta. Но опыт подсказывает — не стоит торопиться с установкой. Первые беты чаще всего очень сырые. Всё может падать, тормозить и глючить, причём дело может быть вовсе не в наших приложениях, а в самой iOS.

Поэтому мы продолжаем спокойно жить и работать. Но чтобы всегда быть в курсе появления новых бета-версий и не тратить время на ручной мониторинг, у нас работает автоматизированный сервис. Он круглосуточно отслеживает выход обновлений Xcode и iOS, и как только Apple выпускает новую версию:

1. Создаёт новый тред в Mattermost.

2. Пингует инфраструктурную команду.

3. Ответственный принимает эстафетную палочку и стартует отлаженный процесс.

Подробнее про нашу систему автоматизации рассказывает мой коллега Женя Мельцайкин в отдельной статье на Хабре.

Когда вторая, третья и последующие беты начинают появляться, мы следим за ними более пристально. Каждый раз, как выходит новая версия Xcode или iOS, мы внимательно читаем Release Notes — смотрим, что пофиксили, какие баги остались, и есть ли важные изменения в SDK или поведении системных компонентов.

Да, можно начать действовать сразу, но наш опыт показывает: лучше немного подождать. Мы начинаем активные действия после выхода Public Beta, которая, как правило, появляется через 4–6 недель после WWDC. Это всё ещё не релиз, но уже вполне пригодный для более серьёзной работы — стабильность заметно выше, а шум вокруг критичных багов сильно спадает.

Дальнейшие шаги

После выхода стабильной публичной беты я, как ответственный за процесс адаптации под новую iOS, запускаю заранее заготовленный план действий. Он позволяет не теряться в хаосе изменений и обеспечивает командную синхронность.

Напоминаю всем о старте подготовки

Создаю отдельный тред в Mattermost, где:

• Напоминаю команде о начале подготовки к новой версии Xcode/iOS.

• Публикую план, чтобы все могли отслеживать прогресс и быть в контексте.

Готовлю инфраструктуру для тестов

У нас есть отдельная CI-машина, на которую можно удалённо установить Xcode Beta. Это удобно:

• Не нужно просить всех разработчиков ставить бету себе локально.

• Экономим часы на скачивание и установку.

• Можно спокойно и безопасно прогонять тесты и эксперименты, не ломая себе локальную среду.

---

Проверяю инфраструктурные модули

Прежде чем бросаться адаптировать боевые проекты под новую iOS, мы всегда начинаем с фундамента — инфраструктурных модулей. Именно на них опираются все приложения, и их стабильная работа — залог спокойной жизни всей команды.

У нас в команде таких модулей немало:

• С UI-составляющей: KonturAuth, KonturCabinet, KonturSupportCenter и другие.

• С системной/утилитарной логикой: KonturDependencyInjection, KonturMetrika, KonturNetworking, и т.п.

Но главная особенность — все модули подключены к единому Sample-приложению, которое служит универсальной средой для тестирования: оно позволяет быстро проверять работу каждого компонента по отдельности, а также их совместное взаимодействие в разных комбинациях.

Первый шаг — запуск Sample проекта

Как только Xcode Beta готова к работе, первым делом я открываю наше Sample-приложение, запускаю его и смотрю, как оно себя ведёт.

Сразу радует, что проект компилируется без ошибок — это уже хороший знак. На первых бетах обычно ничего не работает, что подтверждает мысль о том, что лучше не торопиться, а выждать стабильной версии. Дальше — ручной обход по всем основным модулям:

• Проверяю, работают ли экраны.

• Смотрю на UI.

• Щёлкаю основные кейсы.

Функционально всё, как правило, в порядке. Но вот UI — это отдельная история. С приходом новой iOS, особенно с новой визуальной парадигмой (в нашем случае — Liquid Glass), начинаются сюрпризы.

Примеры типичных проблем

KonturCabinet

Здесь обнаруживаем, что кнопки в верхней навигации рендерятся с визуальными дефектами: уехали, увеличилиcь, плохо читаются. 

Решение — сделать их ближе к системным стилям в iOS 26, т.е. стеклянными.

KonturAuth

Когда появляется BottomSheet с ошибкой в виде карточки — сверху накладывается белая подложка, перекрывающая системный эффект стеклянности.

Решение: убрать эту подложку, так как с новым дизайном прозрачность и глубина становятся частью UX.

И так далее — от KonturSupportCenter до KonturFeedback, проблемы в основном сосредоточены на визуальном слое.

Хорошая новость — 80% UI-компонентов идут из нашей дизайн-системы. А это значит, что достаточно внести правки в одном месте — и они сразу автоматически распространятся на все модули и проекты.

---

Проверка дизайн-системы

Следующий шаг — тестируем дизайн-систему, как отдельный артефакт. У нас для этого также есть отдельное Sample-приложение, которое мы называем «Галерея компонентов».

Если вам интересно поподробнее узнать про нашу дизайн-систему, то дайте нам знать в комментариях)

Галерея компонентов – это не просто набор экранов, а полноценный UI Playground:

• Все компоненты дизайн-системы.

• Разные состояния каждого из них.

• Поддержка светлой/тёмной темы.

• Проверка с динамическими шрифтами.

• Необходимые ресурсы: палитра цветов и шрифты.

• Сценарии «взаимодействия» между компонентами.

• И, конечно, Snapshot-тесты, которые помогают быстро выявить визуальные регрессии.

Где чаще всего всё ломается?

• NavigationBar — кнопки, фон, прозрачность. Особенно при кастомизации back-кнопки.

• TabBar — проблемы с размером табов и шрифтами.

• BottomSheet — перекрытия эффекта стекла.

• TextFields — слетающие placeholder-анимации, ломающиеся кастомные маски ввода телефона.

---

Дизайн и Figma

Параллельно, как только начинается адаптация UI, мы синхронизируемся с дизайнерами.

Так как Apple меняет визуальный стиль, нужно:

• Обновить макеты.

• Учесть визуальное поведение Liquid Glass.

• Перестроить взаимодействие компонентов на уровне гайдлайнов.

---

Подключаются команды продуктов

Когда базовая инфраструктура готова — даю отмашку в треде. С этого момента:

• Команды основных приложений (Диадок, Экстерн, Коннект, Подпись, Эльба и др.) подтягивают к себе обновления.

• Проверяют сборку и запуск на последнем симуляторе.

• Вносят нужные правки.

• Передают в тестирование.

RC — финальные проверки

После выхода Release Candidate Xcode:

• Обновляем CI-машину до финальной версии.

• При необходимости ещё раз прогоняем тесты.

• Проверяем, не появилось ли чего-то неожиданного под конец.

Финал: готовим релизы

Если всё готово — выкатываем новые версии приложений. К этому моменту:

• Обновлены зависимости.

• Обновлены макеты.

• Всё протестировано на новой версии iOS.

---

Что, если мы не успеваем?

Apple подстелила нам соломки в виде ключа UIDesignRequiresCompatibility

Что это за ключ?

UIDesignRequiresCompatibility — это Boolean-ключ в Info.plist, который управляет режимом отображения интерфейса приложения (т.е Liquid Glass) в новых версиях iOS.

Как работает?

• Если YES → iOS использует режим совместимости, и приложение выглядит так, будто собрано под старую версию SDK (например, iOS 18).

• Если NO (или ключ отсутствует) → iOS применяет новый дизайн системы, соответствующий текущей версии (iOS 26).

Важное уточнение:

Liquid Glass активируется только если приложение собрано в Xcode 26.

Проверил на практике:

• Установил iOS 26 beta на реальное устройство.

• Запустил несколько наших приложений (Sample, галерею компонентов, Диадок) — все выглядели как раньше, без Liquid Glass.

• Установил Xcode 26, собрал Sample — после этого Liquid Glass появился.

Выводы:

• Если вы не готовы к переходу на Liquid Glass, установите UIDesignRequiresCompatibility = YESв Info.plist или продолжайте собирать приложение на Xcode 16 — в этом случае Liquid Glass не появится.

• Если вы готовы к новому дизайну, соберите приложение на Xcode 26 и убедитесь, что параметр UIDesignRequiresCompatibility отсутствует или равен NO.

В заключение

1. Составьте план и назначьте ответственного — фиксируйте этапы подготовки, назначьте того, кто будет отслеживать бета-версии и устранять блокеры.

2. Не спешите с первыми бетами — дождитесь выхода стабильной версии.

3. Соблюдайте последовательность — сначала дизайн-система, затем инфраструктура, потом приложения.

4. Не чините фантомные баги — фиксируйте их в виде задачи, но ждите подтверждения в следующих бета-версиях.

5. Временные решения — только как исключение — механизмы вроде UIDesignRequiresCompatibility используйте лишь до полной адаптации.

6. Мониторьте после релиза — первые 72 часа важны для выявления проблем и оперативных хотфиксов.

Обновление iOS близко — но ваша подготовка уже сделала его безопасным)

Вперёд, к стабильному релизу!