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

Кроссплатформенная разработка — одно приложение на Flutter или React Native, которое работает и на iOS, и на Android. Код пишется один раз, поэтому первый релиз выходит быстрее, а каждая доработка стоит меньше: её не нужно повторять для второй платформы. Для большинства бизнес-приложений этого достаточно — личные кабинеты, каталоги и заказы, запись на услуги, программы лояльности, приложения для сотрудников.

Нативная разработка — отдельные приложения на Swift для iOS и на Kotlin для Android. Она оправдана, когда продукт глубоко работает с устройством: сложная съёмка и обработка видео, Bluetooth-оборудование, долгие фоновые процессы, дополненная реальность, тяжёлая графика. Ещё один довод — если у вас уже есть отдельные iOS- и Android-команды и приложение нужно встроить в их процессы.

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

Подход выбираем на мини-проектировании по вашим сценариям, а не по привычке команды. В мини-проекте объясняем выбор: что он даёт сейчас и чем обернётся через год развития продукта.

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

• API и бизнес-логика. Проектируем так, чтобы тот же сервер мог обслуживать и приложение, и веб-кабинет, и внешних партнёров.
• Админ-панель. Ваши сотрудники сами меняют контент, цены, акции и статусы заказов, а не пишут задачи разработчикам.
• Интеграции. Подключаем CRM, 1С, платёжные сервисы, службы доставки, карты и телефонию. Если у системы нет готового API, предлагаем способ обмена и согласуем его с вашими ИТ-специалистами.
• Данные пользователей. Персональные данные храним на серверах в России, как требует 152-ФЗ, а доступ сотрудников к ним разграничиваем по ролям.

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

Push-уведомления возвращают пользователя в приложение, но легко превращаются в спам. Разделяем сервисные сообщения — статус заказа, напоминание о записи, смена пароля — и маркетинговые рассылки, которые идут по сегментам аудитории. Разрешение на уведомления запрашиваем в момент, когда пользователь понимает, зачем они ему, а не на первом экране.

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

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

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

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

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

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

Готовим материалы для модерации заранее и отвечаем на замечания модераторов сами. RuStore добавляем для аудитории в России — особенно когда пользователям важно установить приложение из российского магазина. Обновления тоже проходят проверку, поэтому дату релиза планируем с запасом и не привязываем к ней запуск рекламы вплотную.

Мобильному продукту часто нужна веб-версия. Клиенты открывают личный кабинет с компьютера, сотрудники работают во внутреннем веб-приложении, а у продукта есть сайт, с которого приходят установки. Эту часть делаем на той же серверной основе, что и приложение, — данные и логика не дублируются.

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

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

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

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