Пошагово разбираем, из каких этапов состоит разработка мобильного приложения — от аналитики до публикации в App Store и Google Play — и что реально происходит на каждом из них.
Когда заказчик впервые сталкивается с разработкой мобильного приложения, процесс часто представляется одним монолитным этапом: «отдали техзадание — получили приложение». На практике между этими двумя точками лежит несколько последовательных этапов, каждый из которых закрывает свой класс рисков, и пропуск любого из них почти гарантированно всплывает уже после релиза — в виде переделок, отказов сторов или недовольства пользователей.
Аналитика и прототипирование
Первый этап — не дизайн и не код, а формализация того, что приложение должно делать. Здесь определяется целевая аудитория, ключевые пользовательские сценарии, состав экранов и логика переходов между ними. Результат этого этапа — не документ на сто страниц, а кликабельный прототип (wireframe), по которому уже можно провести пользователя через основной сценарий и увидеть нестыковки до того, как они попадут в код.
Именно на этом этапе принимается решение о технологическом стеке — WebView, React Native или полностью нативная разработка. Мы подробно разбирали критерии этого выбора в статье «На чём разрабатывают мобильные приложения: обзор технологий» — от решения, принятого здесь, зависит и стоимость, и сроки всех последующих этапов.
UI/UX-дизайн
На основе прототипа разрабатывается визуальный дизайн: экраны, компоненты интерфейса, анимации переходов, состояния загрузки и ошибок. Важная деталь, которую часто недооценивают, — дизайн мобильного приложения должен учитывать различия между iOS и Android на уровне навигационных паттернов и системных элементов управления, а не быть одним макетом, механически натянутым на обе платформы.
Хороший дизайн-этап заканчивается не просто набором картинок, а UI-китом — библиотекой переиспользуемых компонентов с зафиксированными отступами, цветами, типографикой. Это напрямую ускоряет следующий этап: разработчик собирает экраны из готовых компонентов, а не согласовывает с дизайнером каждую мелочь по ходу вёрстки.
Разработка: клиентская часть и backend
Разработка обычно идёт параллельно в двух направлениях: клиентское приложение (то, что видит пользователь) и серверная часть (API, база данных, бизнес-логика, интеграции с внешними сервисами). Даже небольшому приложению почти всегда нужен backend — для хранения пользовательских данных, авторизации, синхронизации между устройствами.
На этом этапе также подключаются сторонние сервисы — платежи, push-уведомления, аналитика, карты. Мы подробно разбирали, как правильно проектировать такие интеграции, в статье «Разработка приложения с интеграцией сторонних сервисов: архитектура, а не просто SDK» — решения, принятые здесь, определяют, насколько устойчиво приложение будет вести себя при сбоях внешних сервисов уже после релиза.
Именно длительность этого этапа сильнее всего зависит от сложности функционала, и именно поэтому сроки разработки нельзя оценить одной цифрой без понимания состава фич — мы разбирали факторы, влияющие на сроки, в статье «От чего зависят сроки разработки мобильного приложения».
Тестирование
Тестирование мобильного приложения — это не только проверка «работает или нет», а прогон приложения через комбинации устройств, версий операционных систем, размеров экранов и сетевых условий. Отдельное внимание уделяется тестированию офлайн-сценариев и поведения приложения при обрыве соединения — это одна из самых частых причин негативных отзывов в сторах, если её пропустить на этапе разработки.
- функциональное тестирование — соответствие каждого экрана и сценария техническому заданию;
- тестирование на реальных устройствах, а не только в симуляторе, включая устройства с невысокой производительностью;
- нагрузочное тестирование backend, если ожидается большое количество одновременных пользователей;
- проверка поведения при плохом или отсутствующем интернет-соединении;
- приёмочное тестирование заказчиком перед публикацией.
Публикация в App Store и Google Play
Публикация — отдельный этап со своей спецификой и рисками, которые редко закладывают в изначальные сроки проекта. У App Store модерация может занимать от нескольких дней до пары недель, и приложение может быть отклонено по формальным причинам — от нарушения гайдлайнов интерфейса до недостаточно очевидной ценности приложения для пользователя, особенно если оно выглядит как обёртка над сайтом без нативной функциональности.
Google Play обычно проверяет быстрее, но требует аккуратной работы с разрешениями приложения (доступ к камере, геолокации, контактам) — избыточные разрешения без явного обоснования тоже становятся причиной отклонения. Опытная команда закладывает время на возможную повторную отправку на модерацию уже на этапе планирования сроков, а не воспринимает отказ стора как форс-мажор.
Поддержка после релиза
Релиз в сторе — не финальная точка проекта. Новые версии iOS и Android регулярно меняют требования и поведение системных API, и приложение, которое не обновляется, через полтора-два года начинает работать нестабильно даже без изменений в собственном коде. Поэтому в план проекта стоит закладывать не только разработку, но и период сопровождения.
В Codeking мы фиксируем состав каждого этапа и его результат ещё на старте проекта — это позволяет заказчику видеть прогресс не абстрактно, а по конкретным артефактам: прототип, дизайн-макеты, работающая сборка, отчёт тестирования, ссылка на приложение в сторе. Такой подход снимает главный источник недопонимания между заказчиком и разработчиком — ощущение, что процесс «непрозрачен», пока не готов финальный результат.