React Native или нативная разработка на Swift и Kotlin: честный разбор с кейсами

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

Правы бывают и те, и другие. Зависит от задачи.

За несколько лет мы сделали достаточно проектов на обоих стеках, чтобы перестать отвечать шаблонно. Расскажем как есть.

В «Регро Вахта» мобильную часть сделали на React Native, а веб — на Next.js: одна команда, общий бэкенд на Django и ежемесячные релизы новых функций.

Прежде чем выбирать между React Native и нативной разработкой на Swift и Kotlin, стоит понять: сравнение образца 2019 года уже не работает.

React Native прошёл через серьёзную техническую перестройку. Старая архитектура с асинхронным «мостом» (bridge), через который JavaScript общался с нативным кодом через сериализацию JSON, — осталась в прошлом. Начиная с версии 0.76 новая архитектура включена по умолчанию. В её основе — JSI (JavaScript Interface): прямые вызовы из JavaScript в нативный код без накладных расходов на сериализацию. Вместе с этим пришли TurboModules с ленивой загрузкой модулей и Fabric — новый рендерер.

Результат на практике: движок Hermes даёт примерно на 30% быстрее старт приложения и заметно меньше потребление памяти по сравнению с предыдущими версиями фреймворка.

На нативной стороне тоже произошли изменения. SwiftUI сейчас используется в большинстве новых iOS-проектов — разработка на Swift стала заметно быстрее, чем три года назад. Android-разработка на Kotlin с Jetpack Compose тоже упростилась. Нативная разработка под iOS и Android перестала быть настолько неподъёмной по срокам, как было раньше.

Итог: выбор между кроссплатформенной разработкой на React Native и нативными приложениями на Swift и Kotlin — это не выбор между «быстро и дёшево» versus «качественно и надёжно». Это выбор между разными архитектурными подходами с разными компромиссами под разные задачи.

Нужно запустить продукт на iOS и Android без двух отдельных команд. Это главный аргумент в пользу кроссплатформенной разработки. Одна кодовая база — один iOS-разработчик или один Android-разработчик не нужен отдельно. По нашему опыту, на проектах среднего масштаба React Native экономит от 30 до 50% бюджета на разработку по сравнению со схемой «два нативных приложения — две команды».

Команда уже работает на TypeScript или JavaScript. Если у вас есть фронтенд-разработчики — порог входа в React Native значительно ниже, чем учить Swift с нуля. Это ускоряет найм и снижает стоимость.

Нужны частые обновления без ревью в App Store. CodePush позволяет доставлять обновления JavaScript-слоя напрямую на устройства пользователей, минуя процедуру апрува. Для продуктов с еженедельными итерациями — это конкретное преимущество, а не маркетинговый тезис.

Задача — стандартная для мобильного приложения. Маркетплейс, сервис доставки, B2B-приложение для полевых сотрудников, корпоративный инструмент, HR-продукт, e-commerce, агрегатор — для всего этого React Native работает без компромиссов. Instagram, Tesla, Shopify используют его, располагая ресурсами на нативную разработку. Это рациональный выбор, не вынужденный.

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

Финтех, банкинг, медицина — всё, где критична безопасность. Swift даёт прямой доступ к Secure Enclave на iOS — специализированному чипу для хранения биометрии и ключей шифрования. В React Native это решается через кастомный native module, что добавляет уровень сложности и потенциальный риск. Крупный российский банк, переведя платёжно-биометрические модули на нативную разработку для iOS и Android, получил прирост скорости биометрической верификации на 34% и снижение баг-репортов на 62% по сравнению с предыдущим кроссплатформенным решением.

Real-time с требованием к миллисекундам. Трейдинг, мониторинг оборудования, медицинские приборы — там, где задержка в десятки миллисекунд имеет значение, JavaScript-рантайм добавляет накладные расходы, которые незаметны в обычном приложении, но ощутимы в потоковой обработке данных.

Глубокая интеграция с платформой. HealthKit, CarPlay, Wear OS, Bluetooth LE, NFC, виджеты и расширения операционной системы, Siri, Google Assistant — всё это доступно в нативной разработке на Swift и Kotlin в день официального релиза Apple или Google. В React Native это появляется позже через community-библиотеки с переменным качеством.

AR/VR и тяжёлая графика. ARKit для iOS и ARCore для Android раскрываются полностью только в нативном стеке. Это не архитектурное ограничение React Native — просто экосистема кроссплатформенной разработки не успевает за обновлениями платформ в этой части.

Мобильное приложение — ключевой продукт компании. Если приложение не вспомогательный инструмент, а сама суть бизнеса, нативная разработка даёт полный контроль над кодовой базой, предсказуемость при обновлениях операционных систем и отсутствие зависимости от фреймворка третьей стороны. Долгосрочное обслуживание такого приложения обычно проще и предсказуемее.

«React Native медленно работает». Для подавляющего большинства бизнес-приложений — контент, e-commerce, социальные платформы, корпоративные инструменты — разницу в производительности между React Native и нативными iOS/Android-приложениями пользователь не почувствует. Разрыв остаётся только в специфических сценариях: игры с высоким FPS, сложная 3D-графика, real-time анимации со строгими требованиями.

«Нативная разработка iOS и Android — это всегда долго». Долго и дороже, да. Но если требования к безопасности или интеграции с платформой делают React Native неподходящим вариантом, «быстрый» выбор обернётся дорогостоящим рефакторингом через год. Мы видели это несколько раз.

«Нужно выбрать что-то одно». На практике грамотный подход часто выглядит иначе: основная бизнес-логика и интерфейс — на React Native, требовательные модули (платёжный, биометрический, работа с конкретным железом) — нативные, написанные на Swift и Kotlin и подключённые через чистый интерфейс. Так устроены многие production-приложения с серьёзными техническими требованиями. Это не компромисс — это архитектурно правильное решение.

На первом звонке мы задаём клиенту пять вопросов. Ответы дают 80% решения:

• Будет ли приложение работать с платёжными данными, биометрией или медицинской информацией? Если да — рассматриваем нативную разработку или нативные модули для критичных частей.
• Нужна ли глубокая интеграция со специфическими API платформы: HealthKit, NFC, Bluetooth LE, AR? Если да — нативка или гибридный подход.
• Есть ли уже команда с опытом JavaScript или TypeScript? Если да — React Native снизит стоимость и ускорит разработку мобильного приложения.
• Приложение — ядро бизнеса или вспомогательный инструмент? Если ядро с расчётом на миллионы пользователей — нативная разработка под iOS и Android заслуживает серьёзного рассмотрения.
• Нужны частые обновления без апрува App Store? Если да — React Native с OTA-обновлениями через CodePush.

Выбор технологии для разработки мобильного приложения — это не вопрос «что лучше». Это вопрос «что подходит под вашу конкретную задачу». Именно с этого вопроса начинается любой наш проект.

Если хотите разобраться, что подойдёт в вашем случае — напишите нам. Расскажем честно.