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

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

1. Решите, нужно ли вообще делать приложение

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

Признак в вашем продукте	О чём он говорит
Им пользуются раз в неделю или чаще	Приложение
Нужны камера, GPS в фоне, Bluetooth, NFC или биометрия	Приложение
Оно должно работать без связи или при плохой связи	Приложение
Своевременные push-уведомления — часть ценности, а не маркетинг	Приложение
Находят через поиск, заходят один раз, в основном читают	Мобильный сайт
Вы ещё проверяете, нужно ли это кому-нибудь	Мобильный сайт или бот

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

Что входит в первую версию

Назовите один цикл, который пользователь повторяет снова и снова — заказать и отследить, записать и просмотреть, запросить и согласовать, — и сделайте этот цикл от начала до конца.

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

2. Выберите технический подход

	Кроссплатформенная (Flutter, React Native)	Нативная (Swift, Kotlin)
Кому подходит	Большинству бизнес- и потребительских приложений	Графике, длительной работе с оборудованием
Кодовая база	Одна общая плюс небольшие нативные части	Две, развивающиеся отдельно
Новые возможности платформ	Ждёте поддержки в плагине	Доступны в день выхода
Команда	Одна мобильная команда	Два набора компетенций: нанимать и удерживать

Кроссплатформенная разработка не зря стала выбором по умолчанию: две кодовые базы означают двойное исправление каждой ошибки и два набора регрессий. Flutter рисует интерфейс сам, что даёт одинаковый, выстроенный вокруг дизайна продукт на обеих платформах; React Native уместнее, когда команда уже живёт в React и TypeScript. Наше собственное приложение по питанию EatWise работает на одной кодовой базе Flutter под iOS и Android, с приложением-компаньоном для Wear OS.

Уходите в нативную разработку, когда этого требует конкретное названное ограничение: графика реального времени или AR, непрерывная обработка видео или звука, серьёзная фоновая работа, приложение, весь смысл которого — в аппаратной возможности устройства. Частый компромисс — кроссплатформенное приложение с одним нативным модулем, который делает самую сложную часть. Варианты мы сравниваем в статье Flutter или нативная разработка под Android, и это первое, что мы фиксируем в любом проекте мобильной разработки.

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

3. Проектируйте под две платформы и три языка

Пользователь сравнивает ваше приложение не с конкурентом, а с операционной системой, в которой он живёт весь день. Уважайте жест «назад» на Android и свайп от края экрана на iOS, используйте системное меню «Поделиться» и системные выборы даты. Хороший UI/UX-дизайн — это одна дизайн-система с двумя наборами платформенных поведений, а не один макет, выгруженный дважды.

Локализация — инженерное решение, а не перевод в самом конце:

• Русские строки часто длиннее английских, которые они заменяют, и первыми ломаются кнопки фиксированной высоты. Проверяйте каждый экран самой длинной строкой.
• В русском несколько форм множественного числа, поэтому код вида count + " товаров" будет ошибаться. Используйте правила плюрализации платформы с самого начала.
• Узбекский пишется и латиницей, и кириллицей. Решите, что именно вы выпускаете, и относитесь ко второму варианту как к отдельному набору ресурсов, а не к автозамене.
• Никогда не зашивайте текст в картинки и храните выбранный язык на стороне аккаунта, чтобы при входе с нового телефона он сохранялся.

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

4. Заложите то, что потом дорого менять

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

5. Спланируйте интеграции с длинными сроками

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

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

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

Push-уведомления. Для iOS нужен ключ APNs, Android использует FCM, а часть устройств, которые продаются в регионе, поставляются без сервисов Google Play. Относитесь к push как к доставке «по возможности» и дублируйте всё критичное внутри приложения.

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

6. Тестируйте на устройствах, которые реально есть у пользователей

Эмуляторы скрывают ровно те две вещи, которые ломают настоящие приложения: медленное железо и плохую сеть. Тестируйте на недорогом Android-устройстве и на самой старой версии ОС, которую вы заявляете как поддерживаемую, а затем намеренно ломайте связь: искусственно замедляйте её, переключайтесь с Wi-Fi на мобильный интернет посреди загрузки файла и включайте авиарежим во время оплаты.

Автоматизируйте выборочно. Юнит-тесты на бизнес-правила окупаются сразу, и несколько сквозных тестов на основной цикл стоит поддерживать; большой набор тестов медленный, нестабильный и через несколько месяцев тихо отключается. Раздавайте ранние сборки через TestFlight и тестовые треки Google Play, чтобы непонятные экраны первыми нашли живые пользователи.

7. Публикуйтесь в магазинах приложений без сюрпризов

• Заводите аккаунты заранее. Аккаунты разработчика Apple и Google требуют верификации, и это ожидание вы не контролируете.
• Дайте ревьюеру рабочий демодоступ. Если для входа нужен SMS-код на местный номер, ревьюер не войдёт — и вы получите отказ именно из-за этого.
• Закройте типовые требования Apple. Если пользователь может создать аккаунт, вы обязаны дать возможность удалить его в приложении. Запросы разрешений должны объяснять, зачем вам доступ, декларация приватности должна совпадать с тем, что вы реально собираете, а приложение, которое просто оборачивает ваш сайт, отклонят как слишком пустое.
• Закройте типовые требования Google. Заполните декларацию безопасности данных и собирайте под актуальный уровень API. Проверьте текущие правила для новых аккаунтов разработчика — они могут требовать сначала закрытого тестирования; политики магазинов меняются, поэтому сверяйтесь на момент подачи.
• Берегите ключи подписи. Используйте Play App Signing; потеря ключа загрузки без него может оставить вас без возможности обновлять собственное приложение.
• Раскатывайте поэтапно и следите за долей сессий без сбоев, прежде чем расширять аудиторию.

8. Планируйте год после запуска

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

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

Вопросы, которые стоит задать любому подрядчику

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

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

Итог

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