Мобильное приложение для iOS и Android — это не только экраны на телефоне: в проект входят серверная часть, база данных, админ-панель, интеграции с системами компании и аккаунты разработчика в двух магазинах. Работа идёт восемью этапами, от аналитики до поддержки после запуска. Смету определяют список функций, число интеграций и требования Apple и Google, а не количество экранов.
Коротко
Готовый продукт — это пять частей, и пользователь видит только одну из них. Остальные определяют, выдержит ли приложение нагрузку и сможет ли компания управлять им без разработчика.
| Часть продукта | Что делает | Кто с ней работает |
|---|---|---|
| Клиент на телефоне | Экраны, навигация, формы, поведение при плохой связи, обращения к серверу | Клиент или сотрудник |
| Бэкенд и API | Хранит данные, считает заказы, проверяет права доступа, связывает приложение с внешними сервисами | Системы компании |
| База данных | Пользователи, заказы, платежи, документы, история действий | Разработка и аналитика |
| Админ-панель | Каталог, цены, заказы, пользователи, рассылки, отчёты | Ваши сотрудники |
| Аккаунты в магазинах | Карточка приложения, релизы, статистика установок, выплаты | Владелец продукта |
Серверная часть — самый недооценённый пункт сметы: от неё зависят скорость, безопасность и связь с CRM. Как она устроена и какие методы API нужны приложению, разобрано в статье о бэкенде и API для мобильного приложения.
Выбор сводится к двум вариантам: писать два приложения отдельно — на Kotlin для Android и на Swift для iOS — или собрать обе версии из одной кодовой базы на Flutter, React Native либо Kotlin Multiplatform.
| Что сравниваем | Нативная разработка | Кроссплатформенная разработка |
|---|---|---|
| Кодовая база | Две отдельные | Одна общая плюс платформенный слой |
| Доступ к камере, датчикам и NFC | Прямой | Через готовый плагин или свой нативный модуль |
| Правки после запуска | Делаются дважды | Выходят сразу на обе платформы |
Если приложение работает в основном с экранами и данными, берут кроссплатформу; если оно постоянно обращается к камере, датчикам и модулям связи — нативную разработку. Полное сравнение с критериями выбора и разбором фреймворков — в статье «Нативная или кроссплатформенная разработка».
С какой платформы начинать, решают по устройствам платящих клиентов. По данным StatCounter за август 2026 года, на Android пришлось около 83 % просмотров веб-страниц с мобильных телефонов в Узбекистане, на iOS — около 17 %. Это доля трафика, а не число устройств, но перекос заметный: многим продуктам разумно выйти сначала на Android.
Проект идёт восемью этапами, и у каждого есть результат, который заказчик может проверить и принять.
Дизайн — отдельная работа со своими правилами: зоны касания, жесты, онбординг и запросы разрешений разобраны в статье про UX/UI-дизайн мобильного приложения.
Магазины требуют сборку под актуальные SDK, заполненные декларации о собираемых данных, возможность удалить аккаунт и функциональность сверх переупакованного сайта. Это часть технического задания, а не формальность в конце проекта: требования влияют на архитектуру, дизайн и смету.
Важно С 28 апреля 2026 года App Store Connect принимает сборки только из Xcode 26 с SDK iOS 26. С 31 августа 2026 года новые приложения и обновления в Google Play должны быть нацелены на Android 16 (API 36), а уже опубликованные — минимум на Android 15 (API 35), иначе их не увидят новые пользователи на более свежих версиях Android. Продлить срок можно по запросу до 1 ноября 2026 года.
Аккаунты разработчика, закрытое тестирование, сроки проверки и причины отказов разобраны в статье «Как опубликовать приложение в App Store и Google Play».
Чаще всего в первую версию входят вход по номеру телефона, каталог, заказ с онлайн-оплатой, личный кабинет и уведомления. Состав собирают из сценариев, а не из списка возможностей: каждая функция отвечает на вопрос, что человек делает в приложении и зачем в него возвращается.
Остальное откладывают во вторую версию. Чем меньше функций в первом релизе, тем раньше видно, пользуются приложением или скачали и забыли.
Приложение подключают к системам компании через API: данные ходят в обе стороны, и сотрудники продолжают работать в привычных программах.
Если систем несколько и они между собой не связаны, обмен данными настраивают до выхода в магазины. Иначе приложение станет ещё одним источником разрозненных данных, которые кто-то будет сводить вручную.
Стоимость складывается из объёма функций, числа интеграций, требований к данным и того, что у компании уже есть. Оценка получается точнее, когда исходные данные собраны заранее.
Разработка — только первый платёж. Дальше приложение живёт по правилам магазинов, и взносы одинаковы при любом подходе к разработке.
К взносам добавляются сервер и резервные копии, обновления под новые версии iOS и Android, правки после обратной связи и работа с отзывами в магазинах. Эти расходы закладывают в план на год вперёд, а не оплачивают по факту.
Приложение не нужно там, где клиент обращается к вам разово: он не станет ставить программу ради одной покупки. Оно оправдано, когда человек возвращается регулярно — заказывает еду, записывается, отслеживает доставку, пользуется бонусами.
Вторая проверка — установка. Приложение нужно найти, скачать, дать ему разрешения и не удалить через неделю. Для разовых задач — регистрация на мероприятие, запись, заявка, статус ремонта — дешевле сделать кабинет в Telegram или на сайте: там нет ни установки, ни взносов магазинов.
Бот для заявок и записи мы делаем от 1 200 $. Сравните этот вариант с приложением, прежде чем утверждать бюджет: часто он закрывает задачу целиком, а приложение становится следующим шагом.
Мы в Syntra Systems начинаем с аналитики и технического задания с критериями приёмки, а не со сборки экранов. Дальше проект ведёт одна команда: дизайн, клиентская часть, бэкенд, интеграции с CRM и платёжными системами, публикация в обоих магазинах и поддержка после запуска.
В портфеле есть мобильные продукты. Для QADAM мы сделали фирменный стиль, интерфейс и архитектуру приложения экспресс-доставки, а все состояния и цвета описали в интерактивном брендбуке на 14 разделов. Для КручуВерчу собрали дизайн-систему и более 30 экранов приложения доставки для iOS: витрину, конфигуратор блюда, корзину, оплату и трекинг курьера.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Да, так делают часто. Стартовую платформу выбирают по устройствам платящих клиентов: смотрят аналитику сайта, данные о заказах и отчёты рекламы. Вторую версию добавляют, когда первая подтвердила спрос.
Через API, в обе стороны: регистрация в приложении создаёт контакт в CRM, заявка — сделку, а остатки и цены приходят из учётной системы. Если систем несколько и они не связаны, обмен настраивают до выхода в магазины, иначе приложение станет ещё одним источником данных, которые сводят вручную.
На компанию-владельца продукта. Аккаунт определяет, кому принадлежит приложение, кто получает выплаты, видит статистику и может выпускать обновления. Если аккаунт оформлен на подрядчика, бизнес зависит от него в каждом релизе.
Приложение имеет смысл, когда клиент возвращается регулярно и вам нужны push-уведомления, работа при плохой связи или доступ к камере и геолокации. Для разовых обращений мобильной версии сайта обычно достаточно.
Взносы магазинов — 99 $ в год Apple и 25 $ один раз Google, плюс сервер с резервными копиями, обновления под новые версии iOS и Android и работа с отзывами. Обновления обязательны: с 31 августа 2026 года Google Play принимает новые версии только с целевым уровнем Android 16 (API 36).
Источники
