Сколько времени занимает разработка мобильного приложения

Простое мобильное приложение обычно разрабатывают за 2–4 месяца, приложение средней сложности — за 4–7 месяцев, а сложный продукт с большим количеством интеграций или жесткими требованиями регулятора — за 8–12 месяцев и больше. MVP с четко ограниченным набором функций часто можно запустить за 2–4 месяца.

Диапазоны широкие не случайно. Одно и то же «приложение для доставки» может быть экраном заказа для одного ресторана, а может быть платформой для клиентов, курьеров и партнеров. В статье раскладываем сроки по этапам и типам приложений, объясняем, что их растягивает и сокращает, и показываем, как ускорить работу без потери качества. Цифры берем из проектов, которые делаем в рамках разработки мобильных приложений, а не из рекламных обещаний.

Средние сроки разработки приложения

Если нужен быстрый ориентир, начните со сложности. В таблице реалистичные диапазоны от начала discovery до первого публичного релиза.

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

Вот как может выглядеть календарь приложения средней сложности, если его делают кроссплатформенно, а клиент отвечает за день-два:

В сумме примерно полгода. Наложение этапов намеренное: разработка стартует до того, как нарисован последний экран, а тестирование начинается с первого спринта.

Сроки разработки по этапам

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

Discovery и требования

Длительность: 2–4 недели для большинства приложений, до 6–8 недель для сложных платформ.

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

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

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

Чтобы discovery прошел быстро, подготовьте заранее несколько вещей: кто ваши пользователи и какую проблему приложение для них решает, с какими системами оно должно работать (CRM, учет, оплата, доставка), кто с вашей стороны принимает решения и какие есть жесткие ограничения по дате запуска. Даже черновик на две страницы сокращает этап на неделю.

UX/UI дизайн

Длительность: 3–8 недель в зависимости от количества экранов и ролей пользователей.

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

UI-дизайн добавляет визуальный слой: цвета, шрифты, иконки, компоненты и их состояния. Для приложения, которое будет развиваться, дизайнеры создают дизайн-систему — библиотеку компонентов с правилами использования. Она ускоряет и дальнейший дизайн, и разработку.

Разработка

Длительность: 2–6 месяцев для большинства приложений, дольше для сложных платформ.

Это самый длинный этап, и он охватывает три слоя:

• Frontend, само мобильное приложение: экраны, навигация, локальное хранение, работа офлайн, push-уведомления.

• Backend, серверная часть: бизнес-логика, база данных, управление пользователями, админка.

• API, слой, который соединяет приложение с backend и сторонними сервисами: оплатой, картами, CRM.

Большинство команд работают по Agile и Scrum: разработку делят на спринты по одной-две недели, каждый заканчивается рабочей частью продукта, которую клиент может увидеть и протестировать. Прогресс виден, а приоритеты можно менять без перезапуска проекта.

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

Длительность этого этапа почти полностью зависит от объема. Экран входа занимает дни. Отслеживание заказа в реальном времени с геолокацией курьера занимает недели.

Выбор backend тоже влияет. Собственный backend дает полный контроль и подходит для продуктов со сложной бизнес-логикой. Готовые платформы вроде Firebase закрывают авторизацию, базу данных и уведомления «из коробки», что может сэкономить недели на MVP. Цена этого — меньшая гибкость в будущем, поэтому решение должно соответствовать планам развития продукта, а не только дате запуска.

QA и тестирование

Длительность: параллельно с разработкой, плюс 2–4 недели стабилизации перед релизом.

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

Перед релизом команда раздает бета-версии закрытой группе тестировщиков. На iOS это обычно TestFlight, на Android — закрытое тестирование в Google Play Console.

Отдельно про Android. Устройств на этой системе намного больше, чем моделей iPhone: разные производители, размеры экранов, версии системы и собственные оболочки. В Украине у Android заметная доля рынка, поэтому тестирование на нескольких реальных устройствах разных ценовых сегментов — не роскошь, а необходимость. Закладывайте на это время в плане QA.

Публикация и ревью в сторах

Длительность: от нескольких дней до 3 недель.

Оба магазина проверяют приложения перед публикацией. По данным Apple, большинство заявок в App Store рассматривают в течение 24 часов, хотя первая публикация и приложения из чувствительных категорий могут проверяться дольше, а отказы добавляют новые циклы. Ревью в Google Play обычно длится от нескольких часов до нескольких дней.

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

Релиз также включает страницы в сторах (скриншоты, описания, данные о конфиденциальности), продакшен-сборки, настройку аналитики и план выкатки. Поэтапный релиз на часть пользователей уменьшает риск неудачной версии.

Поддержка после запуска

Длительность: постоянно.

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

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

Время, о котором легко забыть. Часть работы вообще не зависит от разработчиков, но влияет на дату запуска:

• Аккаунты разработчика. Чтобы публиковаться в App Store от имени компании, нужно зарегистрироваться в Apple Developer Program как организация, а для этого нужен номер D-U-N-S. Если его в компании еще нет, получение может занять от нескольких дней до нескольких недель. Google Play для аккаунтов организаций тоже требует номер D-U-N-S и проверяет личность разработчика и данные организации.

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

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

• Согласования сторонних сервисов. Платежные провайдеры, карты, банковские API, BankID и некоторые способы входа требуют отдельных заявок, договоров или проверок.

Начинайте эти задачи на этапе дизайна, а не за неделю до релиза.

Сроки по типу приложения

Этапы одинаковы для всех приложений. Отличается объем работы внутри каждого. Вот что делает распространенные типы короче или длиннее.

MVP

Типичный срок: 2–4 месяца.

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

Самая частая причина, почему MVP занимает 6 месяцев вместо 3, — это разрастание объема: «раз уж делаем, добавим чат, реферальную программу и темную тему». Каждая мелочь невелика, вместе они удваивают срок. Если планируете первую версию, наша разработка MVP для стартапов построена именно на этой дисциплине.

e‑commerce приложение

Типичный срок: 4–7 месяцев.

Основа e‑commerce приложения: каталог с поиском и фильтрами, корзина, оформление с оплатой и трекинг заказов. Время уходит на интеграции: платежные сервисы, учет остатков, службы доставки вроде Новой почты, программы лояльности. Если приложение работает рядом с существующим интернет-магазином, backend может уже существовать, и срок сокращается. Если каталог, цены и остатки живут в нескольких системах, их синхронизация может занять столько же времени, сколько само приложение.

Приложение для доставки

Типичный срок: 6–10 месяцев.

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

Финтех-приложение

Типичный срок: 8–12+ месяцев.

Финтех-приложения дольше из-за требований регулятора и безопасности, а не из-за экранов. KYC-проверки, мониторинг транзакций, защита персональных данных, интеграции с банками и платежными системами добавляют работы. В Украине к этому часто добавляются вход и верификация через BankID или подписание документов через Дія.Підпис, и у каждой из этих интеграций свои условия подключения и тестирования. Большинство финтех-продуктов также проходят внешний аудит безопасности и пентест перед запуском, и исправление находок занимает время.

Маркетплейс и соцсеть

Типичный срок: 6–12 месяцев.

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

Корпоративное приложение

Типичный срок: 9–12+ месяцев.

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

iOS или Android первым: как это влияет на сроки. Если бюджет или команда не позволяют запускать обе платформы одновременно, приходится выбирать, с чего начать. Решение зависит от аудитории. В Украине у Android большая доля пользователей, особенно в массовых сегментах, поэтому для сервисов доставки, розницы или финансовых продуктов широкого потребления Android часто важнее. Для премиальных сервисов и B2B-продуктов с аудиторией в США или отдельных странах Западной Европы, где доля iPhone выше, часто логично начать с iOS. Прежде чем решать, проверьте долю платформ именно на ваших целевых рынках.

Технически платформы отличаются не так сильно, как кажется, но есть нюансы. Устройств на Android намного больше, поэтому тестирование занимает больше времени. На iOS меньше моделей, зато строже требования к ревью и дизайну по Apple Human Interface Guidelines. Кроссплатформенная разработка снимает большую часть этого выбора, потому что позволяет выпустить обе версии почти одновременно, а разницу во времени сводит к тестированию и публикации.

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

Что влияет на сроки разработки

Вот основные факторы примерно в порядке их влияния.

Объем функций. Самый большой фактор. Каждая функция добавляет дизайн, разработку, тестирование и граничные случаи. Убрать функции из первой версии — самый эффективный способ запуститься раньше.

Количество платформ. Приложение для iOS, Android и web с точки зрения пользователя — это три продукта, даже если часть кода общая. Запуск сначала на одной платформе и добавление других позже — вполне рабочая стратегия.

Нативная или кроссплатформенная разработка. Нативные приложения для iOS пишут на Swift, для Android — на Kotlin. Это две отдельные кодовые базы и две линии разработки. Кроссплатформенные фреймворки Flutter и React Native позволяют одной команде сделать оба приложения из общей кодовой базы, что для типичных бизнес-приложений обычно заметно экономит время. Нативная разработка по-прежнему имеет смысл для приложений, которые активно используют «железо» устройства, сложные анимации или новейшие функции платформ. Подробнее о преимуществах разработки на Flutter и разработке приложений на React Native мы писали отдельно.

Интеграции. Оплата, карты, CRM, ERP, аналитика, службы доставки, BankID. Хорошо документированные API подключаются за дни. Старые или плохо описанные системы могут забрать недели, и часто это невозможно знать, пока команда не начнет с ними работать.

Требования регулятора. Защита персональных данных, GDPR для пользователей из ЕС, KYC для финансовых сервисов, требования доступности. Каждое требование добавляет документацию и тестирование.

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

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

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

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

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

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

Почему оценка меняется и когда ей можно доверять. Оценка, сделанная по идее на одну страницу, легко может ошибаться в два раза, потому что никто еще не знает деталей каждой функции, интеграции и нестандартных сценариев. После discovery, когда понятны user stories, макеты ключевых экранов и требования к интеграциям, диапазон становится намного уже. Это нормально, поэтому опытные команды на старте дают диапазон, а более точный план — после discovery. Если кто-то после 30-минутного звонка называет точную дату для сложного приложения, спросите, на каких допущениях она держится.

Украинская специфика, которая влияет на сроки. Языковые версии добавляют не только перевод, но и тестирование каждого языка: более длинные украинские и русские слова часто ломают кнопки и заголовки, рассчитанные на английский. Интеграции с «Новой почтой», LiqPay, monobank или Checkbox обычно имеют удобные API, но каждая требует тестовых аккаунтов и проверки на реальных сценариях. Вход через BankID или Дія.Підпис требует отдельного подключения и согласований, поэтому закладывайте на это время с самого начала.

Как ускорить разработку без потери качества

Быстрее не обязательно значит хуже. Вот подходы, которые реально сокращают сроки:

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

Выбирайте кроссплатформенную разработку, когда она подходит. Flutter или React Native для типичных бизнес-приложений означает одну кодовую базу вместо двух.

Ведите дизайн и разработку параллельно. Как только согласованы ключевые сценарии и дизайн-система, разработчики начинают backend, API и первые экраны, пока дизайнеры завершают остальное.

Переиспользуйте компоненты. Дизайн-система с одной стороны и готовые модули (авторизация, оплата, уведомления) с другой означают, что команда не решает одну задачу дважды.

Автоматизируйте через CI/CD. Непрерывная интеграция и доставка автоматически собирают, тестируют и раздают приложение после каждого изменения. Тестировщики получают новые сборки за минуты, а подготовка релиза перестает быть ручным проектом.

Работайте с выделенной командой. Команда, которая работает только над вашим продуктом, не переключается между клиентами и сохраняет знания внутри проекта. Чем выделенная команда отличается от fixed price и почасовой оплаты, мы разбирали в статье про модели сотрудничества в IT.

Принимайте решения быстро. Назначьте с вашей стороны одного человека, который может согласовать дизайн и ответить на вопросы за день-два.

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

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

Пример из реального проекта

Sailica — это онлайн-платформа бронирования яхт из Великобритании. Первым этапом был web-MVP, который наша команда из 8 специалистов сделала за 3 месяца. Это стало возможным благодаря узкому объему: MVP покрывал ключевой сценарий поиска и бронирования яхты, а остальной продукт вырастал из него в следующих релизах.

Когда web-платформа доказала свою ценность, следующим шагом стало нативное iOS-приложение. Команда из 5 специалистов сделала его на Swift примерно за 440 часов работы. Поскольку backend, бизнес-логика и визуальный язык уже существовали, приложение использовало их вместо старта с нуля. Это типичный эффект хорошо спланированного MVP: второй продукт делается быстрее, потому что первый уже ответил на самые сложные вопросы.

В целом разработка платформы Sailica продолжалась около 18 месяцев, и это нормально. Первый релиз занял 3 месяца. Все, что дальше, — это развитие продукта на основе реальных данных пользователей.

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