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

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

Главное

Лучшее первое приложение — небольшое: MVP, который хорошо решает одну проблему; обычно его делают кроссплатформенным, а если вы нужны клиентам лишь изредка — хватит сайта или PWA. Закладывайте приватность и требования магазинов приложений с самого начала, публикуйте приложение в собственных аккаунтах разработчика, чтобы код и данные оставались вашими, и предусмотрите бюджет на поддержку после запуска.

С чего начать: проблема, MVP и прототип

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

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

Затем определите MVP (minimum viable product, минимально жизнеспособный продукт) — самую маленькую версию, которая решает основную проблему достаточно хорошо, чтобы ею пользовались реальные люди. Опишите один-два ключевых сценария, например «регистрация → каталог → заказ → оплата → уведомление», а всё остальное перенесите в список «на потом». MVP — это не наполовину сломанное приложение, а продукт, отполированный в узких рамках.

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

Нативное, кроссплатформенное или веб-приложение?

Для большинства бизнес-приложений разумный вариант по умолчанию — кроссплатформенная разработка; нативная оправдана для сложной графики, работы с камерой или звуком, а веб-приложения или PWA часто достаточно, если клиенты обращаются к вам лишь изредка. Три варианта сравниваются так:

Нативное: отдельное приложение для каждой платформы — на Swift для iOS и на Kotlin для Android. Максимальный доступ к возможностям устройства, но две кодовые базы, которые нужно поддерживать.
Кроссплатформенное: фреймворки вроде Flutter или React Native делят большую часть кода между iOS и Android; в документации Flutter (на английском) цель сформулирована как создание «мультиплатформенных приложений из единой кодовой базы». Для типичных бизнес-приложений (заказы, бронирования, программы лояльности, каталоги, внутренние инструменты) это разумный вариант по умолчанию. Сложная графика, продвинутая работа с камерой или звуком либо зависимость от самых новых возможностей платформ могут склонить чашу весов обратно к нативной разработке.
Веб-приложение или PWA: прогрессивное веб-приложение работает в браузере, его можно добавить на главный экран, и оно не проходит модерацию в магазинах. Этого часто достаточно, если клиенты обращаются к вам лишь изредка или если вы ещё проверяете идею. Если ваши клиенты живут в Telegram, похожую роль могут сыграть мини-приложения Telegram (на английском) — интерфейсы на JavaScript, которые запускаются прямо внутри мессенджера. Компромиссы: нет присутствия в магазинах приложений, сложнее интеграция с устройством и более ограниченная поддержка PWA на iOS.

Быстрая проверка: нужны ли вы пользователям каждую неделю или несколько раз в год? Нужны ли push-уведомления, работа без интернета или геолокация в фоне? Важно ли для доверия присутствие в магазинах приложений? Если на большинство этих вопросов ответ «нет», лучшим первым шагом может стать быстрый, ориентированный на телефон сайт или PWA. На чём его сделать, разбирает наше сравнение Wix, WordPress или самописный сайт.

Бэкенд, админ-панель и API

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

Бэкенд: серверы и база данных для аккаунтов, заказов, контента и уведомлений. Управляемые сервисы вроде Firebase могут ускорить MVP; собственный бэкенд даёт больше контроля над данными, интеграциями и текущими расходами по мере роста.
Админ-панель: веб-интерфейс, в котором ваша команда каждый день управляет товарами, заказами, пользователями и уведомлениями. Админ-панель легко упустить из плана, поэтому определите её заранее, вместе с ролями и правами: кто видит данные клиентов, кто может оформлять возвраты.
API и интеграции: платежи, карты, доставка, сообщения и системы, которые у вас уже работают, — интернет-магазин, ERP, CRM или бухгалтерская программа. Каждая интеграция зависит от документации другой стороны, одобрения доступа и ограничений, поэтому проверьте их до того, как утверждать план. Если ERP или CRM ещё только предстоит выбрать, сравнение CRM и ERP на заказ и готовых SaaS-систем поможет решить, что разрабатывать, а что купить.

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

Приватность и защита данных

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

Собирайте только необходимое. Каждое поле формы и каждое разрешение (геолокация, контакты, камера) должно соответствовать функции, которую вы можете объяснить.
Знайте, какие законы применяются. Если у вас есть пользователи в ЕС, применяется GDPR. В руководстве по защите данных для малого бизнеса (на английском) Европейского совета по защите данных подтверждается, что это касается и организаций за пределами Европейской экономической зоны, если их товары или услуги предлагаются людям внутри неё. GDPR требует правового основания для каждого использования данных, понятного информирования, соблюдения прав пользователей и договоров с провайдерами, которые обрабатывают данные по вашему поручению. Во многих других странах и в ряде штатов США действуют собственные законы о персональных данных.
Спрашивайте согласие перед отслеживанием. В ЕС аналитические и рекламные SDK, которые не являются строго необходимыми, как правило, требуют предварительного согласия, и вы отвечаете за то, что собирают сторонние SDK. На iOS для отслеживания людей в приложениях и на сайтах других компаний нужно разрешение App Tracking Transparency от Apple.
Декларируйте это в магазинах. Apple запрашивает сведения о конфиденциальности приложения (App Privacy), а Google Play — раздел «Безопасность данных». Оба требуют политику конфиденциальности, а ваши декларации должны соответствовать тому, что приложение делает на самом деле.
Дайте людям удалить аккаунт. Согласно пункту 5.1.1 правил проверки App Store (на английском), если приложение поддерживает создание аккаунта, оно должно также позволять удалить аккаунт внутри приложения. Требования Google Play к удалению аккаунтов добавляют веб-ссылку, по которой люди могут запросить удаление аккаунта и данных вне приложения.

Тестирование, модерация и собственные аккаунты разработчика

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

Тестирование. Используйте реальные устройства: старые и новые телефоны, маленькие и большие экраны, все поддерживаемые версии систем. Затем проведите бета-тестирование через TestFlight от Apple и тестовые треки Google Play. Согласно требованиям Google Play к тестированию, владельцы личных аккаунтов разработчика, созданных после 13 ноября 2023 года, должны провести закрытое тестирование, в котором не менее 12 тестировщиков участвуют не менее 14 дней подряд, и только после этого подавать заявку на доступ к рабочей версии; правило касается только личных аккаунтов.

Модерация. Apple проверяет приложения по своим правилам проверки App Store (на английском), Google — по правилам программы для разработчиков. В пункте 4.2 правил Apple сказано, что приложение должно содержать функции, контент и интерфейс, которые поднимают его выше «переупакованного сайта». Частые камни преткновения: сбои, неполные карточки, отсутствие сведений о конфиденциальности, нет удаления аккаунта, нет демо-доступа для проверяющего и приложения, которые представляют собой лишь сайт в обёртке. Заложите в график время на отклонение и повторную отправку.

Собственные аккаунты. Публикуйте приложение в аккаунтах разработчика вашей компании, а не вашего подрядчика. Программа Apple Developer Program платная с ежегодным взносом, Google Play Console — с разовым регистрационным взносом; для аккаунтов организаций в обоих случаях нужен номер D-U-N-S и проверка личности, поэтому начинайте заранее. Домен, хостинг, репозиторий кода и ключи подписи тоже оформляйте на себя.

Что влияет на стоимость и сроки — до и после запуска

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

Платформы и роли: iOS, Android, веб и админ-панель — каждое добавляет работу; приложение для клиентов, приложение для сотрудников и админ-панель — это три продукта, а не один.
Сложность функций: чат в реальном времени, отслеживание местоположения в реальном времени, видео, офлайн-синхронизация и правила бронирования — среди самых трудоёмких функций.
Интеграции: каждая внешняя система добавляет работу, особенно старые системы без хороших API.
Амбиции в дизайне: стандартные компоненты делаются быстрее, чем уникальная графика и анимация.
Языки, рынки и соответствие требованиям: переводы, местные способы оплаты, перенос данных, строгие требования к безопасности.
Ваша сторона: как быстро принимаются решения и готовы ли вовремя тексты, изображения и данные о товарах.

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

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

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

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

Затем спросите команду разработчиков: как вы разобьёте работу на этапы? Кому принадлежат код, макеты и аккаунты? Как обрабатываются изменения объёма работ? Как будет выглядеть поддержка?

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

Какое приложение делать: нативное или кроссплатформенное?

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

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

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

Нужны ли собственные аккаунты разработчика Apple и Google?

Да, это настоятельно рекомендуется. С собственными аккаунтами вы контролируете карточку приложения, отзывы и обновления и можете сменить команду разработчиков, не перенося приложение. Apple берёт ежегодный взнос, Google Play — разовый регистрационный; для аккаунтов организаций нужен номер D-U-N-S.

UsualMatrix проектирует и разрабатывает приложения для iOS и Android вместе с бэкендом и админ-панелью для клиентов по всему миру; мы общаемся на китайском, испанском или английском языке. Посмотрите нашу услугу разработки приложений и ПО или напишите нам, чтобы обсудить вашу идею.

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