Как создать мобильное приложение: 4 способа, пошаговый план и бюджет

Рынок мобильных приложений в России продолжает расти. По данным RB.ru, в июле 2026 года месячная аудитория RuStore достигла 68,4 млн пользователей, а выручка магазина за первое полугодие выросла в 2,3 раза к прошлому году. iXBT со ссылкой на Mediascope добавляет: число разработчиков с опубликованными приложениями за полгода удвоилось и дошло до 30 тысяч, а в каталоге уже больше 110 тысяч приложений и игр. Конкуренция за внимание пользователя растёт, и вопрос «как создать мобильное приложение» бизнес задаёт всё чаще и всё раньше.

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

Ниже сравним четыре способа по деньгам, срокам и рискам, дадим план из 8 шагов, ориентиры бюджета и требования сторов на 2026 год.

Что такое мобильное приложение и из чего оно состоит

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

Клиентская часть

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

Серверная часть и API

Серверная часть (бэкенд) хранит данные и выполняет бизнес-логику: учётные записи, заказы, платежи, каталог, расчёты, рассылку уведомлений. Приложение общается с сервером через API, набор правил обмена данными. Через тот же API бэкенд подключается к внешним системам: 1С, CRM, платёжному шлюзу, службе доставки.

Админ-панель для команды бизнеса

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

Что хранится на устройстве, а что на сервере

Разделение данных между смартфоном и сервером обычно выглядит так:

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

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

Зачем бизнесу своё приложение

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

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

Больше аргументов собрали в материале «7 причин создать мобильное приложение для бизнеса». Честная оговорка: приложение нужно не всем. Если клиент покупает раз в несколько лет (окна, ремонт, недвижимость) и повторного контакта не будет, скачивать отдельную программу он не станет. Таким компаниям обычно хватает быстрого адаптивного сайта или PWA.

4 способа создать мобильное приложение

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

Способ 1. Конструктор (no-code)

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

Плюсы конструктора:

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

Минусы проявляются при росте:

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

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

Способ 2. Самостоятельная разработка с нуля

Сделать мобильное приложение самому реально, если вы готовы платить временем. Понадобятся язык и среда разработки: Kotlin и Android Studio для Android, Swift и Xcode для iOS (а для сборки под iOS нужен компьютер Mac). Есть и третий вариант: кроссплатформенные фреймворки Flutter или React Native, на которых одна кодовая база работает на обеих платформах.

Помимо экранов придётся разобраться в бэкенде: базе данных, API, авторизации, хранении файлов. Часть задач закрывают готовые облачные сервисы (BaaS), но и их нужно настроить и защитить. Путь от первых уроков до опубликованного приложения у новичка обычно занимает месяцы.

Если вы выбираете этот путь, начните с наших пошаговых разборов: как создать мобильное приложение в Android Studio и как создать мобильное приложение на React Native. Самостоятельная разработка хороша для обучения, пет-проектов и стартапов, где основатель сам разработчик. Для коммерческого продукта с дедлайном риск велик: ошибки архитектуры и безопасности новичок замечает слишком поздно.

Способ 3. Фрилансер

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

Основные риски работы с фрилансером:

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

Риски можно снизить: заключить договор с передачей исключительных прав, вести код в репозитории, который принадлежит вам, регистрировать аккаунты App Store, Google Play и RuStore на свою компанию и платить поэтапно, за принятые результаты. Стоимость у фрилансеров сильно разнится и зависит от опыта исполнителя и объёма задачи, поэтому сравнивайте предложения по одному и тому же ТЗ.

Способ 4. Студия разработки под ключ

Студия разработки берёт проект целиком и проводит приложение через все этапы: аналитик собирает требования, дизайнер проектирует интерфейс, мобильные и бэкенд-разработчики пишут код, QA-инженер тестирует, менеджер проекта следит за сроками и бюджетом. Работать можно по фиксированной смете, когда объём понятен заранее, или по модели Time & Materials, когда требования уточняются по ходу.

Это самый дорогой из четырёх способов, зато за результат отвечает компания по договору. В YuSMP Group, например, на приложение даётся гарантия 6 месяцев, а исходный код передаётся заказчику. Ориентиры цен из нашего прайса: MVP от 300 000 ₽ за 2 месяца, приложение с админ-панелью от 800 000 ₽ за 4 месяца (подробнее в разделе о стоимости).

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

А если своя команда?

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

Какой способ выбрать: сравнительная таблица

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

Критерий	Конструктор	Сам с нуля	Фрилансер	Студия
Бюджет	Подписка, от нескольких тысяч ₽ в месяц	Время вместо денег	Ниже студии, сильно зависит от исполнителя	MVP от 300 000 ₽
Срок до первой версии	Дни–недели	Месяцы (с обучением)	От нескольких недель до месяцев	MVP от 2 месяцев
Сложность функций	Шаблонные сценарии	Зависит от навыков	Средняя	Любая, включая интеграции
Владение кодом	Кода нет, всё у платформы	У вас	У вас, если прописано в договоре	У заказчика по договору
Масштабирование	Ограничено платформой	Зависит от архитектуры	Рискованно без документации	Закладывается в архитектуру
Кому подходит	Проверка идеи, простая витрина	Обучение, пет-проекты	Небольшие приложения	Бизнес-продукты и стартапы с инвестициями

Быстрое дерево решения:

• Если нужно за пару недель проверить спрос и в приложении нет оплаты и личных данных → конструктор или PWA.
• Если нужны оплата, личный кабинет, интеграция с 1С или CRM → студия или опытная команда.
• Если в штате уже есть мобильный разработчик → своя разработка, при необходимости с усилением дизайнером и QA.
• Если бюджет ограничен, а задача небольшая и хорошо описана → фрилансер по договору с поэтапной оплатой.
• Если приложение станет основой бизнеса на годы → MVP в студии с последующей передачей кода своей команде.

Нативное, кроссплатформенное или PWA: на чём делать приложение

Технология определяет, сколько кодовых баз придётся поддерживать и насколько глубоко приложение работает с устройством. Вариантов три.

• Нативное приложение пишут отдельно под каждую платформу: на Swift для iOS и на Kotlin для Android. Оно максимально быстрое и сразу получает новые возможности системы.
• Кроссплатформенное приложение пишут один раз на Flutter или React Native и собирают под iOS и Android. Большая часть кода общая, поэтому разработка и поддержка обходятся дешевле.
• PWA (прогрессивное веб-приложение) — это сайт, который ведёт себя как приложение: ставится на домашний экран, работает офлайн и может присылать уведомления. В магазин его публиковать не обязательно.

Параметр	Нативное (Swift / Kotlin)	Кроссплатформенное (Flutter, React Native)	PWA
Производительность	Максимальная	Высокая для большинства бизнес-задач	Ограничена возможностями браузера
Доступ к функциям устройства	Полный	Почти полный, редкие функции через нативные модули	Частичный, на iOS заметно уже
Кодовая база	Две, отдельно под iOS и Android	Одна общая	Одна, веб
Публикация в сторах	Да	Да	Не обязательна
Бюджет	Высокий	Средний	Низкий

Для большинства бизнес-MVP мы рекомендуем кроссплатформу: одна команда, один код, обе платформы и нормальная скорость работы. Нативная разработка оправдана для тяжёлой графики и игр, AR, сложной работы с Bluetooth, камерой и датчиками или когда приложение должно первым поддерживать новые функции iOS. PWA подойдёт, когда присутствие в магазине не обязательно, а аудитория и так приходит через сайт. Плюсы и минусы этого варианта подробно разобраны в статье «PWA против нативного приложения».

С чего начать разработку приложения: подготовка

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

Сформулируйте задачу и аудиторию

Опишите одним предложением, кто ваш пользователь и какую работу он «нанимает» приложение сделать. Например: «мастер маникюра хочет, чтобы клиентки записывались сами, без переписки в мессенджере». Такая формулировка (в продуктовом мире её называют Job To Be Done) сразу отсекает лишние функции и подсказывает главный экран.

Проверьте спрос до кода

Проверка спроса отвечает на вопрос, нужно ли приложение кому-то кроме вас. Несколько дешёвых способов:

• проведите 6–10 интервью с целевыми пользователями (кастдев): спрашивайте о прошлом опыте и текущих решениях, а не о том, «стали бы вы пользоваться»;
• изучите конкурентов в App Store, Google Play и RuStore: отзывы с одной-двумя звёздами дают готовый список болей, которые вы можете закрыть;
• сделайте лендинг-заглушку или кликабельный прототип и посмотрите, сколько людей оставят контакты или пройдут сценарий до конца.

Определите MVP

MVP (минимально жизнеспособный продукт) — первая версия, в которой есть только то, без чего приложение не решает задачу пользователя. Разложите функции по приоритетам must / should / could: в MVP попадают только must. Всё остальное идёт в бэклог и добавляется по данным реального использования. Как это сделать на практике, мы описали в материале «MVP мобильного приложения: как запустить за минимальный бюджет».

Подготовьте ТЗ

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

Как создать мобильное приложение: пошаговый план из 8 шагов

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

Шаги 1–4: от идеи до дизайна

1. Идея и проверка спроса. Формулируем задачу пользователя, проводим интервью и смотрим конкурентов в сторах. Результат шага: подтверждение, что продукт кому-то нужен, и список ключевых сценариев.
2. Выбор способа и технологии. Решаем, кто делает приложение (конструктор, свои силы, фрилансер, студия) и на чём (нативно, кроссплатформенно, PWA). Результат: понятная модель работы и стек.
3. ТЗ и оценка. Описываем функции, роли, экраны и интеграции, получаем смету и график. Результат: зафиксированный объём MVP, бюджет и сроки.
4. Прототип и UX/UI-дизайн. Собираем кликабельный прототип в Figma, проверяем его на пользователях и рисуем финальный дизайн. Результат: утверждённые макеты всех экранов и дизайн-система.

Шаги 5–8: разработка, релиз и поддержка

5. Разработка клиентской части и бэкенда. Пишем приложение и сервер спринтами по две недели, в конце каждого показываем рабочую сборку. Результат: работающий продукт, который заказчик видит и проверяет по ходу.
6. Тестирование. Проверяем функции, работу на реальных устройствах с разными версиями ОС, нагрузку и безопасность. Результат: стабильная сборка без критических ошибок.
7. Публикация в сторах. Готовим описание, скриншоты и иконку, проходим модерацию App Store, Google Play и RuStore. Результат: приложение доступно для скачивания.
8. Запуск, аналитика и поддержка. Подключаем аналитику, собираем отзывы, выпускаем исправления и обновления под новые версии iOS и Android. Результат: продукт развивается на основе данных, а не догадок.

Каждый из этих этапов, с ролями в команде и артефактами на выходе, подробно описан в материале «Этапы разработки мобильного приложения: от идеи до релиза».

Сколько стоит создать мобильное приложение и сколько времени займёт

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

Ориентиры стоимости и сроков

Ориентиры студийной разработки YuSMP Group по типам приложений:

Тип приложения	Что входит	Стоимость	Срок
MVP	Минимальный набор функций для проверки идеи	от 300 000 ₽	около 2 месяцев
Стандартное приложение	Авторизация, оплата, основные сценарии	от 500 000 ₽	около 3 месяцев
Приложение с админ-панелью	Плюс управление контентом и заказами для команды	от 800 000 ₽	около 4 месяцев
Расширенное приложение	Интеграции с внешними системами, аналитика	от 1 000 000 ₽	около 5 месяцев

Это ориентиры, точная смета появляется после аналитики и согласования ТЗ. Полноценный продукт обычно разрабатывается 4–8 месяцев.

Дополнительные расходы и что удорожает проект

Помимо разработки заложите обязательные расходы:

• аккаунт Apple Developer Program: $99 в год;
• аккаунт Google Play Console: разовый сбор $25;
• RuStore: регистрация бесплатна, но с платежей внутри приложения берётся комиссия от 15%;
• серверы и хостинг бэкенда, хранилище файлов, сервисы push-уведомлений;
• поддержка и обновления после релиза.

Что сильнее всего увеличивает бюджет:

• число платформ, если выбрана нативная разработка под iOS и Android отдельно;
• интеграции с 1С, CRM, платёжными системами, службами доставки;
• функции реального времени: чаты, трекинг курьера, видеосвязь;
• сложная кастомная анимация и нестандартный интерфейс;
• требования 152-ФЗ при обработке персональных данных.

Практический совет: держите резерв 15–20% бюджета на непредвиденное. Требования почти всегда уточняются после первых тестов на пользователях. Детальная калькуляция по статьям расходов есть в статье о стоимости разработки мобильного приложения, а разбор сроков по этапам в материале «Сколько длится разработка приложения».

Как опубликовать приложение в App Store, Google Play и RuStore в 2026 году

Публикация приложения — это регистрация аккаунта разработчика, загрузка сборки с описанием и прохождение проверки магазина. У каждого стора свои условия, и их стоит учесть ещё на этапе планирования.

Магазин	Аккаунт разработчика	Особые требования	Подробнее
App Store	Apple Developer Program — $99 в год	Каждое приложение и обновление проходит ревью Apple	Как опубликовать приложение в App Store
Google Play	Разовый сбор $25	Для новых личных аккаунтов — закрытое тестирование: не менее 12 тестировщиков не менее 14 дней подряд до выхода в продакшен	Как опубликовать приложение в Google Play
RuStore	Регистрация бесплатна через VK ID, для физлиц, ИП и юрлиц	Комиссия от 15% с платежей через RuStore	Публикация приложения в RuStore

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

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

ASO (App Store Optimization) — работа с карточкой приложения в магазине. Название, описание, ключевые слова, иконка и скриншоты определяют, найдут ли приложение в поиске стора и решатся ли его установить.

Что делать после релиза: продвижение и поддержка

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

• ASO и продвижение. Тестируйте разные скриншоты и описания, отвечайте на отзывы, приводите трафик с сайта и из соцсетей.
• Push-уведомления. Используйте их для полезных напоминаний и персональных предложений, а не для спама: навязчивые push приводят к удалению приложения.
• Аналитика. Отслеживайте установки, активацию (дошёл ли пользователь до ключевого действия), удержание на 1-й, 7-й и 30-й день и отток. Как считать и улучшать эти метрики, мы разобрали в статье о retention и churn в мобильном приложении.

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

Частые ошибки при создании приложения

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

• Разработка без проверки спроса. Продукт делают месяцами, а потом выясняется, что задача пользователя решается иначе или не болит вовсе.
• «Всё и сразу» вместо MVP. В первую версию пытаются уместить все идеи, бюджет заканчивается раньше релиза.
• Конструктор для продукта, который будет расти. Через полгода упираются в ограничения платформы и платят за разработку дважды.
• Аккаунты и репозиторий оформлены на подрядчика. При смене исполнителя компания не может выпустить обновление собственного приложения.
• Нет бюджета на поддержку. Приложение не обновляют, оно ломается на новых версиях ОС и собирает плохие отзывы.
• Игнорирование 152-ФЗ. Персональные данные собирают без согласия и политики обработки, а хранят на зарубежных серверах.
• Нет аналитики с первого дня. Без данных невозможно понять, почему пользователи уходят, и решения принимаются наугад.

Коротко о главном

Пять решений, которые стоит принять до первой строки кода:

• Начинайте с проверки спроса и MVP, а не с полного списка функций.
• Конструктор подходит для теста гипотезы, студия — для продукта с оплатой, интеграциями и планами на рост.
• Для большинства бизнес-приложений оптимальна кроссплатформенная разработка на Flutter или React Native.
• Закладывайте в план две недели закрытого теста Google Play для нового личного аккаунта и ежегодный взнос Apple.
• Код, сервер и аккаунты в сторах должны принадлежать вам с первого дня.

Частые вопросы о создании мобильного приложения

Можно ли создать мобильное приложение бесплатно?

Собрать простое приложение бесплатно можно в конструкторе на бесплатном тарифе, но с ограничениями по функциям, дизайну и с логотипом платформы. Публикация тоже стоит денег не везде: в RuStore регистрация бесплатна, в Google Play разовый сбор составляет $25, в App Store подписка обходится в $99 в год. Для коммерческого продукта бесплатный вариант обычно оказывается временным.

Сколько стоит сделать мобильное приложение под ключ?

В YuSMP Group MVP стоит от 300 000 ₽, стандартное приложение с авторизацией и оплатой от 500 000 ₽, с админ-панелью от 800 000 ₽, с расширенными интеграциями и аналитикой от 1 000 000 ₽. Итоговая цена зависит от числа платформ, интеграций и сложности интерфейса. Точную смету даём после аналитики и согласования ТЗ.

Сколько времени занимает создание приложения?

В конструкторе простое приложение собирают за дни или недели. MVP в студии занимает от 2 месяцев, полноценный продукт обычно 4–8 месяцев. К сроку разработки стоит добавить время на модерацию в сторах и, для нового личного аккаунта Google Play, две недели закрытого тестирования.

Что выбрать: конструктор или разработку?

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

Нужно ли делать приложение сразу под iOS и Android?

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

Кому принадлежат код и аккаунты в сторах?

Это зависит от договора, поэтому права нужно прописать явно: передача исключительных прав на код, доступ к репозиторию, передача серверов и документации. Аккаунты разработчика в App Store, Google Play и RuStore лучше сразу регистрировать на свою компанию и давать подрядчику доступ, а не наоборот. Тогда смена исполнителя не остановит выпуск обновлений.