Swift 6 простыми словами: многопоточность, тесты, ошибки и переход на новую версию

Swift 6 — самое масштабное обновление языка от Apple с момента появления async/await в Swift 5.5. Главное нововведение — защита от гонок данных на уровне компилятора: ошибки многопоточности, которые раньше проявлялись только на устройстве пользователя в самый неподходящий момент, теперь обнаруживаются ещё на этапе сборки — как обычные ошибки в swift build. Всё остальное — новый фреймворк Swift Testing, улучшения any Sendable, типизированные ошибки, изоляция по регионам, кроссплатформенный Foundation — строится вокруг этого одного важного изменения в том, как Swift работает с многопоточностью.

Этот разбор — та самая статья «что нового в Swift 6», которой нам не хватало, когда мы начинали мигрировать собственные iOS-приложения. Здесь акцент на решениях: что даёт каждая фича в продакшене, сколько стоит миграция и когда её стоит включать в реальную кодовую базу, а не только в учебных примерах. Все примеры взяты из практики — из того, как мы делаем видеоконференции, стриминг и iOS-продукты с ИИ для клиентов.

Почему именно Фора Софт пишет этот разбор Swift 6

Фора Софт разрабатывает iOS-приложения на Swift для клиентов из сфер EdTech, e-health, медиа и корпоративного видео. В 2024–2025 годах мы обновили собственные продакшен-проекты до Swift 6 — в том числе iOS-клиент обучающей платформы BrainCert, приложение для видеоэффектов в реальном времени SuperPower FX и мобильные инструменты для корпоративной видеоплатформы VALT. Каждая миграция столкнулась со своими трудностями, связанными с многопоточностью, поэтому описанные ниже компромиссы — не теоретические, а проверенные практикой.

Мы используем Agent Engineering (старшие инженеры курируют Cursor, Claude, Copilot), чтобы миграции на Swift 6 укладывались в бюджет: более строгая диагностика компилятора неожиданно хорошо сочетается с правками, которые предлагает ИИ — каждое предложенное исправление обязано пройти более строгую проверку типов и многопоточности, прежде чем попасть в код. В результате наши оценки на миграцию обычно оказываются на 20–40% ниже стандартных ставок агентств.

Сжатая хронология — от Swift 5.1 до Swift 6

Swift 6 — итог пятилетнего развития. Каждый релиз серии 5.х добавлял новый элемент модели многопоточности; Swift 6 изменил стандартные настройки и полностью интегрировал эту модель в систему типов.

Строгая проверка многопоточности по умолчанию

Главное изменение в Swift 6 — полная проверка многопоточности включена по умолчанию в режиме языка -swift-version 6. Компилятор теперь отвергает все пути выполнения, при которых возможно разделение изменяемого состояния между доменами изоляции. Там, где в Swift 5.х выдавалось только предупреждение, в Swift 6 возникает ошибка сборки.

На практике это значит: классы, не соответствующие Sendable, не могут использоваться в замыканиях с @Sendable; значения, переходящие между акторами, должны быть передаваемыми; глобальное изменяемое состояние без изоляции вызывает ошибку компиляции. Основная сложность миграции — проверить, что код действительно безопасен, и исправить всё, что не проходит проверку.

// Swift 5: compiles with a warning
class CounterUnsafe {
  var value = 0
}
let c = CounterUnsafe()
Task.detached { c.value += 1 }  // data race, warning only

// Swift 6: compile error unless `Counter` is an actor
// or Sendable-safe
actor Counter {
  private(set) var value = 0
  func bump() { value += 1 }
}
let counter = Counter()
Task { await counter.bump() }   // compiler is happy

Region-based isolation (SE-0414) — меньше аннотаций Sendable

Фича, благодаря которой строгая многопоточность становится терпимой, — region-based isolation. Вместо требования помечать каждый тип как Sendable, компилятор отслеживает, какие значения пересекают границы изоляции, и возражает только тогда, когда настоящая гонка действительно возможна.

В типичной миграции приложения region-based isolation сокращает число добавляемых аннотаций Sendable на 50–70%. Не-Sendable значение, созданное на MainActor и переданное в Task на том же акторе, — в порядке; компилятор недоволен лишь тогда, когда видит, что это значение уходит в другой домен изоляции.

Практический эффект: меньше диффов на ревью, меньше механических обходных extension Foo: @unchecked Sendable {}, гниющих в кодовой базе, и меньше церемоний на пути к защите от гонок данных.

Параметры и значения sending (SE-0430)

Ключевое слово sending помечает значения, которые компилятор может безопасно передать через границу изоляции — обычно потому, что вызывающая сторона после вызова к ним больше не обращается. Это устраняет целый класс дилемм «сделать Sendable или клонировать» и заменяет их точной локальной аннотацией.

actor Uploader {
  func send(_ payload: sending Payload) async throws {
    // The compiler verifies the caller released the Payload.
    // We can safely mutate it across the actor boundary.
  }
}

В коде обработки видео и стриминга, где буферы постоянно передаются по конвейерам, именно sending позволил сделать строгую многопоточность жизнеспособной в SuperPower FX. Буферы живут недолго; пометить их как sending — более точный подход, чем объявлять их Sendable.

Типизированные ошибки (SE-0413) — чёткие контракты на ошибки

В Swift 6 появились типизированные ошибки: теперь функция может указать, какой именно тип ошибки она может выбросить, а не просто использовать throws, означающий любое возможное исключение.

enum UploadError: Error { case network, serialization, size }

func upload(_ file: URL) throws(UploadError) -> UploadID {
  // Only UploadError cases compile.
}

Применяйте типизированные ошибки на границах библиотек (входные точки SDK, сетевой слой, файловый I/О), где количество возможных сбоев невелико и полностью известно. Во внутреннем коде используйте нетипизированный throws — жёсткая типизация ошибок слишком глубоко в коде приводит к трудоёмким правкам при появлении новых типов сбоев.

Noncopyable-типы (SE-0390 / SE-0437) — RAII на значимых типах

Swift 6 переводит noncopyable-типы (~Copyable) из превью в стабильное состояние с более широкой поддержкой в стандартной библиотеке. Используйте их для значений, представляющих уникальный ресурс: файловый дескриптор, токен мьютекса, хэндл GPU-буфера, текущую сетевую транзакцию. Компилятор не позволит случайно скопировать такое значение — вы не сможете дважды закрыть один и тот же файл или случайно потерять блокировку.

struct FileHandle: ~Copyable {
  private let fd: CInt
  init(_ path: String) throws { /* open fd */ }
  consuming func close() { /* close fd */ }
  deinit { /* close if not consumed */ }
}

func write(to file: borrowing FileHandle) { /* ... */ }

Это ответ Swift на move-семантику C++ и систему владения в Rust, но без полного контроля со стороны borrow-checker. Для мобильного видеокода, работающего с GPU-буферами, аппаратными кодировщиками и сессиями захвата, такой подход устраняет целый класс трудноуловимых утечек.

Swift Testing — альтернатива XCTest, которая поставляется вместе с Xcode

Swift Testing — новый фреймворк на макросах, который поставляется вместе со Swift 6. Он заменяет цепочки XCTAssert одним #expect и сразу поддерживает параметризованные тесты, теги, трейты и сьюты.

import Testing

@Suite("Uploader")
struct UploaderTests {
  @Test(arguments: [1024, 5 * 1024 * 1024, 100 * 1024 * 1024])
  func respectsSizeLimit(size: Int) async throws {
    let result = try await upload(size: size)
    #expect(result.status != .rejected)
  }
}

Swift Testing работает параллельно с XCTest, поэтому миграцию можно проводить постепенно — по одной фиче за раз. Новые тесты пишите на Swift Testing, а существующие сьюты XCTest оставляйте без изменений, пока вы не будете редактировать эти файлы по другим причинам. К тому моменту, когда дойдёте до самых активно изменяющихся частей кода, большая часть тестов уже будет переписана — без необходимости делать масштабный рефакторинг за один раз.

Swift Testing мы используем вместе с инструментами ИИ-QA, о которых рассказывается в нашей статье о процессах тестирования: Swift Testing — для юнит-тестов и быстрых интеграционных проверок, Reflect Mobile / Zentester — для end-to-end UI-сценариев. Именно такая комбинация позволяет нам поддерживать стабильный ритм релизов даже на сложных видеоприложениях.

Foundation на Swift — macOS, iOS, Linux, Windows, Android

Swift 6 завершает переписывание Foundation на Swift. Поведение Date, URL, JSONEncoder, String и других типов теперь одинаково на платформах Apple и вне их экосистемы. При этом производительность на устройствах Apple остаётся близкой к версии на Objective-C или даже выше.

Вместе с рабочей группой Swift on Android 2025 года Swift впервые с тех пор, как Objective-C стал основным языком, становится реальным выбором для общей логики между iOS, Android, macOS, Linux и Windows. Один язык может использоваться на всех платформах полностековой системы и полностью передавать доменную модель — более подробный контекст по Swift on Android см. в нашем дайджесте лета 2025 года.

Макросы повзрослели — практические паттерны

Макросы появились в Swift 5.9 и стали стабильными к версии 6.0: улучшилась диагностика, инструментальная поддержка стала надёжнее, а число встроенных макросов — больше (@Observable, @Suite, @Test). Четыре случая, когда макросы действительно оправдывают себя в наших приложениях:

1. Наблюдение. @Observable заменяет шаблонный код ObservableObject/@Published одним атрибутом и корректно работает со строгой многопоточностью.

2. Кодогенерация для сериализации. Собственные макросы вида @CodedAt / @Freestanding избавляют от необходимости вручную писать ключи для сериализации в доменных типах.

3. Эргономика тестов. @Test, #expect и #require позволяют объединить три строки XCTest в одну.

4. Константы времени сборки. API-ключи и схемы remote-config задают на этапе компиляции, а не как строки во время выполнения.

Поэтапный план миграции, совместимый с настоящими релизами

Попытка переключить продакшен-приложение на Swift 6 за один спринт — верный способ испортить выходные. Мы разбиваем миграцию на четыре этапа, каждый из которых отправляется в релиз вместе с обычными изменениями.

Фаза 1 — зафиксировать кодовую базу на Swift 5.10 с полной проверкой. Включите SWIFT_STRICT_CONCURRENCY=complete. Выпускайте релизы с предупреждениями. Ведите в CI график накопления предупреждений — так регрессии будут видны сразу.

Фаза 2 — заменить глобальное изменяемое состояние акторами или синглтонами с @MainActor. Большинство предупреждений возникают именно из-за этого. Не поддавайтесь искушению использовать @unchecked Sendable — компилятор почти всегда прав.

Фаза 3 — доработать границы библиотек. Добавьте Sendable, sending и типизированные ошибки в интерфейсы SDK. Внутренний код можно отложить.

Фаза 4 — переключиться на -swift-version 6. Когда предупреждений не остаётся, переход проходит без сбоев. Праздновать стоит тихо — основная работа была в фазах 2 и 3.

Сколько это стоит — миграция на Swift 6 в инженеро-неделях

Ориентиры из наших собственных миграций в продакшене. Цифры сильно зависят от чистоты кода: приложения, уже использующие async/await, попадают в нижнюю границу.

1. Небольшое iOS-приложение (<50 тыс. строк, в основном async/await). 2–4 инженеро-недели — в основном добавление Sendable и точечные правки нескольких глобальных проблемных мест.

2. Среднее приложение (50–200 тыс. строк, смесь GCD и async). 6–10 инженеро-недель. Основная работа — перенастроить очереди GCD на акторы и убрать синглтоны с общим состоянием.

3. Крупное приложение (200 тыс.+ строк, много моста с Objective-С). 12–20 инженеро-недель, распределённых на два-три релиза.

4. SDK с публичным API. Добавьте сверху 2–3 недели на аккуратную версионированную аннотацию Sendable, sending и типизированных ошибок — чтобы зависимые приложения могли мигрировать в удобном для них темпе.

По нашему опыту, Agent Engineering сокращает каждый бакет на 20–40%: более строгий компилятор неожиданно хорошо сочетается с правками от ИИ — каждое предложение теперь обрабатывается в новом режиме, поэтому ложные срабатывания ИИ отсеиваются мгновенно. Чтобы получить защитимую оценку под вашу кодовую базу, свяжитесь с нами по телефону или почте ниже.

Мини-кейс — Swift 6 в приложении с видео в реальном времени

Ситуация. Продакшен-приложение для iOS с захватом видео в реальном времени, выполнением машинного обучения на устройстве и сетевым стеком на основе GCD. Полная проверка на Swift 5.10 выдавала более 400 предупреждений. Цель — перейти на Swift 6, не нарушая ритм релизов (раз в две недели) и не ухудшая KPI по просадкам кадров.

12-недельный план. Недели 1–3: выгорание предупреждений по глобальным синглтонам через изолированный @MainActor-актор AppState и перенос трёх очередей GCD в актор пайплайна захвата. Недели 4–7: разметить поверхности видеокодека и сетевого SDK sending и Sendable, ввести сьюты Swift Testing в двух самых активно меняющихся модулях. Недели 8–10: закрыть последние 50 предупреждений мелкими рефакторингами, плюс одно сознательное @unchecked Sendable на специально разделяемом кэше — с задокументированным обоснованием. Недели 11–12: переключить -swift-version 6, выкатить под фичефлагом, раскатать на всю аудиторию.

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

Решающий фреймворк — внедрять ли Swift 6 в этом квартале?

1. Кодовая база уже на async/await? Если нет — сначала перейдите на async/await. Выигрыши Swift 6 на асинхронном коде мультипликативны.

2. Включена ли полная проверка в Swift 5.10? Если да, основная работа уже сделана — переключайтесь на новый режим в ближайшем релизе. Если нет, это и есть фаза 1.

3. Команда уверенно работает с акторами и изоляцией? Запланируйте короткий обучающий спринт до миграции — два дня на реальных примерах сэкономят две недели споров из-за ошибок компиляции.

4. Вы выпускаете публичный SDK? Заложите дополнительный буфер на версионированные аннотации и подготовьте понятное руководство по миграции для пользователей вашего SDK.

5. Какая доля сбоев приходится на многопоточность? Если в топ-5 падений значительная часть связана с многопоточностью, миграция окупится уже в первом релизе после перехода. Если нет — планируйте её вместе с другими задачами и внедряйте по возможности.

Чего стоит избегать

1. Слишком быстро тянуться к @unchecked Sendable. Каждый такой обход — технический долг. Если он действительно нужен, обязательно объясните причину; если нет — пересмотрите архитектуру.

2. Перегружать внутренний код типизированными ошибками. Сохраняйте типизированные ошибки для границ библиотек. Внутренний код, который продолжает развиваться, безопаснее писать с использованием нетипизированного throws.

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

4. Откладывать Swift Testing до конца. Первый @Test в начале миграции многому учит команду о новых макросах ещё до дедлайна.

5. Недооценивать мост с Objective-С. Бриджированные API Objective-C вызывают наибольшее количество предупреждений о Sendable. Учитывайте это при разработке любого приложения с заметным ядром на Objective-C.

KPI — что измерять после перехода на Swift 6

KPI качества. Сбои многопоточного класса на 10 тыс. сессий (цель — стремиться к нулю), предупреждения компиляции в CI (цель — ноль) и доля нестабильных юнит-тестов (ожидается снижение по мере замены неудобных async-паттернов XCTest на Swift Testing).

Бизнес-метрики. Время до внедрения исправления по многопоточному инциденту (до и после), время адаптации новых инженеров в кодовой базе (новички должны быстрее вникать, поскольку компилятор сам обучает их модели многопоточности) и стабильность графика релизов.

KPI надёжности. Заморозки главного потока (теперь вы явно владеете областями @MainActor), аналоги зависаний ANR и время холодного старта (обычно улучшается, иногда немного ухудшается, но в любом случае стоит отслеживать).

Когда мигрировать пока не стоит

Не каждому приложению нужно переходить на Swift 6 в этом квартале. Подождите, если команда сейчас в середине миграции на SwiftUI или async/await (миграции лучше делать по одной), если приложение всё ещё активно использует Objective-C-код, который вы пока не готовы перенести на мост, или если релизный график уже сжат из-за внешних факторов — например, запретов на публикацию в App Store или выхода крупной версии ОС.

Swift 6 точно выйдет в следующем квартале. А вот неудачный релиз, в котором миграция столкнулась с запуском продукта, будет иметь долгосрочные последствия.

FAQ

Можно ли использовать возможности Swift 6, не меняя режим языка?

Да. Большая часть возможностей Swift 6 (region-изолированные значения, отправка, типизированные ошибки, неизменяемые типы, Swift Testing) доступна уже в Swift 5.10 — по опциональным флагам. Многие команды включают их постепенно, за один-два релиза до перехода на -swift-version 6.

Сломает ли Swift 6 мою существующую кодовую базу?

Только если вы включите режим языка 6. Компиляторы Swift 6 по-прежнему собирают код на Swift 5 — более строгое поведение включается опционально, помодульно. Используйте это, чтобы мигрировать модуль за модулем.

Стоит ли сразу переходить с XCTest на Swift Testing?

Спешить не нужно. Swift Testing работает параллельно с XCTest. Новые тесты пишите на Swift Testing, а существующие тестовые сьюты переписывайте по мере необходимости — например, когда уже редактируете соответствующий файл. Принудительный массовый рефакторинг не принесёт пользы по сравнению с постепенным подходом.

Как Swift 6 взаимодействует с приложениями на SwiftUI?

SwiftUI помечен @MainActor и хорошо стыкуется со строгой многопоточностью. Заложите дополнительные работы, если у вас неизолированные синглтоны вью-моделей или вы передаёте не-Sendable замыкания в actions SwiftUI — компилятор теперь подсвечивает такие паттерны, которые раньше проскакивали.

Какое правило большого пальца по типизированным ошибкам?

Используйте типизированные ошибки на границах SDK и фреймворков, где набор ошибок стабилен, а вызывающим сторонам полезна полная обработка. Внутренний код оставляйте с нетипизированным throws, чтобы изменения в способах возникновения ошибок не требовали каскадных правок.

Можно ли использовать Swift 6 для бэкенда на Linux или Windows?

Да. Swift 6 со Swift-реализацией Foundation — реальный вариант для бэкенда на Linux и Windows. В связке с Vapor или Hummingbird он обеспечивает HTTP API. Команды, уже использующие Swift на клиенте, выигрывают от единого языка на всём стеке.

Как Swift 6 влияет на планы по Swift на Android?

Рабочая группа Swift on Android 2025 года использует тулчейн Swift 6. Общая бизнес-логика на Swift 6 со строгой многопоточностью — самый аккуратный старт для новых кроссплатформенных модулей. SwiftUI по-прежнему работает только на iOS; нативный интерфейс для каждой платформы остаётся рекомендуемым решением.

Во сколько обычно обходится миграция на Swift 6?

Небольшое приложение — как правило, 2–4 инженерные недели; среднее — 6–10; крупное — 12–20, с выпуском в несколько релизов. С Agent Engineering мы регулярно укладываемся на 20–40% быстрее этих ориентиров. Каждая оценка зависит от конкретной кодовой базы, поэтому приведённые цифры — ориентиры, а не обязательства.

Что почитать дальше

Готовы сделать Swift 6 безопасным для своего продакшен-приложения?

Swift 6 — серьёзный шаг вперёд: защита от гонок данных на этапе компиляции, лучшая эргономика тестов, noncopyable-ресурсы, типизированные ошибки на границах библиотек и кроссплатформенный Foundation, который наконец делает один язык реальным выбором сразу для iOS, Android, macOS, Linux и Windows. Миграция — это работа, но каждое продакшен-приложение, которое мы переносили, становилось заметно безопаснее и проще в понимании.

Размазывайте миграцию по релизам, используйте region-изолирование и sending, чтобы держать количество аннотаций Sendable минимальным, и внедряйте Swift Testing там, где уже пишете тесты. Если понадобятся инженеры с опытом таких изменений в продакшене — мы на связи.