Сколько стоит мобильное приложение: нативное, кроссплатформенное и PWA

Разница в цене между тремя подходами достигает трёх раз. Выбор определяется одним вопросом: нужен ли приложению доступ к тому, что умеет только телефон?

Три подхода

Нативная разработка

Отдельное приложение под iOS на Swift и отдельное под Android на Kotlin. Фактически два проекта: две команды, два кода, два цикла тестирования.

Цена: от 2 500 000 ₽ за обе платформы. Срок: от 5 месяцев.

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

Кроссплатформенная разработка

Один код, работающий на обеих платформах — React Native или Flutter. Экономия достигает 40% относительно нативной пары, потому что общей остаётся большая часть кода.

Цена: от 1 400 000 ₽ за обе платформы. Срок: от 3 месяцев.

Подходит подавляющему большинству бизнес-приложений: каталог, заказы, личный кабинет, уведомления, оплата. Ограничения начинаются там, где нужна нестандартная работа с железом — но большинству приложений это не нужно.

PWA — сайт, который ставится как приложение

Веб-приложение, которое добавляется на домашний экран, работает офлайн и шлёт уведомления. Отдельного приложения не существует — это ваш сайт в другой упаковке.

Цена: от 400 000 ₽. Срок: от 1,5 месяцев.

Главное преимущество не в цене, а в том, что нет магазинов приложений: обновление выкатывается мгновенно, без модерации, а пользователю не нужно ничего скачивать. Главный минус — на iOS часть возможностей ограничена, и рассчитывать на push-уведомления там нельзя так же уверенно, как на Android.

Сравнение в одной таблице

Подход	Цена за обе платформы	Срок первой версии	Возможности устройства	Обновление у пользователя
Нативная	от 2 500 000 ₽	от 5 месяцев	полный доступ	через магазин, с модерацией
Кроссплатформенная	от 1 400 000 ₽	от 3 месяцев	почти полный, нестандартное — через доработку	через магазин, с модерацией
PWA	от 400 000 ₽	от 1,5 месяцев	ограниченный, на iOS сильнее	мгновенно, без модерации

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

Что не входит в цену разработки

Об этих статьях узнают в последний момент.

• Аккаунты разработчика. Apple — 99 $ в год, Google — 25 $ разово. Нужны, чтобы выложить приложение.
• Публикация и модерация. Первая подача редко проходит с первого раза; закладывайте одну-две итерации.
• Серверная часть. Приложение без бэкенда — витрина. Если данные приходят с сервера, сервер тоже нужно разработать.
• Поддержка. Раз в год выходят новые версии iOS и Android. Приложение, которое не обновляют, через два года перестаёт запускаться.
• Комиссия магазинов. С покупок и подписок внутри приложения Apple и Google удерживают свою долю. Если вы продаёте цифровой товар, учтите это в экономике заранее.

Аккаунты разработчика оформляйте на своё юридическое лицо, а не на подрядчика. Перенос приложения между аккаунтами возможен, но требует согласия обеих сторон, а его удобнее не выпрашивать.

Как решить, нужно ли приложение вообще

Приложение оправдано, когда человек возвращается регулярно. Доставка еды, банк, такси, программа лояльности, рабочий инструмент — да. Компания, к которой обращаются раз в год, — почти наверняка нет: установка приложения ради одной покупки не окупится ни для кого.

Проверьте себя вопросом: что мой пользователь будет делать в приложении такого, чего не может на сайте? Если ответ «то же самое, но удобнее» — сделайте удобнее на сайте. Это дешевле в разы.

Второй способ проверки — список. Приложение имеет смысл, если вы уверенно отвечаете «да» на несколько пунктов:

• пользователь возвращается регулярно, а не от случая к случаю;
• ему нужны уведомления, на которые он действительно реагирует: статус заказа, смена, запись;
• сценарий требует камеры, геолокации или работы без сети;
• у вас повторные покупки или подписка, а не разовая сделка;
• приложением пользуются ваши сотрудники, и установку можно сделать обязательной.

Как прикинуть окупаемость

Считать окупаемость по выручке бессмысленно: вернуть нужно не оборот, а то, что от него остаётся. Порядок рассуждения такой.

1. Возьмите цену подходящего вам варианта из таблицы выше — это сумма, которую предстоит отбить.
2. Оцените, сколько вы зарабатываете с одной дополнительной покупки — не получаете, а именно зарабатываете, за вычетом себестоимости.
3. Разделите первое на второе. Получится количество дополнительных покупок, ради которых всё затевается.
4. Прикиньте, откуда они возьмутся: сколько у вас постоянных клиентов, какая их часть поставит приложение и насколько чаще станет возвращаться.

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

Не считайте, что приложение поставят все. До установки доходит меньшая часть аудитории, и заранее вы не знаете какая. Именно поэтому дешёвый вариант разумно запускать первым: он измеряет эту долю за свои деньги, а не за деньги нативной разработки.

Не сравнивайте варианты по одной цене. PWA дешевле кроссплатформенного приложения не за то же самое: часть сценариев она отдаёт не полностью. Если ваш расчёт держится на уведомлениях — например, на сообщениях об акциях в программе лояльности, — помните, что на iOS рассчитывать на них нельзя так же уверенно, как на Android. Значит, в PWA этот сценарий работает не для всей аудитории, и закладывать в расчёт нужно только ту её часть, до которой он действительно дойдёт. Сравнивать по цене имеет смысл только те варианты, которые закрывают ваш сценарий целиком.

Разумный порядок действий

Начать с PWA. Она собирается за полтора месяца, показывает реальный спрос и не требует магазинов. Если аудитория пользуется и просит большего — переходить к кроссплатформенной версии, уже понимая, какие функции востребованы.

Идти сразу в нативную разработку разумно, только когда без возможностей устройства продукта просто нет.

Когда это правило не работает

Совет «начните с PWA» верен не всегда. Вот случаи, когда он вреден.

Присутствие в магазинах — само по себе требование. Тендер, партнёрская программа, условия сети, к которой вы подключаетесь. PWA такую задачу не решает по определению.

Аудитория преимущественно на iOS. Ограничения PWA там заметнее всего, и часть смысла промежуточного шага теряется. Долю платформ смотрите не по рынку вообще, а по статистике своего сайта.

Продукт — это устройство. Камера в реальном времени, датчики, фоновая геолокация. Здесь PWA не промежуточный шаг, а потерянные полтора месяца.

Платформа одна и она известна. Если приложением пользуются ваши сотрудники и у всех Android, нативная разработка под одну платформу может выйти дешевле кроссплатформенной под две. Считайте от реального парка устройств.

Чего делать не стоит

Заказывать приложение «как у конкурента». Вы видите его интерфейс, но не видите, окупился ли он. Возможно, конкурент тоже смотрел на кого-то.

Откладывать серверную часть на потом. Экраны собираются быстро и создают ощущение готовности. Сервер — половина работы, и обнаруживается она ровно тогда, когда бюджет уже потрачен на интерфейс.

Экономить на тестировании на реальных устройствах. Эмулятор не покажет, как приложение ведёт себя при слабом сигнале, на старом телефоне и при входящем звонке посреди оплаты.

Частые вопросы

Можно ли сделать приложение дешевле, чем в таблице?

Ниже нижней строки таблицы начинается уже не приложение, а что-то другое: прототип под одну задачу или оболочка вокруг сайта. Такое решение бывает уместно как способ проверить идею, но продавать его как «приложение под iOS и Android» нечестно. Если вам называют сумму заметно меньше, спрашивайте не про цену, а про состав: что именно вы получите, что оно будет уметь и чего не будет.

Сколько времени занимает публикация в магазинах?

Само рассмотрение занимает дни. Проблема не в нём, а в замечаниях: чаще всего просят исправить описание, политику конфиденциальности или объяснить, зачем приложению запрошенные разрешения. Планируйте одну-две итерации.

Что дешевле поддерживать — нативное или кроссплатформенное?

Кроссплатформенное: исправление делается один раз, а не дважды. Но у него своя статья расходов — обновления самого фреймворка, которые иногда требуют работы, не дающей пользователю ничего видимого.

Нужен ли отдельный дизайн под iOS и Android?

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

Можно ли выпустить сначала одну платформу?

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

Приложение уже есть, но его никто не открывает. Переделывать?

Сначала выяснить причину. Обычно дело не в приложении, а в том, что у человека нет повода вернуться. Новая версия того же самого стоит денег и ничего не меняет.