Разработка мобильных приложений: этапы, сроки и стоимость

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

Материал для владельца бизнеса или маркетолога, которому предстоит решить, нужно ли приложение, какой подход выбрать, сколько заложить денег и недель и как пройти RuStore, App Store и Google Play из России. Дальше — подходы, этапы, команда, расчёт бюджета, правила магазинов на октябрь 2026 года, ошибки и чек-лист.

Приложение или сайт: пять ситуаций, когда приложение окупается

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

1. Повторные покупки и визиты. Заказ кофе, запись на стрижку, ежедневная тренировка: пользователь запускает сценарий раз в неделю и чаще, и иконка на экране сокращает путь до одного касания.
2. Возможности телефона. Сканер штрихкодов, геолокация курьера, Bluetooth, NFC, работа без интернета. Браузер отдаёт сайту лишь часть этого, и на iPhone ограничений больше.
3. Push-уведомления как канал возврата. «Заказ в пути» доходит до экрана блокировки и не зависит от почтовых фильтров и алгоритмов соцсетей.
4. Закрытая аудитория с личным кабинетом. Клубная программа, подписка, кабинет владельца автомобиля.
5. Рабочий инструмент сотрудников. Курьеры, торговые представители, монтажники: приложение заменяет бумажные листы и звонки диспетчеру.

Не подходит ни один пункт — начните с сайта: клиент, который покупает раз в полгода, не поставит приложение ради одного заказа. Промежуточный вариант — PWA, сайт на экране телефона без публикации в магазинах. Когда нужны глубокий доступ к «железу», надёжные уведомления и карточка в магазине, он приложение не заменит.

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

Допустим, у сети из 8 кофеен выручка 60 млн ₽ в год, маржа 40%. Приложение с картой лояльности стоит 2,2 млн ₽, поддержка — 400 000 ₽ в год. Если оно добавляет 5% выручки, это 3 млн ₽ и 1,2 млн ₽ маржи; после поддержки остаётся 800 000 ₽ в год, и затраты возвращаются за 2,75 года. При приросте 10% остаётся 2 млн ₽ в год, и проект окупается примерно за 13 месяцев. Прирост лучше проверять на первой версии с минимальным набором функций.

Нативная, кроссплатформенная или веб: сравнение подходов для бизнеса

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

Проценты — наш ориентир для сравнения, а не прайс: реальная разница зависит от набора функций.

Нативная разработка: когда платформа важнее бюджета

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

Кроссплатформа: один код, две платформы

Для типового бизнес-приложения — каталог, корзина, оплата, кабинет, push — Flutter или React Native хватает, а экономия заметна: одна команда, один набор тестов, правки выходят на обе системы одновременно. Цена — зависимость от фреймворка и редкие функции, которые приходится дописывать нативно. Заранее спросите у подрядчика про нужные SDK (платёжные, карт, аналитики): обёртки под кроссплатформу есть у российских сервисов не всегда.

Веб-приложение и конструкторы

Если нужны каталог, формы и кабинет, а клиенты и так приходят с сайта, веб-версия закрывает задачу за треть бюджета. Конструктор подходит для теста идеи или внутренней записи на смены, но не как фундамент продукта. Простую обёртку сайта RuStore и App Store не принимают (подробнее — в разделах о публикации).

Два вопроса, которые решают выбор

• Нужен ли доступ к «железу»? Да — нативный или кроссплатформенный подход, не веб.
• Где ваша аудитория? Откройте отчёт Яндекс Метрики по платформам устройств. Допустим, 85% заходов — Android: начните с одной платформы.

Кто работает над приложением: состав команды и зоны ответственности

Приложение собирает команда, а не «программист». У фрилансера-одиночки роли не исчезают: их закрывает один человек, и страдают тестирование и сервер.

На среднем проекте это 5–8 человек, но не все на полной ставке. Сервер связан с приложением через API, и от того, как договорились две команды, зависит скорость всей разработки.

Ваша роль: владелец продукта

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

Девять этапов от идеи до релиза: что вы получаете на каждом

У каждого этапа есть результат, который можно проверить глазами: документ, схема, макет, сборка. Если «идёт разработка», а вы второй месяц не видите ни одного из этих артефактов, спросите, что именно делается.

Этап 1. Аналитика: цели, аудитория, сценарии

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

Этап 2. Техническое задание и оценка

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

Этап 3. Прототип

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

Этап 4. UI-дизайн и дизайн-система

Интерфейс рисуют с учётом гайдлайнов Apple и Google, собирают библиотеку компонентов, готовят иконку и скриншоты для магазинов. Результат: макеты в Figma и графические ассеты.

Этап 5. Разработка спринтами

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

Этап 6. Тестирование

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

Этап 7. Подготовка к публикации

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

Этап 8. Релиз и наблюдение

Google Play открывает версию на заданный процент пользователей, App Store раскатывает обновление фазами за семь дней (от 1% до 100%). Допустим, вы стартуете с 10% аудитории, следите за сбоями и при чистой статистике открываете всем. Результат: приложение доступно, настроены мониторинг и аналитика.

Этап 9. Развитие

Релиз — старт, а не финиш: отзывы, аналитика, обновления раз в 2–4 недели. Результат: план развития на квартал.

Сколько времени занимает проект: календарь для приложения средней сложности

Для среднего приложения — кабинет, оплата, push, админ-панель, одна-две интеграции — это пять–восемь месяцев до публикации. Простое укладывается в два–три месяца, сложное растягивается на восемь–четырнадцать.

Что растягивает сроки

• Медленные согласования. Допустим, каждое согласование макета занимает три рабочих дня вместо одного. При десяти согласованиях это лишние четыре недели.
• Чужие системы. Учётная система без документации или банк, который выдаёт доступ три недели, в плане выглядят одной строкой.
• Правки после дизайна. «Добавим ещё раздел» после вёрстки означает переделку кода, а не рисунка. Для первой публикации заложите запас в одну–две недели на случай отклонённой сборки.

Из чего складывается цена приложения: восемь факторов

Вопрос «сколько стоит приложение» упирается в то, что честного ответа без ТЗ нет: разброс от сотен тысяч до десятков миллионов рублей объясняется набором факторов, а не наценкой. Логика сметы похожа на расчёт стоимости сайта, но приложение дороже за счёт двух платформ, сервера и тестирования на устройствах.

1. Платформы: одна дешевле двух, кроссплатформа дешевле двух нативных.
2. Экраны и логика: каталог из пяти экранов и кабинет с ролями и чатом — разные порядки трудозатрат.
3. Сервер и админ-панель: в примере ниже это около пятой части часов проекта.
4. Интеграции: учётная система, CRM, платежи, онлайн-касса, карты. Каждая — работа и риск.
5. Дизайн: типовые компоненты дешевле собственной анимации.
6. Тестирование: чем больше устройств и сценариев, тем больше часов QA.
7. Безопасность и данные: персональные данные и оплата добавляют работы в архитектуре.
8. Модель договора: фиксированная цена за ТЗ защищает бюджет, оплата по часам гибче и требует контроля.

Ориентиры по классам приложений

Вилки ниже — наш ориентир для первичной оценки, а не прайс BigPanda и не статистика рынка: точную цену даёт смета по ТЗ. Ставка часа у студий сильно различается, в расчётах ниже мы берём условные 3 000 ₽.

Если проект упирается в верх вилки, ищите, что убрать из первой версии: сокращение объёма экономит больше скидки на час.

Считаем на примере: приложение магазина за 4,4 млн ₽ и его урезанная версия

Допустим, интернет-магазину нужно приложение с каталогом, корзиной, оплатой, кабинетом, push и выгрузкой заказов в учётную систему. Берём Flutter и ставку 3 000 ₽ за час.

В MVP убраны история заказов, интеграция с учётной системой (заказы приходят менеджеру в админ-панель и на почту) и программа лояльности. Товар можно найти, заказать и оплатить; остальное добавится, когда статистика покажет нехватку.

Расходы вне разработки

• Магазины: Apple Developer Program — 99 долларов США в год, Google Play — 25 долларов США один раз, публикация в RuStore бесплатна.
• Сервер и сервисы: хостинг, push-провайдер, аналитика, комиссия платёжного сервиса.
• Продвижение: приложение само не появится в телефонах клиентов, нужны баннеры, QR-коды и реклама.
• Поддержка: 15–25% стоимости разработки в год (подробнее — в разделе о сопровождении).

Три магазина рядом: RuStore, App Store и Google Play в одной таблице

Публикация — отдельная работа со своими сроками. Её начинают за месяц до релиза: аккаунту организации в App Store нужны D-U-N-S и проверка данных Apple, а новый личный аккаунт Google Play требует двухнедельного теста. Условия на октябрь 2026 года:

Если iOS-аккаунт пока недоступен из-за оплаты, запуск откладывать не нужно: Android-версия в RuStore и Google Play стартует независимо.

Публикация в RuStore: регистрация, файл и модерация

Самый короткий путь для российской компании: регистрация и публикация бесплатны, вход в RuStore Консоль — через VK ID.

Физическое лицо подтверждает данные и сразу получает доступ к консоли. ИП и юрлица подписывают регистрационную форму усиленной квалифицированной электронной подписью, после чего доступ открывают в течение 2–4 рабочих дней (по справке RuStore). Оформляйте аккаунт сразу на компанию: новые приложения добавляет только роль «Владелец компании». Документы для выплат запросят позже, при подключении монетизации.

Что готовить к загрузке

• Файл: APK или AAB до 5 ГБ с цифровой подписью. В обновлениях подпись и имя пакета совпадают с прошлой версией, номер версии выше. Загруженный файл хранится 14 дней: не отправите на модерацию — удалится.
• Карточка: название до 30 символов, краткое описание до 80, полное до 4 000, контакт разработчика (почта, группа VK, сайт или MAX).
• Графика: иконка 512×512 пикселей, не меньше трёх скриншотов для телефона.
• Декларации: рекламные SDK и платёжные решения, а также чувствительные разрешения Android.

За что отклоняют

Проверка занимает до 72 часов. Поводы для отказа из правил магазина:

• сайт, упакованный в приложение: WebView допускается только с дополнительной функциональностью — push, офлайн-режим, доступ к возможностям устройства;
• нет политики конфиденциальности на русском языке, хотя приложение собирает персональные данные;
• аккаунт нельзя удалить из самого приложения;
• проверка установки через Google Play Integrity: такие механизмы мешают работе приложения в RuStore;
• запрещённые разрешения Android в сборке.

Платежи через RuStore требуют монетизации: заявление подписывается УКЭП компании, подключает её владелец. Размер комиссии смотрите в консоли — условия меняются.

App Store: аккаунт, TestFlight и пять пунктов App Review

Для iOS нужен Apple Developer Program за 99 долларов США в год с ежегодным продлением. Аккаунт физлица оформляется на юридическое имя, и оно же станет названием продавца в магазине. Для организации Apple требует юридическое лицо (не филиал и не торговое название), рабочую почту и живой сайт на домене компании, D-U-N-S Number и регистранта с правом подписи. Нужна двухфакторная аутентификация.

Отдельный вопрос для России — оплата. По правилам Apple, там, где её онлайн-магазин недоступен, членство оплачивают через форму банковской карты, с которой можно списать доллары США, а физлицо платит только своей картой. Подойдёт ли карта российского банка, выясните заранее: способ платежа лучше решить до старта разработки, иначе iOS-версия будет готова, а выпустить её будет не из чего.

Что проверяет App Review

1. Законченность (п. 2.1). Без заглушек и пустых разделов. Если есть вход, дайте проверяющему демо-аккаунт и включите сервер: выключенный на время проверки сервер — нелепая причина отказа.
2. Минимальная функциональность (п. 4.2). Приложение должно давать больше, чем упакованный сайт.
3. Данные (п. 5.1.1). Ссылка на политику в карточке и в приложении, согласие на сбор данных, удаление аккаунта из самого приложения.
4. Платежи (п. 3.1.1 и 3.1.3). Цифровые товары и подписки продаются через встроенные покупки Apple. Физические товары и услуги, которые потребляются вне приложения, оплачиваются картой или Apple Pay. Для интернет-магазина это ключевой пункт: верная схема избавляет от комиссии Apple с каждой покупки.
5. Вход через сторонние сервисы (п. 4.8). Если есть вход через соцсеть или другой сторонний сервис, нужен равноценный вариант входа с ограниченным сбором данных (только имя и почта, возможность скрыть адрес). Исключения есть, например, у приложений, где вход устроен только через собственные аккаунты компании.

С 28 апреля 2026 года App Store Connect принимает сборки только из Xcode 26 и новее. Перед публикацией приложение раздают тестировщикам через TestFlight: до 10 000 внешних пользователей.

Google Play: взнос, закрытое тестирование и целевой API

Регистрация стоит 25 долларов США один раз. Принимаются Visa, Mastercard и American Express, предоплаченные карты не подходят. Google может запросить документ и карту на одно юридическое имя; при недействительных данных взнос не возвращается. Условия по оплате и выплатам для российских компаний менялись, поэтому уточните их в справке Play Console до подписания договора.

Тест для новых личных аккаунтов

Если аккаунт личный и создан после 13 ноября 2023 года, выйти в производство можно только после закрытого теста: не меньше 12 тестировщиков, каждый подписан на тест 14 дней подряд. Затем подаётся заявка; Google обычно рассматривает её до семи дней. Для организационных аккаунтов это требование не действует, и это стоит учесть при выборе типа аккаунта.

Целевой API и верификация разработчиков

С 31 августа 2026 года новые приложения и обновления для телефонов должны ориентироваться на Android 16 (API 36); можно запросить продление до 1 ноября 2026 года. Это ежегодное требование, его закладывают в поддержку.

Отдельно для всех, кто распространяет Android-приложения, включая RuStore: Google вводит обязательную верификацию разработчиков. По данным Google, с 30 сентября 2026 года защита начинает работать для пользователей в Бразилии, Индонезии, Сингапуре и Таиланде, а на остальные страны проверку планируют распространить в 2027 году. Сроки могут измениться, следите за документацией Google.

Персональные данные в приложении: что требуют закон и магазины

Регистрация по телефону, адрес доставки или геолокация означают обработку персональных данных и подпадают под 152-ФЗ. Магазины проверяют это сами. Заложите в ТЗ:

• Политику обработки на русском языке со ссылкой в карточке и внутри приложения: что собирается, зачем, как долго хранится, как удалить.
• Согласие отдельно от иных документов и без предустановленной галочки: с 1 сентября 2025 года это закреплено в части 1 статьи 9 закона 152-ФЗ, и то же отмечают правила RuStore.
• Место хранения. Базу с данными граждан России размещают на серверах в России. Каждый зарубежный SDK аналитики или рассылок нужно проверить.
• Реакцию на утечки. Роскомнадзор уведомляют первично в течение 24 часов, затем в течение 72 часов с результатами расследования.
• Удаление аккаунта из приложения — требование Apple и RuStore.

Добавлять эти пункты после тестирования дороже, а отказ магазина из-за политики задерживает релиз.

После релиза: поддержка, обновления под новые версии ОС и метрики роста

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

Что входит в сопровождение

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

Годовое сопровождение ориентировочно закладывают в размере 15–25% от стоимости разработки: для приложения за 4,4 млн ₽ это 660 000–1 100 000 ₽ в год, или 55 000–92 000 ₽ в месяц. Новые функции в эту сумму не входят. Обязательные обновления идут по календарю магазинов (требования Apple и Google к сборкам описаны выше). Приложение, о котором «забыли» на год, превращает следующее обновление в проект.

Метрики первых 90 дней

Подключите аналитику до релиза, например Яндекс AppMetrica, и договоритесь, какие числа смотрите раз в неделю.

• Активная аудитория. Число уникальных пользователей за месяц, MAU, показывает, живёт ли приложение, а не только скачивается.
• Удержание. Допустим, из 1 000 установивших на седьмой день возвращаются 120 человек: 12% — повод разбирать путь нового пользователя.
• Доля сессий без сбоев: падения убивают оценку в магазине быстрее остального.
• Целевое действие. Конверсия из установки в первый заказ, запись или оплату и стоимость такого действия по каналам.

Где заказчики теряют бюджет: восемь ошибок до и после релиза

1. Старт без ТЗ и приоритетов. «Сделайте как у конкурента» приводит к запасу в смете и к спору через три месяца о том, что входило в цену. Хватит списка функций с разметкой «обязательно, желательно, потом».
2. Всё сразу в первой версии. Функции «на всякий случай» нельзя проверить на пользователях, но можно оплатить.
3. Две нативные платформы по умолчанию. Для типового приложения кроссплатформа даёт тот же результат дешевле: просите расчёт обоих вариантов.
4. Магазины проверены в конце. Подпись для RuStore, оплата и D-U-N-S для Apple, двухнедельный тест личного аккаунта Google Play занимают недели. Оформляйте аккаунты параллельно с дизайном.
5. Дизайн без прототипа. Правки после вёрстки меняют и дизайн, и код.
6. Приёмка «по скриншотам». Требуйте установленную сборку каждые две недели, доступ к репозиторию и трекеру задач.
7. Код и аккаунты у подрядчика. Аккаунты в магазинах оформляйте на свою компанию, репозиторий держите у себя. В RuStore подпись в обновлениях должна совпадать с прошлой версией, и потеря ключа лишает вас возможности выпускать обновления.
8. Бюджет только на разработку. Без поддержки и продвижения через месяц после релиза приложение никто не скачивает, а ошибки копятся.

Чек-лист перед подписанием договора: двенадцать пунктов

Пройдитесь по списку с подрядчиком вслух: на пункте, где звучит «потом разберёмся», остановитесь.

1. Сформулированы цель и число, которое должно вырасти.
2. Понятно, почему нужно приложение, а не сайт или PWA.
3. Выбраны платформы и технология, подрядчик объяснил почему.
4. Есть ТЗ или список функций с приоритетами.
5. Первая версия урезана до необходимого минимума.
6. Смета разбита по этапам и ролям, указана ставка часа или цена этапа.
7. В договоре описаны результаты этапов и порядок приёмки.
8. Права на код и дизайн переходят к вам; ключи подписи и репозиторий лежат у вас.
9. Назначены владелец продукта и срок ответа на вопросы команды.
10. Решены вопросы с аккаунтами: подпись для RuStore, оплата и D-U-N-S для Apple, тип аккаунта Google Play.
11. Учтены требования к персональным данным.
12. Прописаны гарантийный период, поддержка и бюджет на продвижение.

Студия, фрилансер или штатная команда: три модели с цифрами

Расчёт для штатной команды: допустим, пять специалистов получают по 200 000 ₽ на руки. С налогами, взносами и рабочими местами это около 1,5 млн ₽ в месяц, 18 млн ₽ в год — до первой строки кода. Для разовой задачи невыгодно, для продукта, который развивается годами, подходит. Какую модель ни выберете, просите показать опубликованные приложения и поговорите с их владельцами.

С чего начать: бриф на одну страницу и бесплатный аудит

Чтобы получить честную оценку, а не абстрактное «от и до», подрядчику нужен бриф на одной странице:

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

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

Если вы пока не уверены, что приложение нужно, начните с бесплатного аудита: мы проверим сайт и данные Яндекс Метрики, покажем, где теряются заявки, и скажем прямо, не хватит ли доработки сайта вместо приложения.

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