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

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

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

Проект приложения для iOS и Android мы обычно рассматриваем по таким направлениям:

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

Приложение или веб-приложение?

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

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

Для каких компаний это имеет смысл?

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

Выбор технического подхода для приложения iOS и Android

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

Нативная разработка

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

Кросс-платформенная разработка

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

Что определяет решение?

Выбирая подход в проекте приложения для iOS и Android, мы смотрим на такие вопросы:

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

Производительность и доступность

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

Наш процесс разработки мобильных приложений

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

1. Ознакомительная встреча: обсуждаем вашу бизнес-цель, ваших пользователей и главную проблему, которую должно решать приложение.
2. Документ об объеме работ: фиксируем письменно список функций первой версии, роли пользователей и интеграции.
3. Сценарии и прототип: рисуем переходы между экранами и проверяем их на кликабельном прототипе.
4. Дизайн интерфейса: адаптируем визуальный язык вашего бренда под привычки двух платформ.
5. Циклы разработки: делим работу на короткие циклы и в конце каждого цикла передаем вам тестовую версию.
6. Тестирование: проверяем на разных размерах экранов, версиях операционных систем и условиях соединения.
7. Публикация в магазинах: готовим страницы в магазинах, отправляем приложение на проверку и обрабатываем полученные замечания.

Что входит в документ об объеме работ?

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

Почему важен прототип?

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

Дизайн с учетом различий платформ

У пользователей iPhone и Android разные привычки: жест возврата, расположение меню, выбор даты и экран «поделиться» работают на двух платформах по-разному. В дизайне приложения для iOS и Android мы сохраняем общий язык бренда, а такие вопросы поведения оставляем в шаблонах каждой платформы. Так пользователь при первом запуске приложения не чувствует себя чужим.

Держать первую версию небольшой

Хорошая первая версия это приложение, которое не делает все, а очень хорошо решает одну задачу. Мы советуем разделить объем на «первую версию» и «следующие версии». Тогда приложение раньше попадет к пользователю, а последующие функции будут формироваться не по догадкам, а по данным реального использования.

Первый запуск и запросы разрешений

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

Передача вам тестовых версий

В ходе разработки мы делимся тестовыми версиями через TestFlight на iOS и через каналы тестирования Google Play на Android. Вы и ваша команда устанавливаете приложение на свои телефоны, пробуете в реальных условиях использования и присылаете замечания. Эти замечания попадают в список приоритетов следующего цикла разработки.

Серверная часть, панель управления и интеграции

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

• Управление пользователями: регистрация, вход, сброс пароля и удаление аккаунта.
• Панель управления: веб-панель, в которой ваша команда может обновлять контент, товары, заказы или записи, не трогая приложение.
• Уведомления: мгновенные уведомления, отправляемые через Apple Push Notification service на iOS и Firebase Cloud Messaging на Android.
• Аналитика: измерения, которые показывают, какими экранами пользуются и на каком шаге пользователи уходят.
• Отслеживание ошибок: отчеты, которые сообщают, на каком устройстве и на каком шаге произошел сбой приложения.

Чаще всего ваше приложение работает не само по себе; ему нужно обмениваться данными с платформой интернет-магазина, ERP или бухгалтерским ПО, CRM или платежной организацией. Эти подключения мы планируем в части API и интеграций систем. Есть ли у ваших текущих систем API, это один из первых вопросов, определяющих объем разработки мобильных приложений.

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

Процесс публикации в магазинах и после нее

Готовность приложения не означает, что оно опубликовано в магазине. Apple и Google проверяют каждое приложение и каждое обновление по своим правилам. В проекте приложения для iOS и Android мы включаем подготовку к магазинам в план с самого начала, а не оставляем ее на конец разработки.

Аккаунты разработчика

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

Правила проверки

В правилах проверки App Store Apple перечислены условия, которым должно соответствовать приложение, по разделам: безопасность, производительность, бизнес-модель, дизайн и соблюдение закона. В Google публикацией, версиями, каналами тестирования и уведомлениями о политике управляют через Google Play Console. Среди частых причин отказа: неполный контент, неработающие ссылки, отсутствие демо-аккаунта для проверяющей команды и неполные сведения о конфиденциальности.

Конфиденциальность, KVKK и разрешения пользователей

Оба магазина требуют ссылку на политику конфиденциальности и декларацию о том, какие данные собирает приложение: в App Store это ярлыки конфиденциальности, в Google Play раздел о безопасности данных. Если в приложении можно создать аккаунт, ожидается, что его можно и удалить из самого приложения. Для пользователей из Турции отдельно нужно подготовить текст информирования в рамках закона Турции № 6698 о защите персональных данных (KVKK) и при необходимости шаги получения явного согласия; окончательный вид этих текстов мы советуем определить вместе с вашим юристом.

Платежи внутри приложения

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

Страница в магазине и видимость

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

Сопровождение после публикации

Разработка мобильных приложений не заканчивается публикацией. Apple и Google регулярно выпускают новые версии операционных систем; Google Play требует, чтобы в течение определенного срока приложения ориентировались на актуальный уровень Android API. Обновления библиотек, патчи безопасности и отзывы пользователей требуют постоянного внимания. Эти задачи мы можем взять на себя в рамках услуги обслуживание и техническая поддержка.

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

От чего зависит объем работ при разработке мобильных приложений

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

• Число экранов и роли пользователей (например, клиент, курьер, администратор).
• Специальные модули: оплата, карта, камера, чат, календарь.
• Число подключаемых систем и наличие у них готового API.
• Требования к работе без интернета, нескольким языкам и доступности.
• Объем панели управления и потребность в отчетности.
• Ожидания по сопровождению после публикации и разработке новых функций.

Что вам нужно подготовить

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

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

На что смотреть при сравнении предложений?

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

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

Частые ошибки

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

Как мы измеряем успех?

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

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

Сколько занимает разработка мобильных приложений?

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

Можно ли одним приложением для iOS и Android выйти сразу в двух магазинах?

Да. С кросс-платформенным фреймворком из одной кодовой базы можно собирать версии и для App Store, и для Google Play. Если приложению сильно нужны функции устройства, мы рассматриваем и нативную разработку.

Кому принадлежат исходный код приложения и аккаунты в магазинах?

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

Может ли приложение использовать те же данные, что и мой существующий сайт?

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

Что будет, если магазин отклонит приложение?

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

Кто делает обновления после разработки мобильных приложений?

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

Давайте вместе уточним вашу идею приложения

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