Разработка на React Native

React Native — наш основной стек: на нём мы собираем приложения для iOS, Android и даже macOS из одной кодовой базы. Это значит, что бизнес-логику, экраны и сетевой слой пишем один раз, а не дважды под каждую платформу — отсюда короче сроки, ниже бюджет и меньше расхождений в поведении между iPhone и Android.

При этом RN — не «обёртка над сайтом»: интерфейс рендерится нативными контролами платформы, а тяжёлые или специфичные вещи (камера, биометрия, карты, фоновые задачи) мы подключаем через нативные модули. Получается продукт, который для пользователя неотличим от чисто нативного, но обходится команде дешевле в разработке и поддержке.

Когда React Native подходит, а когда нет

RN — сильный выбор для продуктов, где нужны обе платформы сразу, важна скорость вывода на рынок и большая часть функциональности — это экраны, формы, списки, работа с API: маркетплейсы, сервисы заказа, кабинеты, мессенджеры, travel и delivery. В таких задачах общая кодовая база экономит до половины усилий без потери качества для пользователя.

Честно говорим и об обратном: если ядро продукта — тяжёлая графика, сложный realtime-звук/видео, AR или игровая физика, либо нужен только iOS с глубокой завязкой на свежие нативные API, — чистый Swift/Kotlin может оказаться уместнее. На Discovery мы как раз и определяем, где RN даёт выигрыш, а где честнее уйти в нативную часть. Решение — под вашу задачу, а не под наш любимый стек.

Одна кодовая база — iOS, Android, macOS

Пишем на TypeScript: общая бизнес-логика, навигация, состояние, работа с бэкендом (Node.js) — единый код на все платформы. Платформенные различия (отступы под вырезы экрана, разрешения, поведение клавиатуры, специфика сторов) аккуратно разводим там, где это действительно нужно, а не дублируем приложение целиком.

Из того же кода умеем собирать и десктоп под macOS через React Native macOS — этот навык у нас реально в проде (приложение Postmypost для соцсетей). Так один продукт живёт на телефоне и на маке, оставаясь единой кодовой базой, а не тремя разными приложениями с расходящимся поведением.

OTA-обновления и нативные модули

Часть обновлений (правки в JS-логике и интерфейсе) выкатываем по воздуху через OTA (CodePush) — без релиза в App Store и Google Play и без ожидания ревью. Это ускоряет хотфиксы и эксперименты: исправление доезжает до пользователей за часы, а не за дни. Изменения, которые затрагивают нативную часть, по-прежнему идут штатным релизом через сторы — мы заранее проговариваем, что можно отдавать через OTA, а что нет.

Когда стандартных возможностей RN не хватает, подключаем нативные модули на Swift/Kotlin или готовые библиотеки: платежи, биометрия, карты и гео, пуши, камера, работа в фоне. Граница между JS- и нативным слоем спроектирована так, чтобы её можно было развивать, а не переписывать.

Что входит и сколько занимает

В разработку на React Native входит: проектирование архитектуры приложения, настройка проекта и CI/CD, экраны и навигация, интеграция с бэкендом, нативные модули под нужные функции, сборка и публикация в App Store и Google Play, настройка OTA-обновлений. После релиза остаёмся на поддержке — обновляем зависимости и версии RN, чиним и развиваем продукт.

Ориентир по срокам: MVP на RN под обе платформы — от 1 месяца до первого релиза; полноценный продукт со сложной логикой и интеграциями — дольше, точные сроки и бюджет называем после Discovery. Грубую вилку можно прикинуть в нашем калькуляторе на главной.

Вопросы и ответы

Приложение на React Native будет тормозить по сравнению с нативным?
Для подавляющего большинства бизнес-приложений — нет: интерфейс рендерится нативными контролами, а узкие места (анимации, тяжёлые списки, специфичные функции) выносятся в нативные модули. Заметная разница возникает только в тяжёлой графике, играх и сложном realtime-видео — такие случаи мы оговариваем заранее и при необходимости предлагаем нативную реализацию части продукта.
Насколько React Native дешевле и быстрее, чем отдельные iOS и Android?
За счёт общей кодовой базы значительная часть работы делается один раз вместо двух, поэтому RN обычно ощутимо экономит и сроки, и бюджет относительно двух отдельных нативных команд. Конкретная экономия зависит от доли платформенно-специфичной логики в вашем проекте — оценим её на Discovery и покажем вилку под вашу задачу.
Можно ли выпускать обновления без публикации в App Store и Google Play?
Да, частично. Правки в JS-логике и интерфейсе мы выкатываем по воздуху через OTA-обновления (CodePush) — без ожидания ревью сторов. Изменения, затрагивающие нативную часть приложения, по-прежнему публикуются штатным релизом. Мы заранее договариваемся, что можно отдавать через OTA, а что требует обновления в магазинах.

Расскажите о продукте — и составим маршрут до релиза

Созвон на 30 минут: разбираем задачу, риски и формат сотрудничества. Без обязательств.