MVP мобильного приложения: что оставить в первой версии, чтобы её пропустили магазины и было что проверять

Короткий ответ: MVP мобильного приложения — это не «половина приложения», а одна законченная задача клиента, которую можно пройти от установки до результата. В первую версию кладут главный сценарий, один способ входа, обязательное для магазинов (политику конфиденциальности, удаление аккаунта, сведения о данных) и аналитику событий. Всё остальное — второй и третий релиз. У нас такая версия укладывается в тариф от 200 000 ₽ и от 2 недель, если в ней до 6–8 экранов.

Ниже — что магазины требуют даже от маленькой сборки, как выбрать платформу и какие цифры смотреть после выхода. Правила магазинов сверены с официальными документами Apple и Google на 31 октября 2026 года.

Чем MVP приложения отличается от MVP сайта или сервиса?

Между вами и пользователем стоит магазин. Сайт можно выложить в любом виде и поправить вечером, а приложение до публикации смотрит проверяющий App Store или Google Play, и каждое обновление снова проходит проверку. Поэтому «сырая» первая версия обходится дороже: её вернут, а время уйдёт.

Из этого следуют три практических отличия:

• Порог входа для клиента выше. Человек должен найти приложение, установить его, разрешить уведомления и зарегистрироваться. Если ценность не видна на первом же экране, до второго он не дойдёт.
• Исправления приходят не сразу. Новая сборка уходит на проверку, потом пользователи обновляются не одновременно. Ошибку в веб-сервисе исправляют для всех за минуты, в приложении — за дни.
• Есть обязательный минимум, который не связан с вашей идеей. Политика, удаление аккаунта, анкета о данных, демо-доступ для проверяющего. Его нельзя «отложить до второй версии».

Общая логика MVP — один сценарий, проверка спроса, развитие итерациями — разобрана в статье MVP или полная версия: с чего начать разработку сервиса. Здесь — только то, что добавляет мобильная платформа.

Какой минимум нужен, чтобы первую версию пропустили магазины?

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

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

Что ещё проверяющий ждёт от первой версии по App Store Review Guidelines:

• Рабочий демо-доступ и включённый сервер (правило 2.1). Если вход по коду из SMS, проверяющему нужен тестовый номер или демо-аккаунт, иначе он не увидит ничего, кроме экрана входа.
• Никаких «бета»-меток в публичной версии (правило 2.2). Демо и бета-версии распространяются через TestFlight, а в магазин уходит версия, которой можно пользоваться.
• Вход — только когда он нужен (правило 5.1.1(v)). Если ключевые функции не завязаны на аккаунт, приложение должно работать без регистрации. Каталог кофейни можно показать сразу, а вход попросить на шаге «копить бонусы».

Частые причины отказов с номерами правил и тем, как отвечать проверяющему, разобраны в статье почему App Store отклоняет приложения.

Что обязательно с первого дня, даже если хочется отложить?

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

1. Политика конфиденциальности. По правилу 5.1.1(i) ссылка на неё нужна и в App Store Connect, и внутри приложения в легко доступном месте. В тексте — какие данные собираете, кому передаёте (включая сервисы аналитики и сторонние библиотеки), как долго храните и как человек может отозвать согласие. Это пересекается с требованиями 152-ФЗ — подробно в статье о персональных данных в мобильном приложении.
2. Удаление аккаунта в самом приложении. Apple требует его от любого приложения с регистрацией. Google Play — тоже, и добавляет второе условие: веб-страницу, где удаление можно запросить без установленного приложения. Это пара экранов и обработчик на сервере, но о них часто вспоминают в день отправки.
3. Сведения о данных. В App Store — App privacy details, в Google Play — раздел Data safety. Заполняются за всё, что собирает приложение, включая встроенные SDK аналитики и push. Ответы должны совпадать с политикой и с реальным поведением сборки.
4. Актуальный target API для Android. С 31 августа 2026 года новые приложения и обновления в Google Play должны быть собраны под Android 16 (API 36), продление можно было запросить до 1 ноября 2026 — так сказано в требованиях Google. Для нового проекта это решается при сборке, для старого кода может означать обновление библиотек.
5. Доступ для проверяющего. Тестовый аккаунт с данными, на которых видно все функции, и короткая записка: что нажать, где главный сценарий.

Как выбрать единственный сценарий для первой версии?

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

Проверить себя помогает простое упражнение: распишите путь клиента по шагам и отметьте, какой экран нужен на каждом. Если шагов больше семи-восьми, сценарий можно сократить. Несколько примеров, как это выглядит:

• Кофейня. Главное — карта в телефоне и начисление бонусов на кассе. Предзаказ к определённому времени, меню с фото и акции — второй релиз.
• Салон или студия. Выбор услуги, мастера и времени, подтверждение и напоминание. Оплата абонементов, отзывы о мастерах и подарочные сертификаты — потом.
• Выездные сотрудники. Список задач на день, отметка «выполнено» с фото и комментарием. Маршруты на карте, работа без связи и отчёты для руководителя — следующими шагами. Учтите: офлайн-режим, если без него в поле не обойтись, сразу добавляет заметный объём работы.
• Управляющая компания. Заявка с фото и статус её выполнения. Показания счётчиков, пропуска, оплата и голосования — второй и третий релиз.

Функция	В первой версии	Можно отложить	Почему так
Главный сценарий (запись, заказ, заявка, бонусы)	Целиком, от входа до результата	Нельзя	Ради него ставят приложение; без него проверять нечего
Вход и регистрация	Один способ: телефон или email	Второй и третий способ входа	Каждый способ — отдельные экраны, тексты ошибок и проверка
Удаление аккаунта	Да, если есть регистрация	Нельзя	Требование App Store и Google Play, без него сборку вернут
Политика конфиденциальности	Ссылка в карточке магазина и внутри приложения	Нельзя	Требование магазинов и 152-ФЗ
Push-уведомления	Одно-два события: статус заказа, напоминание о записи	Рассылки и сегменты	Служебный push проверяет, возвращаются ли люди; маркетинг — позже
Оплата	Если без неё сценарий не замкнут	Подписки, промокоды, рассрочка	Правила магазинов про оплату зависят от того, что продаёте
Профиль и настройки	Имя, контакты, выход, удаление	Аватар, темы, детальные настройки	Мало влияют на главный вопрос первой версии
Чат с менеджером, карты, видео	Только если это суть продукта	Да	Каждая такая часть оценивается отдельно и растит срок
Аналитика событий	Да, 5–10 ключевых событий	Сложные воронки и когорты	Без событий через месяц нечего анализировать
Админка для сотрудников	Простая: список заявок, статусы	Отчёты, роли, выгрузки	Чтобы команда могла обработать первые заказы

Что оставить в первой версии, а что отложить?

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

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

Одна платформа или сразу iOS и Android?

Если приложение собирается из общего кода на React Native или Flutter, вторая платформа обычно не удваивает бюджет: основная часть экранов и логики общая. Удваиваются тестирование на устройствах, публикация и поддержка двух карточек. Поэтому решение зависит больше от ваших клиентов, чем от денег.

Как рассуждать:

• Клиенты — массовая аудитория. Разумно сразу делать обе платформы: иначе часть людей не сможет установить приложение и ваши метрики первого месяца будут неполными.
• Приложение для своих сотрудников. Можно начать с той платформы, на которой у команды рабочие телефоны, и раздать без публичного магазина.
• Нужно проверить идею за неделю. Посмотрите на PWA — веб-приложение, которое ставится на домашний экран. Пример: у игры «Час пик» есть веб-версия, которая устанавливается как обычное приложение и работает офлайн после первого открытия; клиенту достаточно ссылки. Ограничения PWA на iPhone (push, доступ к функциям телефона) стоит обсудить до старта; сравнение вариантов — в статье PWA, кроссплатформа или натив.

Отдельный момент про Google Play и сроки. Если аккаунт разработчика личный и создан после 13 ноября 2023 года, перед выходом в продакшен нужен закрытый тест: не меньше 12 тестировщиков, которые не отписываются 14 дней подряд. Это две недели к плану запуска. В справке Google правило сформулировано для личных аккаунтов, поэтому компании разумно сразу оформлять аккаунт на организацию.

Как проверить первую версию до публичного релиза?

Раздайте сборку 10–30 людям, похожим на ваших клиентов, через TestFlight и закрытое тестирование Google Play, и попросите пройти главный сценарий без подсказок. Смотрите, где они застревают, а не что им «нравится».

Что важно на этом этапе:

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

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

Сколько стоит и сколько делается MVP приложения?

У нас мобильное приложение стоит от 200 000 ₽, срок — от 2 недель. В эту сумму входят до 6–8 экранов для iOS и Android из одного кода (или PWA), вход по телефону или email, push-уведомления, базовая аналитика, оплаты, подключение к вашему API или простой сервер на нашей стороне и публикация в обоих магазинах.

Хорошая первая версия как раз и укладывается в 6–8 экранов: вход, главный экран, два-три экрана сценария, профиль с удалением аккаунта, настройки. Что важно знать про бюджет и условия:

• Отдельно оплачиваются аккаунты разработчика Apple и Google Play (оформляются на вас), сторонние платные сервисы вроде SMS и хостинга, а также сложная логика — чаты, карты, видеозвонки, которые считаем после брифа.
• Правки: до 2 раундов на прототипе и до 2 на готовой сборке. Поэтому состав первой версии стоит зафиксировать до дизайна, а не менять в процессе.
• Оплата — 50 % предоплаты и 50 % после подписания акта. Цену и срок фиксируем в договоре до старта, объём меняется только отдельным документом.
• После публикации — 14 дней бесплатных мелких правок, гарантия по договору 30 календарных дней с даты акта, дальше поддержка от 7 900 ₽ в месяц или почасово.
• Вы получаете исходный код приложения и сервера в своём репозитории, опубликованные приложения под своими аккаунтами и доступы ко всем сервисам. Исключительное право на код по договору остаётся у исполнителя, а вам предоставляется лицензия на весь срок действия права: любой сервер, любые подрядчики.

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

Показатель	Что он говорит	Тревожный сигнал
Установки → регистрация	Понятен ли вход и зачем он нужен	Большинство ставит и не регистрируется
Регистрация → первое целевое действие	Доходит ли человек до главного сценария	Регистрируются, но не делают ни одного заказа или записи
Возврат через неделю	Есть ли повод открыть приложение снова	Приложение открывают один раз
Отказ от push при первом запросе	Убедил ли экран перед системным вопросом	Почти все отказываются
Сбои и вылеты	Стабильность на реальных телефонах	Вылеты на одной модели или версии системы
Оценки и отзывы в магазине	Что раздражает живых пользователей	Одна и та же жалоба повторяется

Какие показатели смотреть в первый месяц?

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

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

Когда MVP приложения вам не нужен?

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

• Нет повторяющегося действия. Разовая покупка или заявка — задача для сайта.
• Нужно просто показать каталог. Хватит быстрой мобильной версии сайта.
• Спрос уже доказан, а процесс понятен. Например, у вас работает веб-кабинет, и нужна его мобильная версия с тем же набором функций. Тогда это не MVP, а перенос, и его планируют сразу целиком.
• Нет человека, который будет обрабатывать заказы из приложения. Первые клиенты уйдут, если на их запись никто не ответит.

Какие ошибки чаще всего делают с первой версией?

Самая частая — пытаться положить в MVP всё, что есть у крупного конкурента. Вторая — отложить обязательное для магазинов. Третья — выпустить приложение без аналитики и без плана, кто будет отвечать на отзывы.

• Разделы-заглушки «скоро появится». Для проверяющего это незаконченное приложение, для клиента — повод удалить.
• Обязательная регистрация до показа ценности. Сначала покажите, что умеет приложение, потом просите телефон.
• Запрос всех разрешений при первом запуске. Push, геолокацию, камеру просите в тот момент, когда они нужны, с пояснением зачем.
• Личный аккаунт разработчика на сотрудника. Помимо закрытого теста в Google Play, это риск потерять доступ к приложению, когда человек уйдёт.
• Нет демо-доступа для проверки. Сборку вернут, даже если всё работает.
• Нет плана второго релиза. MVP — начало, а не итог. Заранее решите, какие две-три функции добавите, если показатели первого месяца подтвердят спрос.

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

Короткие ответы на частые вопросы

MVP мобильного приложения — это что простыми словами?

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

Можно ли опубликовать в App Store «тестовую» версию с пометкой beta?

Нет. По правилу 2.2 демо, беты и пробные версии в App Store не публикуются — для них есть TestFlight. В магазин уходит версия, которой можно пользоваться по-настоящему.

Сколько стоит MVP мобильного приложения у Roboweb?

От 200 000 ₽ и от 2 недель за приложение до 6–8 экранов для iOS и Android из одного кода, с входом, push-уведомлениями, оплатами и публикацией. Если первая версия больше тарифа, цену и срок считаем после брифа и фиксируем в договоре до старта.

Нужно ли удаление аккаунта, если у нас всего три экрана?

Если в приложении можно зарегистрироваться — да, и в App Store, и в Google Play. Для Google Play нужна ещё веб-страница, где можно запросить удаление без приложения.

Почему новый разработчик не может сразу выложить приложение в Google Play?

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

Услуги и кейсы по теме: мобильные приложения · кейс «Час пик» · цены и сроки