Выберите тему — соберём контекст
Разрабатываем мобильные приложения для iOS и Android — нативно на Swift и Kotlin или кроссплатформенно на Flutter и React Native. С единым API к вашей учётной системе, офлайн-режимом и push-уведомлениями. Первая версия — с фиксированным объёмом, сроком и публикацией в обоих сторах.
Состав функций определяет не мода, а сценарий: где сотрудник или клиент открывает телефон и что должен успеть сделать до того, как его позовут. Ниже — блоки, из которых собирается первая версия.
Swift и SwiftUI для iOS, Kotlin и Jetpack Compose для Android. Выбор оправдан, когда важны фоновая работа, виджеты, сложная работа с камерой и максимум производительности.
Одна кодовая база и предсказуемая отрисовка интерфейса на обеих платформах. Сильный вариант для бизнес-приложений с плотными списками, формами и офлайн-режимом.
Разумный выбор, если в команде уже есть JavaScript и веб-приложение на React: часть логики и типов переносится в мобильный клиент без переписывания.
Отдельные раскладки для больших экранов и сценарии для часов — там, где это действительно нужно процессу, а не «для галочки».
Приложение работает на том же бэкенде, что сайт и учётная система. Одни данные, одни правила, никакого ручного переноса между базами.
Мобильный клиент нельзя обновить мгновенно у всех пользователей: контракт версионируется, старые версии живут, пока ими пользуются.
Локальное хранилище, очередь операций и разрешение конфликтов — критично для склада, выездных мастеров и курьеров, где связь пропадает.
Фотофиксация, сканирование штрихкодов и QR, распознавание документов, подпись на экране и загрузка файлов при слабой связи.
Статусы заказов, задачи, напоминания и эскалации. Сценарии по событиям, а не общая рассылка «обо всём».
Виджеты на домашнем экране, шорткаты, быстрый ввод последней операции — то, что сокращает путь до частого сценария.
Биометрия, вход по коду, токены устройства. Меньше трения на входе — больше возвратов.
События, воронка установки, отчёт по сбоям. Видно, какие функции работают, а какие не используют.
Роли, доступы к данным и действиям, журнал операций сотрудников.
Баннеры, разделы, тексты и справочники меняются без выпуска новой версии в стор.
Очередь обращений, сбои по устройствам, ответы пользователям внутри приложения.
Данные из мобильного клиента попадают в отчётность вместе с остальными каналами.
Универсально «правильного» варианта нет: кроссплатформа почти всегда быстрее и дешевле, нативная разработка — точнее там, где нужен доступ к железу. Ниже честное сравнение, включая вариант «приложение не нужно».
Обычно самый быстрый путь к релизу сразу на iOS и Android.
Смысл появляется, когда веб-платформа уже живёт и её можно переиспользовать.
Выбираем осознанно: платить за нативность стоит только под конкретное требование.
Если сценарий закрывается веб-версией, мы так и скажем — приложение не нужно.
Приложение — только видимая часть. Остальное — API, серверная логика, админка и релизный контур. Именно эти слои решают, можно ли обновлять приложение без переписывания и переживёт ли оно рост данных.
Экраны, навигация, состояние, локальная база, очередь операций, темы, локализация.
Версионированный API, авторизация по токенам, пагинация, кэш ответов, повторные попытки при обрыве связи.
Бизнес-логика, права доступа, интеграции с 1С, ERP, CRM, платежами и сервисами доставки.
Управление контентом и пользователями, отчёты, журнал сбоев, метрики использования.
CI/CD, сборки под разные окружения, подписи, тестовые каналы, выкладка в стор и откат версии.
Приложение подключается к существующей CRM, ERP или 1С. Чаще всего добавляется мобильный слой API, а не вторая база данных: тогда заказы, остатки и справочники остаются в одном месте. Начинаем с аудита текущего API и честно говорим, что можно переиспользовать. Подробнее об обмене данными — в разделе интеграций.
Эти требования дешевле учесть до разработки, чем добавлять после релиза: они затрагивают схему данных, архитектуру и срок модерации.
Состав данных, согласия, сроки хранения, требования 152-ФЗ. Определяем до проектирования схемы: добавлять требования «потом» дороже.
Разграничение по ролям и филиалам, журнал действий сотрудников, блокировка утерянного устройства.
Что можно держать в локальной базе, что шифруется, что удаляется при выходе из аккаунта.
Шифрование канала, проверка сертификатов, запрет на отладочные сборки в продакшене.
Политики App Store и Google Play, назначение целей использования данных, требования к контенту и возрасту.
Регламент бэкапов серверной части и проверка восстановления, а не надежда на то, что «и так сработает».
Нужен разбор текущего приложения или API перед доработкой?
Технический аудитГраницы первой версии фиксируем в договоре. Всё, что не вошло, не исчезает — оно уходит в очередь следующих релизов.
Очередь формируется по данным использования, а не по предположениям.
Если сценарий закрывается мобильной версией сайта, скажем об этом прямо — и предложим mobile-first доработку сайта вместо приложения.
Ниже не абстрактные «риски вообще», а то, что мы видели на проектах. Для каждого — решение, которое закладывается до начала работ.
Серверная часть «потом» — и приложение приходится переписывать под реальные данные.
Контракт API проектируем до разработки интерфейсов и фиксируем в документации.
Обновление у пользователей происходит не мгновенно, старые версии ломаются о новый сервер.
Версии API и правила совместимости закладываем с первой версии.
Стор возвращает сборку, релиз сдвигается, а причина — требования к данным или описанию.
Требования площадок проверяем до отправки на ревью, а не после отказа.
Непонятно, на каком экране пользователи уходят и что падает на реальных устройствах.
События и отчёты о сбоях подключаем в первой версии.
Вставка офлайн-режима в готовое приложение — это переделка слоя данных.
Необходимость офлайна выясняем на этапе сценариев и, если он нужен, закладываем сразу.
Код, аккаунты сторов и сертификаты остаются у подрядчика — развитие тормозится.
Репозиторий, аккаунты разработчика и инфраструктура оформляются на вас с самого начала.
Кто пользователь, какие задачи решает в телефоне, что обязательно в первой версии.
Кроссплатформа или нативная разработка: решение с обоснованием, а не по привычке.
Модель данных, версионирование, авторизация, офлайн — до разработки экранов.
Фиксированный объём работ, стоимость и график — до первой строки кода.
Каждые 1–2 недели — работающая сборка в тестовом канале, а не отчёт о занятости.
Подготовка описаний и скриншотов, прохождение модерации, контролируемый выпуск.
Обновления под новые версии ОС, мониторинг сбоев, очередь функций по данным использования.
Это рамки, а не прайс: точная смета появляется после разбора сценариев и фиксируется в договоре. Ниже — три типовых объёма.
Совпадает по нижней границе с опубликованным пакетом SaaS-MVP.
Точная цена зависит от состояния API существующей системы.
Дороже кроссплатформы: интерфейс и логика пишутся дважды.
Опубликованный формат с фиксированной ценой — пакет SaaS-MVP, от 449 000 ₽ · поддержка и обновления после релиза считаются отдельно.
По умолчанию рассматриваем кроссплатформу — Flutter или React Native: одна команда, одна кодовая база, обе платформы с первого релиза. Нативная разработка на Swift и Kotlin оправдана, когда нужны сложная работа с камерой и железом, фоновые процессы, виджеты или максимальная плавность интерфейса. Выбор фиксируем на этапе проектирования с обоснованием, а не «как привыкли».
Ориентир для MVP — 8–12 недель до сборки, которую можно показывать пользователям. Приложение к существующей системе с офлайн-режимом — 12–20 недель, две нативные реализации — 16–24 недели. Срок зависит от объёма интеграций и требований безопасности; точную оценку даём после разбора сценариев и фиксируем в договоре.
Нижняя граница — от 449 000 ₽ за MVP одного ключевого сценария с публикацией в обоих сторах, что совпадает с опубликованным пакетом SaaS-MVP. Приложение к существующей учётной системе — от 690 000 ₽, две нативные реализации — от 1 200 000 ₽. Итоговая сумма зависит от состава первой версии и числа интеграций; смета фиксируется до начала работ.
Вам. Репозиторий, аккаунты разработчика в App Store и Google Play, сертификаты подписи, домен и инфраструктура оформляются на вас с самого начала. Поэтому проект можно развивать другой командой без переписывания и без потери доступа к релизам.
Обычно да, но не обязательно новый: чаще всего мы добавляем мобильный слой API к существующей системе — с версионированием, токенами и правами доступа. Если API уже есть, начинаем с его аудита и говорим честно, что можно использовать, а что придётся переделать.
Обычно несколько дней, но срок зависит от площадки, полноты описания и политик по работе с данными. Закладываем модерацию в план релиза и готовим материалы заранее, чтобы возврат сборки не стал сюрпризом. Требования площадок проверяем до отправки на ревью.
Если сценарий этого требует, проектируем офлайн-режим с самого начала: локальная база, очередь операций, синхронизация при появлении связи и правила разрешения конфликтов. Вставлять офлайн «потом» дорого — это переделка слоя данных, поэтому решение принимается на этапе сценариев, а не после релиза.
Шифрование канала, токены устройства, биометрия по необходимости, разграничение ролей, журнал действий сотрудников, правила хранения данных на устройстве и резервное копирование. Требования 152-ФЗ и отраслевых стандартов уточняем до разработки: они влияют на архитектуру и стоимость.
Поддержка — отдельный этап: обновления под новые версии iOS и Android, мониторинг сбоев, доработки по данным использования. Можно продолжать с нами по договору сопровождения либо своими силами: код, документация и доступы у вас.
Да, но начинаем с технического аудита: состояние кода, версии зависимостей, работа с API и офлайном, узкие места. По результатам говорим прямо — дорабатывать или переписывать отдельные части. Иногда дешевле доработать, и мы так и скажем.
Нужна общая услуга без мобильной специфики — смотрите разработку мобильных приложений в каталоге услуг, а сравнение технологий — в разделе React и Vue.
Расскажите, кто будет пользоваться приложением и какую задачу он решает в телефоне. Скажем, нужен ли вообще мобильный клиент, что войдёт в первую версию и сколько это займёт — до договора и без обязательств.
Опишите сценарий и пользователей — вернёмся с составом первой версии, сроком и стоимостью.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.