Разработка мобильных приложений: как подготовить проект

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

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

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

Что включает разработка мобильных приложений?

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

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

Для руководителя в проекте есть четыре части:

• Пользовательский сценарий. Кто выполняет действие, в каком контексте и какой результат получает.
• Мобильный клиент. Экраны, навигация, состояние, разрешения и функции устройства.
• Данные и сервисы. Что хранится локально, что приходит с сервера и что происходит при сбое связи.
• Выпуск и владение. Кто контролирует аккаунты магазинов, сборки, доступы, обновления и известные ограничения.

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

Когда бизнесу нужно отдельное мобильное приложение?

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

Решение запишите одной фразой: Пользователь открывает приложение в ситуации X, выполняет действие Y и получает результат Z. Затем перечислите функции устройства и состояния сети, без которых этот путь не работает.

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

Как выбрать iOS, Android или обе платформы?

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

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

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

Отдельный код или общая кодовая база?

Термины описывают границу разделения кода. Качество будущего продукта проверяют отдельно по согласованным сценариям. Код, написанный для конкретной платформы, дает прямую работу с ее средствами. Общая кодовая база позволяет делить часть интерфейса и логики, сохраняя отдельные модули там, где iOS и Android ведут себя по-разному.

Официальные обзоры Flutter, React Native и Kotlin Multiplatform показывают разные способы сочетать общий и платформенный код. Они не дают универсального процента повторного использования и не выбирают технологию за проект.

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

Что записать в требованиях до разработки?

Общая карта требований и приемки поможет подготовить цифровой проект. Для мобильного клиента добавьте состояния устройства и правила публикации.

Заполните карточку обычным языком:

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

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

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

Как проверить сценарий на прототипе?

Учебный материал Apple предлагает связать экраны в интерактивный прототип и использовать обратную связь для уточнения дизайна. Для бизнеса достаточно начать с одного основного сценария и одного исключения.

Попросите пользователя выполнить задачу без подсказок автора. Отмечайте вопросы и неверные действия. Объяснение интерфейса по ходу исказит проверку.

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

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

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

Из каких этапов состоит проект мобильного приложения?

Практический порядок этапов выглядит так:

1. Зафиксировать задачу и аудиторию. Описать основной сценарий и проверить, нужен ли ему отдельный мобильный формат.
2. Выбрать платформы. Использовать данные аудитории, функции устройства и ресурсы дальнейшей поддержки.
3. Собрать требования. Уточнить данные, разрешения, интеграции, работу без сети, доступность и приемку.
4. Проверить прототип. Пройти основной путь, ошибку и возврат к работе до полной реализации.
5. Разделить архитектуру. Определить интерфейс, бизнес-логику, данные на устройстве, серверные сервисы и платформенные модули.
6. Собирать проверяемые части. Каждая часть проходит согласованный сценарий на тестовых данных.
7. Проверить целевые устройства. Пройти установку, вход, основной путь, исключения, разрешения, сеть и обновление.
8. Подготовить публикацию. Заполнить метаданные, декларации данных, политику приватности и доступ для проверки магазина.
9. Проверить бета-версию. Выдать участникам конкретные задания, собрать отклонения и повторно проверить исправления.
10. Опубликовать и наблюдать. Контролировать состояние версии, сбои, отзывы и известные ограничения.
11. Поддерживать продукт. Обновлять зависимости, правила магазинов, документацию и карту данных.

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

Что предусмотреть для данных и слабой сети?

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

• Какие данные пользователь должен увидеть без сети?
• Разрешены ли действия без доступа к сети?
• Как интерфейс показывает, что данные могли устареть?
• Куда попадает действие до восстановления связи?
• Что происходит, если локальная и серверная версии конфликтуют?
• Как человек узнает, что синхронизация не завершилась?
• Какие данные запрещено хранить на устройстве?

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

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

Как проверить интерфейс на устройствах?

Рекомендации Android по тестированию разделяют проверки логики, интерфейса и поведения на устройствах или эмуляторах. Заказчику достаточно контролировать покрытие согласованных сценариев; инструментарий выбирает команда.

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

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

Как встроить безопасность и приватность?

OWASP MASVS группирует проверки мобильного клиента по хранению данных, криптографии, аутентификации и авторизации, сети, взаимодействию с платформой, качеству кода, устойчивости к вмешательству и приватности. Выберите релевантные группы MASVS и способы проверки по риску продукта.

Составьте карту данных:

Apple и Google Play требуют учитывать практики работы с данными, включая сторонние библиотеки и SDK, в декларациях приложения. Карта должна совпадать с фактическим поведением каждой выпускаемой версии.

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

Что подготовить для App Store и Google Play?

App Review Guidelines предлагают перед отправкой проверить приложение на сбои, убрать незавершенные материалы, подготовить метаданные и обеспечить проверяющей стороне доступ к функциям и работающим серверным сервисам. Требования меняются, поэтому перед каждой отправкой открывайте текущую версию правил.

Для Google Play сверьте фактический сбор и передачу данных с формой Data safety. Если приложение запрашивает чувствительные разрешения, проверьте действующие требования Play Console к декларациям. Не восстанавливайте эту информацию по памяти перед выпуском: реестр данных и SDK должен обновляться вместе с кодом.

Перед отправкой пройдите список:

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

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

Что контролировать после публикации?

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

Google Play staged rollout позволяет распространять обновление поэтапно, останавливать и продолжать выпуск. Этот механизм относится к обновлениям и не доказывает отсутствие ошибок. Firebase Release Monitoring показывает один из вариантов наблюдения за распространением версии и новыми сбоями; использовать именно этот сервис необязательно.

Назначьте владельцев по списку:

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

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

С чего начать подготовку проекта?

Первый документ можно собрать без технических терминов:

1. Кто выполняет действие и где находится в этот момент.
2. Какую задачу он должен закончить.
3. Какие данные нужны на входе и что появляется на выходе.
4. Какие функции телефона действительно участвуют.
5. Что происходит при отказе в разрешении, слабой сети и неверных данных.
6. Как человек поймет, что действие завершено.
7. Кто проверит сценарий и примет решение по расхождению.

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

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