Когда бизнесу нужно приложение для iOS и Android, первый вопрос обычно технический: делать два отдельных клиента или использовать общую кодовую базу.
В ВебШаг для таких проектов используем React Native. Значительная часть приложения разрабатывается один раз, а затем работает на обеих платформах. При этом сборки, тестирование и часть платформенных функций всё равно остаются отдельными для iOS и Android.
Такой подход подходит многим бизнес-приложениям, но не всем.
Подробнее о разработке — на странице мобильных приложений. Логику заказа и смены статусов можно посмотреть в демо приложения, а ориентиры бюджета отдельно разобраны в статье сколько стоит мобильное приложение.
React Native имеет смысл не потому, что «один код всегда дешевле». Он подходит, когда основная логика и пользовательские сценарии на iOS и Android совпадают и нет требований, ради которых нужно отдельно разрабатывать каждую платформу.
1Кому React Native обычно подходит
Хороший сценарий для React Native — приложение, в котором пользователи делают примерно одно и то же независимо от телефона.
Например:
- смотрят каталог;
- собирают корзину;
- оформляют заказ;
- проверяют его статус;
- работают в личном кабинете;
- получают уведомления;
- заполняют формы;
- просматривают списки и документы.
Это может быть клиентское приложение магазина, сервис для партнёров или внутренний мобильный инструмент сотрудников.
React Native также логичен, если у бизнеса уже есть сайт или серверная система с API. В таком случае мобильное приложение становится ещё одним интерфейсом к тем же данным: сайт → API ← мобильное приложение. Не приходится заново создавать всю бизнес-логику только потому, что появился мобильный клиент.
Главное условие — задачи на двух платформах должны быть в основном одинаковыми. Если на iPhone и Android нужен один каталог, один кабинет и одна схема заказа, общая кодовая база выглядит разумно.
2Когда лучше выбрать другой путь
React Native умеет гораздо больше, чем простые формы и списки. Но вопрос обычно не в том, можно ли технически реализовать функцию, а в том, насколько такой подход подходит конкретному продукту.
Отдельную нативную разработку стоит рассмотреть, если в центре приложения:
- тяжёлая графика, 3D или игровой сценарий;
- сложная работа с устройством в фоне;
- специфичные возможности только iOS или только Android;
- редкие платформенные API, для которых всё равно потребуется много отдельного нативного кода;
- уже существуют два развитых нативных приложения и нет практической причины их переписывать.
Общая кодовая база не отменяет особенностей платформ. Push-уведомления, разрешения, платежи, фоновая работа и поведение интерфейса всё равно нужно проверять отдельно на iOS и Android.
Есть и противоположная ситуация: полноценное приложение пока вообще не требуется. Если клиент уже находится в Telegram или MAX и ему нужен один короткий сценарий — например, записаться, оформить простой заказ или посмотреть статус, — можно начать с мини-приложения в Telegram или MAX.
3Мини-приложение, React Native или два нативных приложения
Запрос может звучать одинаково — «нужно мобильное приложение», — но за ним скрываются разные продукты.
| Формат | Когда подходит | Ориентир ВебШаг |
|---|---|---|
| Мини-приложение в Telegram или MAX | Пользователь уже в мессенджере, нужен один короткий сценарий | от 150 000 ₽ |
| React Native | Нужен самостоятельный клиент для iOS и Android с похожими сценариями | от 500 000 ₽ |
| Отдельные приложения под iOS и Android | Платформы требуют существенно разной реализации | отдельная оценка |
Мини-приложение открывается внутри Telegram или MAX. Его можно использовать для компактного сценария: записи, заказа, просмотра статуса. Отдельная установка из стора не нужна. Это не упрощённый React Native, а другой способ дать клиенту интерфейс.
React Native — самостоятельное приложение для iOS и Android. Его можно публиковать в App Store, Google Play и при необходимости RuStore, использовать вне мессенджера и развивать как отдельный мобильный продукт. Основная часть кода при этом общая для двух платформ.
Два нативных приложения — отдельно версии под iOS и Android. Такой подход имеет смысл, когда особенности продукта требуют глубокой работы с каждой платформой или уже существуют две независимые кодовые базы.
Не нужно выбирать нативную разработку только потому, что она считается «более правильной», и не стоит выбирать React Native только ради самого факта общей кодовой базы. Решение должно следовать из требований продукта.
4Что входит в нормальный объём работ
Мобильное приложение — это не только набор экранов. Для первой версии обычно нужно пройти несколько этапов.
Сценарии и прототип. Сначала определяем, что пользователь должен сделать. Например: открыть каталог → выбрать товар → оформить заказ → получить уведомление о статусе. После этого проектируются ключевые экраны.
Интерфейс. Приложение адаптируется под визуальный стиль компании и требования мобильного экрана. Не все элементы сайта имеет смысл просто переносить один в один.
API и авторизация. Приложению нужно откуда-то получать товары, заказы, профиль и другие данные. Если готового API нет, это тоже влияет на объём проекта.
Уведомления и платформенные функции. Push-уведомления, платежи, разрешения устройства настраиваются с учётом особенностей iOS и Android.
Сборки и подготовка к публикации. Для магазинов нужны отдельные сборки, иконки, скриншоты, описания, политики и доступы.
Ориентир ВебШаг для первой версии приложения на React Native — от 500 000 ₽. Срок часто начинается примерно от 75 рабочих дней.
React Native для iOS и Android — от 500 000 ₽. Срок первой версии часто от ~75 рабочих дней. Точная смета определяется после брифа.
Итог зависит от ролей, интеграций, платежей, офлайн-режима и других требований.
5Сроки и риски, которые часто недооценивают
Общая кодовая база сокращает дублирование разработки, но не превращает две платформы в одну.
Приложение нужно проверять на обеих платформах. То, что функция работает на Android, ещё не означает, что она будет вести себя так же на iOS. Особенно это касается уведомлений, платежей, разрешений, фоновых процессов, клавиатуры и системных элементов интерфейса.
Для публикации нужны доступы. Аккаунты разработчиков и сертификаты лучше готовить не в последний день проекта. Иначе готовая сборка может ждать организационных вопросов.
Модерация магазинов занимает отдельное время. App Store и Google Play проверяют приложения перед публикацией. Срок разработки первой версии и фактическая дата в магазине — не всегда одно и то же.
Контент тоже влияет на запуск. Тексты, изображения, юридическая информация и данные для карточек должны быть готовы к публикации. Если материалы задерживаются, разработка может быть закончена, а запуск — нет.
Если приложение планируется развивать после релиза, стоит заранее продумать и дальнейшее сопровождение, а не только первую публикацию.
6Как выбрать формат до оценки
Чтобы определить направление, не нужно заранее писать подробное техническое задание. Для начала достаточно ответить на несколько вопросов.
Что пользователь должен делать? Опишите основной сценарий. Например: войти → выбрать услугу → оформить заказ → смотреть статус.
Нужны ли App Store и Google Play? Если самостоятельное приложение в сторах обязательно — выбор сужается. Если нет, стоит проверить, не достаточно ли мини-приложения.
Одинаковы ли задачи на iOS и Android? Если да, React Native становится естественным кандидатом. Если платформам нужна существенно разная логика, стоит отдельно оценить нативную разработку.
Какие системы уже есть? Сайт, CRM, 1С, личный кабинет, API? Наличие готовой серверной части заметно влияет на объём проекта.
Есть ли сложные платформенные функции? Офлайн, фоновая работа, тяжёлая графика, работа с устройством? Именно такие требования часто определяют выбор технологии сильнее, чем количество экранов.
После этого уже можно предметно обсуждать формат и бюджет.
Посмотреть направление можно на странице мобильных приложений, попробовать демо приложения, а для оценки конкретной задачи — заполнить бриф или перейти в контакты.