Выбор платформы
Выбираем нативную разработку, кроссплатформенный подход или PWA по доступу к функциям устройства, требованиям к офлайн-работе, сроку жизни продукта, составу команды и необходимости публикации в магазинах.
Услуги
Мобильные приложения для работы в поле и клиентских сервисов
Разрабатываем мобильные клиенты для сценариев с офлайн-работой, камерой, push-уведомлениями, геолокацией и работой в поле. С первого этапа учитываем сборки, подписи, модерацию в App Store и Google Play и канал обновлений. Аккаунты магазинов остаются у заказчика.
Кому подходит
- Сервисы с полевыми сотрудниками: логистика, сервис, инспекции, торговые представители
- B2B-продукты, которым нужен мобильный интерфейс к существующему кабинету и API
- Команды, которым требуется отдельный мобильный канал с публикацией в магазинах приложений
Что делаем
Клиент к вашему API
Авторизация, обновление токена, кэш, очередь отправки, повтор при обрыве. Полевые приложения чаще всего ломаются не на «красивом списке», а на плохой сети и повторной отправке одной и той же заявки.
Офлайн и устройство
Камера, файлы, геолокация, фоновые задачи. Закладываем, что делать, если нет сети в момент действия: очередь, конфликт, пометка «не доставлено». Без этого полевой сценарий нельзя принимать.
Релизы и магазины приложений
Apple: App Store Connect, TestFlight, второй фактор, соглашения. Google: Play Console, внутренние и закрытые дорожки, подпись. Ревью Apple в спокойном случае часто занимает около суток-двух, но это не SLA: отказ по гайдлайну сдвигает дату.
Сопровождение после релиза
Сопровождение может включать анализ сбоев, совместимость с новыми версиями iOS и Android и небольшие исправления. Смена технологической платформы оценивается как отдельный проект.
PWA только по ограничениям
PWA подходит, если основной сценарий работает в браузере, строгий офлайн-режим не требуется, а магазин приложений не является обязательным каналом. На iOS push-уведомления доступны установленным веб-приложениям, добавленным на домашний экран.
Состав работ
- Список сценариев: онлайн, офлайн, роли, устройства, минимальная OS
- Контракт с серверным API до середины разработки: ошибки, пагинация, загрузка файлов
- Клиент критического пути на согласованном стеке
- Внутренние сборки: TestFlight и внутренняя дорожка Play
- Чеклист стора: иконки, скриншоты, политика конфиденциальности, возрастной рейтинг
- Канал обновлений: кто принимает, как откатываем, что делаем при отказе ревью
- Аккаунты, сертификаты и регламент релиза принадлежат заказчику
Как связаны части решения
Базовый технический контур направления. Конкретные границы, интеграции и способ размещения фиксируем после разбора задачи.
01Клиенты
- iOS
- Android
- Работа в поле
02На устройстве
- Локальное состояние
- Очередь изменений
- Синхронизация
03Сервисы
- API
- Push
- Сторы и подписи
Стек
SwiftKotlinReact NativeTypeScriptREST / OpenAPICI для сборокTestFlightPlay Console
Этапы
01
Сценарии и ограничения
1–2 недели
Офлайн, роли, устройства, сторы, минимальная OS, кто публикует. Фиксируем, почему это не адаптивный сайт.
Приёмка: Список сценариев первого релиза и выбранный стек.
02
Клиент и контракт API
6–10 недель
Критический путь, авторизация, ошибки сети, очередь. Договорённость с бэкендом до середины, не в конце.
Приёмка: Внутренняя сборка, которой можно пройти сценарий на устройстве.
03
Сторы и ревью
1–3 недели плюс очередь стора
Метаданные, политика, тестовые доступы для ревьюера, закрытые дорожки. Срок ревью не принадлежит команде.
Приёмка: Приложение в TestFlight / внутренней дорожке, заявка в стор подана.
04
Канал обновлений
входит в сдачу
Фиксируем порядок выпуска исправлений, ответственных за приёмку, действия при отказе магазина и канал получения отчётов о сбоях.
Приёмка: Регламент релиза и доступы у заказчика.
Нормы и ограничения
App Store Review Guidelines и политика Google Play
Аккаунт, политика, права на контент, фоновые режимы, платежи внутри приложения. Нарушение гайдлайна это не «придирка дизайнера», а типичная причина сдвига релиза.
Аккаунты и подписи у заказчика
Аккаунт разработчика и права публикации должны принадлежать заказчику, чтобы выпуск обновлений не зависел от подрядчика.
Контракт API раньше красивых экранов
Сервер должен безопасно обрабатывать повторные запросы и возвращать понятные ошибки. Иначе мобильный клиент может показывать неверный статус при нестабильной сети.
Крэш-отчёты с первого релиза
Для выпуска настраиваем символы отладки и сбор отчётов о сбоях. Критерии готовности полевого приложения включают возможность диагностировать ошибки рабочей версии.
Сроки
Клиент к готовому API для одной платформы или на React Native обычно занимает 10–16 недель до первой внутренней сборки. Срок модерации магазина учитывается отдельно. Два полнофункциональных нативных клиента оцениваются как отдельные приложения.
Срок растёт, если:
- Нет стабильного API или он меняется каждую неделю
- Жёсткий офлайн, конфликты правок, работа в фоне
- Свои карты, сложная камера, BLE, платежи внутри стора
- Парк старых устройств и отдельная версия под каждую OS
Не входит
- Игры, AR и тяжёлая компьютерная графика
- Публикация из аккаунта студии: аккаунт разработчика должен быть оформлен на заказчика до первого релиза
- Гарантия прохождения ревью в фиксированную дату
- Отдельное маркетинговое ASO и закупка установок
Результат
Результат: приложение во внутреннем каталоге или магазине, регламент выпуска версий и документированный контракт с серверным API. Подписи и аккаунты принадлежат заказчику.
Вопросы направления
Всегда ли нужны два нативных приложения?+
Нет. Если основная логика находится в API, React Native позволяет одной команде поддерживать обе платформы. Нативная разработка оправдана сложной работой с устройством, строгими требованиями к интерфейсу платформы или другими техническими ограничениями.
Можно ли начать с PWA?+
Да, если магазин приложений, расширенная офлайн-работа и функции устройства не обязательны. Возможности PWA на iOS отличаются от нативного приложения, поэтому выбор проверяем по конкретному сценарию.
Кто публикует в сторы?+
Первый релиз проводим совместно. Аккаунт разработчика, данные юридического лица и платёжные реквизиты магазина принадлежат заказчику.
Почему стор может отказать?+
Частые причины: нет политики, логин не проверить, скрытые платежи, слишком широкие права, «сырой» контент, копирование чужого бренда. Это пункты гайдлайнов, не вкус модератора.
Сколько стоит сопровождение после релиза?+
Сопровождение работает по отдельному регламенту: анализ сбоев, небольшие исправления и обновление SDK под новые версии ОС. Крупные функции оцениваются отдельными этапами.
Нужен ли отдельный бэкенд?+
Если серверной части ещё нет, потребуется API для авторизации, файлов, данных и фоновых операций. Его надёжность входит в критерии приёмки мобильного сценария.
Следующий шаг
Обсудить задачу
Опишите задачу, срок и ограничения. Ответим в рабочий день: берёмся ли и каким будет первый этап.