Мы в основном пишем на нативном Swift, так что можно ожидать однобокого ответа. Его не будет. Flutter и React Native зрелые технологии, и для некоторых продуктов они — лучший выбор. Вот как мы об этом думаем.
Ответ в одном абзаце
Если ваш продукт в первую очередь для iOS, опирается на возможности платформы вроде виджетов, Live Activities, Siri и Быстрых команд или просто должен идеально ощущаться на iPhone, выбирайте нативный Swift и SwiftUI. Если вам нужны iOS и Android с первого дня, интерфейс в основном стандартный и вы хотите одну общую команду, выбирайте Flutter или React Native. Если ваша команда уже пишет на React для веба, React Native покажется родным.
Как они устроены
- Swift и SwiftUI — собственные язык и UI-фреймворк Apple. Вы используете настоящие системные компоненты, поэтому приложение ведёт себя ровно как iOS.
- Flutter использует язык Dart и сам рисует каждый пиксель своим движком рендеринга. Он выглядит одинаково на всех платформах.
- React Native использует JavaScript или TypeScript и отрисовывает настоящие нативные компоненты через New Architecture, которая включена по умолчанию в актуальных версиях.
Производительность
Все три достигают 60 или 120 кадров в секунду в обычных приложениях. Различия проявляются на краях: тяжёлые анимации, большие списки, игры, обработка камеры и звука. В нативном Swift нет моста и дополнительной среды выполнения, поэтому такие случаи проще сделать правильно.
Доступ к функциям iOS
Здесь натив вырывается вперёд. Виджеты для экрана «Домой» и экрана блокировки (WidgetKit), Live Activities, App Intents, представления StoreKit 2 и многие новые API каждой WWDC появляются сначала для Swift. Кроссплатформенные приложения могут их использовать, но обычно эту часть всё равно пишут на Swift, плюс связующий код.
Внешний вид и ощущения
Приложения на SwiftUI автоматически получают изменения дизайна iOS, например материалы Liquid Glass в iOS 26. Flutter воссоздаёт внешний вид каждой платформы, поэтому может отставать от нового дизайна. React Native находится посередине, так как использует нативные компоненты.
Стоимость и команда
- Одна кроссплатформенная кодовая база может быть дешевле, если обе платформы действительно нужны на старте.
- Одно нативное iOS-приложение обычно дешевле кроссплатформенного плюс нативной работы, которая рано или поздно ему понадобится.
- Найм: JavaScript-разработчиков найти проще всего, затем Swift-разработчиков, Dart-разработчиков меньше всего.
Наш разбор стоимости iOS-приложений показывает, как выбор платформы влияет на бюджет.
Когда что мы рекомендуем
Выбирайте нативный Swift, если
- Ваша основная аудитория — пользователи iPhone
- Вам нужны виджеты, Live Activities, Siri, Apple Watch или серьёзная работа с камерой и звуком
- Сам опыт и есть продукт: премиальные приложения, игры, творческие инструменты
Выбирайте Flutter, если
- Вам нужны iOS и Android на старте с одной командой
- Ваш интерфейс уникальный и брендовый, а не стандартный для платформы
Выбирайте React Native, если
- Ваша команда уже работает с React и TypeScript
- Вы хотите делить логику с веб-приложением
Наш выбор по умолчанию и почему
Свои продукты, такие как Scevia и Paw & Home, мы делаем нативно, потому что они опираются на функции iOS и анимацию. В клиентских проектах мы рекомендуем натив для продуктов «сначала iOS» и с радостью планируем этап Android, когда идея подтверждена.
Частые вопросы
Flutter быстрее нативной iOS?
Нет. Хорошо сделанное нативное приложение как минимум так же быстро. Flutter достаточно быстр для большинства приложений, но в тяжёлой графике, звуке и больших списках преимущество у натива.
Можно начать нативно и добавить Android позже?
Да, это частый путь. Бэкенд и дизайн переносятся, а Android-приложение может быть нативным на Kotlin или кроссплатформенным.
Предпочитает ли Apple нативные приложения в App Store?
Apple не ранжирует приложения по технологии, но отклоняет тонкие веб-обёртки без нативной ценности. Использование возможностей платформы также повышает шансы попасть в редакционные подборки.
Готов ли SwiftUI для продакшена?
Да. SwiftUI — основной UI-фреймворк Apple, и каждое выпущенное нами приложение сделано на нём; UIKit мы используем только там, где этого требует конкретная функция.