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

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

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

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

Задача бизнеса, а не список экранов. «Хотим приложение с личным кабинетом» — это решение, причём чужое. «Клиенты звонят в колл-центр узнать статус заказа, 400 звонков в день, хотим снять половину» — это задача, под которую можно предложить решение дешевле или лучше.

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

Список систем, с которыми надо связаться. 1С, CRM, складская программа, платежи, телефония. Названия, версии, у кого доступы и есть ли API. Это самая недооценённая часть бюджета.

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

Кто ведёт проект с вашей стороны. Имя, зона ответственности, право утверждать макеты и требования.

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

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

Четыре пути отличаются не ценой, а тем, кто несёт риск, если что-то пойдёт не так.

No-code конструкторы. Appy Pie, Glide, Adalo собирают простое приложение из готовых блоков без программистов. Быстро и дёшево для витрины, каталога, записи на услугу. Потолок наступает там, где появляются нестандартная логика, интеграции, нагрузка и собственный дизайн — конструктор это не тянет, и продукт переписывают заново. Как этап проверки гипотезы это нормальный сценарий.

Нейросети. Cursor, ChatGPT и Replit действительно генерируют рабочий каркас и прототип из текстового описания. Энтузиаст соберёт простое приложение за выходные, опытный разработчик ускорится в разы.

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

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

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

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

Мобильная разработка у нас начинается от 1,8 млн ₽, но точной цифры без ваших требований не существует: смету считаем по задаче, оценка проекта бесплатная. Вилку по своей задаче можно получить и без брифа — в калькуляторе за пару минут.

Нативная разработка — отдельное приложение под каждую платформу на родном языке. Максимум производительности и доступа к системе ценой двух проектов вместо одного. Кроссплатформа — общая кодовая база под iOS и Android, для большинства бизнес-приложений это выбор по умолчанию, поэтому мы и ведём разработку приложений на Flutter. PWA закрывает задачу без сторов, но с урезанным доступом к устройству.

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

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

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

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

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

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

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

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

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

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

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

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

RuStore — фундамент для Android. Закон об обязательной предустановке действует с 1 сентября 2025 года, аккаунт разработчика и публикация бесплатны, аудитория в июле 2026 года — 68,4 млн пользователей в месяц по данным Mediascope. Комиссия 15 % против 30 % у зарубежных сторов, а за платежи мимо своего SDK RuStore комиссию не берёт вовсе.

RuStore на iPhone де-факто нет. Закон формально распространили и на технику Apple, ФАС предписала предустановить магазин к 15 июля 2026 года, но срок прошёл, а полноценного RuStore на iOS так и не появилось. Для планирования это значит одно: iOS-канал в России — это App Store и только он.

Google Play — публикуем, но не зарабатываем. С 26 декабря 2024 года разработчикам с расчётным счётом в российском банке недоступны платные приложения, встроенные покупки и подписки; последние выплаты начислили 15 января 2025 года. Бесплатное приложение публиковать и обновлять можно. Аккаунт — 25 $ единоразово.

App Store — только через иностранное юрлицо. Доля iOS в России выросла до 32 % к марту 2026 года по данным Statcounter, и эта аудитория платит охотнее. Аккаунт Apple Developer стоит 99 $ в год, российской картой его не оплатить. Что специфично для платформы — в гайде по разработке приложений для iOS.

Альтернативные витрины. AppGallery, GetApps и Galaxy Store добавляют охвата на устройствах Huawei, Xiaomi и Samsung бесплатно.

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

В RuStore с 1 февраля 2026 года платёжные SDK работают только у ИП и юрлиц: монетизацию для самозанятых отключили, платные приложения таких разработчиков скрыли из магазина, новые заявки перестали принимать ещё в декабре 2025-го. Реклама и собственный платёжный контур остались доступны всем.

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

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

Ещё одно изменение стоит учесть тем, кто планирует продукт на годы вперёд. Google вводит верификацию разработчиков на уровне самой Android: система будет проверять личность автора и права на имя пакета независимо от того, откуда приложение установлено — из магазина или файлом. С 30 сентября 2026 года правило действует в Бразилии, Индонезии, Сингапуре и Таиланде, на остальные регионы его планируют распространить в 2027-м.

Что это значит на практике. Если приложение выходит только в RuStore, разработчику всё равно придётся пройти верификацию в консоли Google и зарегистрировать имя пакета, а организации — получить номер D-U-N-S. Если приложение есть и в Google Play, отдельная верификация не нужна: подходит ключ подписи оттуда. Сам процесс публикации в RuStore при этом не меняется.

Модели монетизации стандартны — подписки, встроенные покупки, freemium, реклама, разовая продажа. В российских реалиях выбирают не модель, а способ провести платёж.

Раз выручку из Google Play не вывести, продажи строят на платёжном SDK самого RuStore либо на собственном контуре, где карты, СБП и эквайринг подключены напрямую. У каждого варианта свои требования к бэкенду, свои сроки подключения и свои правила сторов, которые нельзя нарушать.

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

Рядом с деньгами всегда лежат персональные данные, и цена ошибки здесь выросла. За утечку данных больше ста тысяч человек юридическому лицу грозит штраф в 10–15 млн ₽. За повторное нарушение считают процент от годовой выручки, и нижняя граница измеряется десятками миллионов. Появилась и уголовная статья за незаконную передачу таких данных.

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

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

Исходный код в вашем репозитории, с историей коммитов и инструкцией по сборке. Проверка простая: сторонний разработчик собирает проект по инструкции и не звонит команде.

Документация — архитектура, интеграции, схема данных, окружения. Без неё через полгода никто не вспомнит, почему сервис ходит в 1С именно так.

Доступы и учётные записи — серверы, домены, сертификаты, ключи подписи, аккаунты в сторах, панели аналитики. Список составляется заранее и передаётся под опись.

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

Вокруг фиксированной цены больше всего конфликтов, поэтому скажем прямо. Зафиксировать бюджет и срок реально — мы так и работаем, — но фиксируются они вместе с требованиями. Меняются требования — меняется и цена. Это обсуждают открыто, и тогда не появляется претензия «вы же обещали дешевле».

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

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

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

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

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

Формат продукта. Приложение вместо PWA или Mini App там, где второго хватало, — это лишние миллионы и обязательство содержать продукт годами.

Границы первой версии. Попытка выпустить всё сразу отодвигает релиз на полгода и лишает вас обратной связи от реальных пользователей, по которой и корректируют планы.

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

Юрлицо и аккаунты. Публикация под аккаунтом подрядчика экономит неделю на старте и стоит месяца при расставании.

Платёжный контур. Выбор способа приёма денег определяет требования к бэкенду; менять его после релиза — отдельный проект.

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

• 1. Сформулируйте задачу бизнеса и метрику, которую приложение должно сдвинуть.
• 2. Проверьте, что задачу не закрывает более дешёвый формат.
• 3. Соберите список систем для интеграции и выясните, у кого доступы.
• 4. Назначьте человека с правом принимать решения.
• 5. Определите границу первой версии: один сценарий, доведённый до конца.
• 6. Получите оценку и сверьте её строки со своим списком функций.

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

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

Команда собрана внутри — аналитика с отраслевой экспертизой, дизайн, мобильная разработка, бэкенд и тестирование работают вместе много лет. Мы фиксируем цену и срок до старта, а часть рутины в конвейере закрывает AI-first подход — за счёт этого рабочий продукт выходит за 2–3 месяца, а кликабельный прототип показываем на первой неделе.

Обсудить проект →