Почему мы разрабатываем нативные iOS приложения на Swift вместо кроссплатформенных фреймворков

Искушение кроссплатформенности

Давайте будем честны: нам нравится Flutter. Мы используем его для многих клиентских проектов, где кроссплатформенный охват важнее, чем функции, специфичные для платформы. React Native тоже надежен. Но для наших собственных AI-powered iOS приложений — тех, которые работают с CoreML, используют камеру на 60fps и должны быть неотличимы от приложений Apple первой стороны — мы последовательно выбираем нативный Swift и SwiftUI.

Это не идеологическая позиция. Это практическое решение, основанное на выпуске реальных продуктов и измерении того, что имеет значение: производительность, удержание пользователей, рейтинги App Store и скорость разработки.

Разрыв в производительности CoreML реален

Когда ваше приложение запускает ML pipeline, выполняющий компьютерное зрение на 60fps, накладные расходы на трансляцию кроссплатформенных фреймворков становятся реальным узким местом. Интеграция CoreML в Swift имеет нулевые накладные расходы — модель выполняется на Neural Engine, результаты возвращаются как нативные типы Swift, и UI обновляется в одном и том же кадре.

Мы провели бенчмарк модели YOLOv8 для обнаружения объектов по трем подходам: нативный Swift с CoreML, Flutter с platform channel bridge к CoreML и React Native с нативным модулем. Результаты были поразительны:

Нативный Swift: среднее время вывода 12ms. Flutter bridge: 28ms (bridge добавляет ~16ms накладных расходов на сериализацию за кадр). React Native: 35ms. При вводе с камеры на 30fps, эти накладные расходы bridge съедают почти половину вашего бюджета кадра. При 60fps кроссплатформенность невозможна.

Для приложений, где AI вывод происходит изредка (фильтр фото, функция анализа текста), эти накладные расходы пренебрежимы. Но для AI в реальном времени — обработка видео в реальном времени, непрерывный анализ датчиков, потоковая транскрипция аудио — нативный Swift с CoreML — единственный вариант, обеспечивающий плавный опыт.

SwiftUI превратился в мощный инструмент повышения производительности

SwiftUI значительно улучшился с выходом iOS 17 и 18. Navigation stacks, observable macros и новые animation APIs соперничают с любым решением в кроссплатформенном мире. Скорость итерации с SwiftUI previews фактически выше, чем hot reload во многих случаях, потому что previews отображаются без перекомпиляции всего приложения.

Observable macro в Swift 5.9 исключил большую часть шаблонного кода, который делал управление состоянием в SwiftUI болезненным. В сочетании с новой системой навигации построение сложных многоэкранных потоков теперь простое и типобезопасное. Мы тратим меньше времени на борьбу с фреймворком и больше времени на разработку функций.

Для приложений, которые должны выглядеть нативными — правильные жесты iOS, haptics, Dynamic Island интеграция, Live Activities, виджеты — SwiftUI предоставляет все это бесплатно. Кроссплатформенные фреймворки либо не могут получить доступ к этим функциям, либо требуют сложной реализации platform channels, что сводит на нет экономию времени.

Преимущество App Store

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

Наши нативные приложения имеют среднюю оценку в App Store 4,7 звезд. Самые частые положительные отзывы упоминают скорость и то, как приложение выглядит как будто созданное для iOS. Это нативное ощущение практически невозможно воспроизвести с помощью кроссплатформенных фреймворков, особенно для анимаций, переходов и взаимодействия с жестами.

Когда кроссплатформенность — правильный выбор

Кроссплатформенность имеет смысл, когда: ваше приложение — это в основном интерфейс CRUD, поддерживаемый API, вам нужны iOS и Android с первого дня при ограниченном бюджете, все ваши функции искусственного интеллекта работают на серверной стороне, или вы создаете MVP для проверки концепции перед инвестициями в нативные приложения. Мы используем Flutter именно для таких сценариев в работе с клиентами.

Для всего остального — особенно для приложений с ML на устройстве, пользовательских конвейеров камеры, интеграции ARKit или глубокой интеграции ОС, такой как HealthKit или HomeKit — выбирайте нативные приложения. Первоначальные инвестиции окупаются за счет производительности, удовлетворенности пользователей и долгосрочной поддерживаемости.

Наша рекомендация

Если вы стартап, выбирающий между нативными и кроссплатформенными приложениями, задайте себе один вопрос: связано ли основное ценностное предложение вашего приложения с возможностью, специфичной для платформы? Если ответ «да» — а для большинства приложений на основе AI это так — выбирайте нативные приложения. Если ответ «нет», Flutter или React Native отлично вам подойдут и сэкономят время.

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