Разработка мобильных приложений: технологии, MVP и жизненный цикл
продукта

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

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

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

Границы первой версии: что действительно входит в MVP

MVP в разработке приложений — не урезанное приложение, а минимальный набор функций, который проверяет главную гипотезу продукта. Формулировка гипотезы напрямую задаёт объём работ. Если гипотеза звучит как «клиенты готовы заказывать повторно из телефона», в первую версию входят каталог, оформление заказа, оплата и статус выполнения, а программа лояльности, личный кабинет с историей и реферальная механика уходят во вторую.

• Функция, без которой основной сценарий не работает, идёт в первую версию без обсуждений.
• Функцию, которую на старте можно заменить ручной работой сотрудника, переносим во вторую итерацию.
• Функцию, требующую отдельной интеграции или юридической проверки, выносим отдельным этапом со своим сроком.
• Всё, что «пригодится потом», но не влияет на проверку гипотезы, отправляем в бэклог — не в первую версию.

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

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

С какой платформы начинать: iOS, Android или обе сразу

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

• iOS: логичный старт, когда основная аудитория пользуется устройствами Apple, а продукт предполагает платные подписки и покупки внутри приложения.
• Android: оправдан там, где важнее охват, а среди клиентов много пользователей недорогих устройств и разных версий системы.
• Обе платформы сразу: разумно, если спрос уже подтверждён на сайте или в другом канале и потеря времени дороже экономии бюджета.
• Если внутри iOS-контура платформа выбирается как основная, отдельный разбор есть у разработки приложений под iOS, для второй платформы — у разработки под Android.

Распределение аудитории проверяется дешевле, чем кажется: по статистике сайта, по долям устройств в рекламных кампаниях и по составу клиентской базы в CRM. Если данные показывают, что основная часть ваших клиентов на Android, начинать логично с Android, а iOS добавлять после того, как основной сценарий подтвердил спрос.

Стек разработки: что выбирают в 2026 году и чем за это платят

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

• Нативная разработка: Swift и SwiftUI для iOS, Kotlin и Jetpack Compose для Android. Максимальный доступ к системным возможностям и предсказуемая производительность, но две отдельные кодовые базы и, по сути, два проекта.
• Flutter: одна кодовая база для iOS и Android, собственный движок отрисовки интерфейса, единый внешний вид на обеих платформах.
• React Native: единая кодовая база на JavaScript или TypeScript, широкий набор готовых библиотек, часть логики можно переиспользовать с веб-проектом.
• Kotlin Multiplatform: общий код бизнес-логики и слоя данных для iOS и Android, при этом интерфейс может оставаться нативным; Compose Multiplatform позволяет делить между платформами и интерфейс.

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

Отдельный фактор выбора — требования платформ, которые обновляются каждый год. С 28 апреля 2026 года сборки в App Store Connect принимаются только из Xcode 26 или новее с SDK iOS 26, iPadOS 26, tvOS 26, visionOS 26 или watchOS 26. Google Play с 31 августа 2026 года требует от новых приложений и обновлений целевого уровня Android 16 (API 36), а от приложений, которые уже в магазине, — не ниже Android 15 (API 35), с возможностью продления до 1 ноября 2026 года.

Архитектура: клиент, сервер и офлайн-режим

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

• Разделение слоёв по схеме MVVM или Clean Architecture: интерфейс, бизнес-логика и работа с данными живут отдельно и меняются независимо.
• Обмен с сервером: REST или GraphQL, версионирование API, обработка ошибок, таймауты и повторные попытки запросов.
• Офлайн-режим: локальный кэш и очередь действий, которые уходят на сервер при появлении сети.
• Синхронизация и конфликты: заранее описанное правило, чья версия данных считается верной, если пользователь изменил одни и те же данные на двух устройствах.

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

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

Интеграции и платежи: где чаще всего растёт смета

Интеграции — вторая по объёму часть проекта после самого приложения. Именно они чаще всего превращают фиксированную стоимость в открытую, потому что зависят от чужих систем и чужих правил.

• Платежи внутри приложения: цифровые товары и подписки в iOS продаются через встроенные покупки — этого требует правило 3.1.1 App Review Guidelines, собственные механизмы разблокировки цифрового контента не допускаются. Для физических товаров и услуг правила иные, но платёжный провайдер должен работать на вашем рынке.
• Push-уведомления: Firebase Cloud Messaging работает и на Android, и на iOS, а одно сообщение может нести до 4096 байт данных. Содержательные сценарии строят на связке push и раздела внутри приложения, иначе уведомления быстро отключают.
• Внутренние системы: синхронизация с CRM, складом и учётной системой — самая частая причина переноса сроков. Здесь интеграция приложения с CRM проектируется до разработки и описывается схемой обмена данными, а не обсуждается по ходу.
• Системные возможности: карты и геолокация, камера, сканирование документов, биометрия. Каждая требует разрешения, объяснения пользователю и проверки на модерации.

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

Требования магазинов приложений в 2026 году

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

• App Store, SDK: с 28 апреля 2026 года приложения принимаются только собранными в Xcode 26 или новее с SDK актуальных версий систем Apple.
• App Store, приватность: обязательна разметка собираемых данных в карточке приложения, а сторонние SDK требуют подписи и манифеста приватности.
• App Store, возрастные рейтинги: с 31 января 2026 года действует обновлённая система рейтингов, ответы на новые вопросы нужно дать, иначе обновления приложения не примут.
• App Store, Евросоюз: без подтверждённого статуса торговца приложение недоступно в App Store на территории ЕС.

• Google Play, целевой API: с 31 августа 2026 года новые приложения и обновления должны быть нацелены на Android 16 (API 36).
• Google Play, формат публикации: Android App Bundle, при этом суммарный размер загружаемых пользователю APK не должен превышать 4 ГБ.
• Google Play, данные: обязательная форма Data safety о собираемых и передаваемых данных третьим сторонам.
• Google Play, личные аккаунты: аккаунтам, созданным после 13 ноября 2023 года, до выхода в продакшн нужен закрытый тест с минимум 12 тестировщиками, подключёнными 14 дней подряд.

Стоимость аккаунтов разработчика относится к подготовке проекта: членство в Apple Developer Program — 99 долларов в год, корпоративная программа Apple Developer Enterprise — 299 долларов в год, регистрация в Play Console — разовый платёж 25 долларов. Аккаунты оформляйте на компанию, а не на исполнителя: при смене подрядчика это снимает спор о правах на приложение и историю продаж.

Модерация: почему приложения отклоняют

Модерация проверяет не столько работоспособность, сколько соответствие правилам платформы. Большинство отклонений связано с политиками, а не с ошибками в коде.

• Серверные сервисы недоступны во время проверки: Apple прямо просит держать бэкенд включённым и доступным на время ревью.
• Использование непубличных API и функций, которые не работают на актуальной версии системы.
• Продажа цифрового контента вне встроенных покупок — прямое противоречие правилу 3.1.1.
• Описание функций, которых в приложении нет, и обещания, не подтверждённые интерфейсом.
• Отсутствие политики конфиденциальности, запрос разрешений без объяснения цели, сбор данных сверх заявленных.

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

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

Релизный цикл: как выпускать обновления без сюрпризов

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

• Внутренние сборки: закрытые каналы для проверки на сотрудниках до выхода на пользователей.
• Публичная бета: TestFlight приглашает до 10 000 внешних тестировщиков, в Google Play аналогичную роль играют открытые и закрытые тесты.
• Поэтапный выпуск: сначала доля пользователей, потом полная раскатка — это позволяет остановить обновление, если метрики падают.
• Мониторинг сбоев: отчёты о падениях и зависаниях с привязкой к версии приложения и модели устройства.
• Плановое обновление под новую версию системы: раз в год сборку нужно пересобирать и проверять на соответствие требованиям магазинов.

Отдельная практика — принудительное обновление через сервер. Если найден критичный дефект или изменён протокол обмена, приложение должно уметь потребовать обновление до версии, которая работает с новым API. Механизм версионирования закладывают в первую версию: добавить его задним числом можно только через ещё одну сборку в магазине, то есть через недели.

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

Метрики и ASO: как понять, что приложение работает

Приложение без метрик развивается вслепую. Минимальный набор данных, который нужен с первого дня: источники установок, активация (первое полезное действие), удержание на 1, 7 и 30 день, конверсия в оплату и частота сбоев.

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

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

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

Безопасность и данные

• Токены и ключи — только в защищённом хранилище платформы: Keychain на iOS, Keystore на Android.
• Весь трафик по HTTPS с проверкой сертификата; для критичных операций — дополнительные меры против подмены трафика.
• Политика хранения персональных данных и требования к их размещению зависят от юрисдикции клиентов и правил магазинов.
• Сборку стоит обфусцировать: приложение можно распаковать, и открытые ключи в коде — частая находка исследователей.
• На серверной стороне нужны обновления, резервные копии и контроль доступа — без них защита клиента обнуляется.

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

Технический долг: доработка или переписывание

Приложение стареет быстрее сайта: платформы меняют требования, библиотеки перестают поддерживаться, команда меняется. Развилка «доработать или переписать» решается по нескольким наблюдаемым признакам.

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

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

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

Что делать дальше

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

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

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

Обсудить технологии и стек вашего мобильного приложения