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

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

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

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

  • Неделя 1 — сценарий и платформы. На руках: согласованный объём первого релиза, сумма его этапа и доступы, оформленные на вашу компанию.
  • Недели 2–4 — каркас и серверная часть. На руках: тестовая сборка на вашем телефоне, которая обновляется сама.
  • Недели 5–7 — доводка до боя. На руках: сборка, на которой можно провести настоящий сценарий с деньгами.
  • Неделя 8 — публикация и передача. На руках: приложение в обоих сторах, ключи и аккаунты у вас, инструкция по релизу.

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

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

Неделя 1: один сценарий и аккаунты на ваше имя

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

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

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

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

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

Если задача не укладывается в один разговор, перед разработкой идёт отдельный этап «ТЗ и прототип». Он платный, результат остаётся у вас, а его стоимость идёт в зачёт проекта, если работа продолжается.

Итог недели: согласованный объём первого релиза, сумма его этапа и доступы, оформленные на вашу компанию.

Недели 2–4: каркас, сервер и первая сборка на вашем телефоне

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

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

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

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

Замечание на третьей неделе обычно стоит одной правки. То же замечание на восьмой неделе упирается в уже отправленную на ревью сборку и тянет за собой повторную отправку.

Итог этапа: тестовая сборка на вашем устройстве, которая обновляется сама.

Недели 5–7: деньги, пуши и плохая сеть

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

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

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

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

Итог этапа: сборка, на которой можно провести настоящий сценарий с деньгами.

Неделя 8: публикация и ревью, сроки которого назначаем не мы

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

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

Само ревью назначаем не мы: обычно от нескольких часов до нескольких дней, иногда дольше, если приложение работает с деньгами или медициной. Гарантированных сроков ревью не обещаем — их назначают Apple и Google, и кто обещает иначе, гадает.

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

Итог: приложение в обоих сторах, ключи и аккаунты у вас, инструкция по релизу.

Процесс разработки мобильного приложения глазами заказчика

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

  • Неделя 1: сценарий. Какой один путь пользователя должен работать к релизу. Всё остальное уходит в следующие версии.
  • Неделя 1: аккаунты. Аккаунты разработчика Apple и Google оформляются на вашу компанию. На студию мы их не заводим: продукт должен оставаться вашим.
  • Недели 2–7: ответы по ходу. Сборка у вас на телефоне, вопросы приходят по мере работы. Чем быстрее ответ, тем меньше приходится переделывать.
  • Неделя 8: демо-доступ для ревью. Проверяющему Apple нужен аккаунт с данными: пустой демо-аккаунт — повод развернуть приложение. Что в нём можно показывать постороннему человеку, решаете вы.
  • Неделя 8: материалы для сторов. Тексты описания и скриншоты готовит ваша сторона. Продвижение в сторах и рекламные кампании в нашу работу тоже не входят.

Деньги устроены по тем же этапам. Первый релиз стоит от 800 000 ₽, цена «от», оплата по этапам. Сумма этапа не растёт, пока не меняется объём, а если объём меняется, изменение пересчитывается до начала работ, а не задним числом.

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

Что происходит после релиза

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

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

Круглосуточное дежурство по умолчанию не входит. Оповещения о сбоях приходят вам, а мы отвечаем в рабочие часы, если сопровождение не куплено.

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

С чего начать

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

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

И одно ограничение, о котором лучше знать заранее: игры, AR и всё, что живёт частотой кадров, — не наш профиль.