Что мы на нём делаем
Swift — место, где наши Flutter-приложения по-настоящему встречаются с iOS. Кроссплатформенный слой владеет большей частью продукта, но не тем, что живёт в операционной системе: фоновое выполнение, notification service extensions, keychain и биометрия, NFC, вендорские SDK, поставляемые нативными фреймворками, и всё, что должно появляться за пределами самого приложения.
Это пишется на Swift за platform channel, так что со стороны Dart виден чистый API и ни одной детали жизненного цикла iOS. Это точный аналог того, что делает Kotlin на Android, — и платформенная интеграция обычно означает написать обе половины.
Где он нужен
Внутри наших Flutter-проектов, а не рядом с ними, поэтому отдельной строкой в портфолио не появляется. Он возникает там, куда кроссплатформенный код не дотягивается, — например в App Clip-половине работы с отложенными диплинками, о которой мы писали: переносимой реализации у неё нет.
Виджеты на домашнем экране, share-расширения и поверхности на SwiftUI — второй частый случай: это отдельные таргеты, в которых движок Flutter не работает.
Когда мы его рекомендуем
Для iOS-половины платформенной интеграции и для полностью нативного iOS-приложения, когда продукт действительно привязан к платформе: глубокая интеграция с ОС, аудитория только у Apple или команда, уже вложившаяся туда.
Не по умолчанию для продукта, которому нужен ещё и Android. Две нативные кодовые базы — это две команды, два релизных цикла и два набора багов; если ничего к этому не вынуждает, Flutter со слоем Swift под ним даёт те же возможности заметно дешевле.
