Мобильная разработка в 2026: Native, Flutter, React Native и PWA — что выбрать

Почему этот гид написала Фора Софт

Фора Софт уже 21 год разрабатывает мобильные и мультимедийные продукты. Мы выпустили более 625 приложений для iOS, Android, Flutter, React Native и PWA, включая видеоприложения, которые транслируют потоковое видео в реальном времени, обрабатывают ИИ-модели и обслуживают миллионы сессий в месяц. Каждую неделю мы слышим одни и те же вопросы от заказчиков: native или кросс-платформенная разработка? начать с iOS или сразу с обеих платформ? и сколько это будет стоить? Эта статья — тот же ответ, который вы услышали бы от нас на discovery-встрече, только подробнее, с ссылками и в удобном для распечатки формате.

Если коротко: большинству продуктовых основателей в 2026 году стоит «собрать сфокусированный MVP на native или Flutter, найти Product-Market Fit на 500–1 000 живых пользователях и потом масштабироваться». Выбор между Swift, Kotlin, Flutter, RN, KMP и PWA зависит от пяти конкретных факторов — разберём их ниже. Читайте дальше, если хотите получить обоснованное решение, — или напишите нам, чтобы мы обсудили ваш конкретный продукт.

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

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

Если в смете нет отдельных строк на QA, DevOps или поддержку после запуска — настаивайте на их включении. Именно в этих пунктах скрывается реальная стоимость проекта.

Сигнал рынка в 2026 году — почему мобильная платформа по-прежнему ваш главный инструмент

Мобайл больше не опция. Statista и data.ai оценивают мировой рынок мобильных приложений примерно в 12–14 трлн ₽ в год в сумме по App Store и Google Play, при 140–160 млрд скачиваний ежегодно и среднем времени в приложениях 5+ часов в день на зрелых рынках. По количеству просмотров мобильный веб может быть больше, но сессии в приложениях в 10–100 раз ценнее с точки зрения удержания, конверсии и ARPU. Если ваш продукт в 2026 году взаимодействует с потребителями, партнёрами или выездными сотрудниками, «только веб» — это выбор, который нужно осознанно делать.

Native iOS — реальность Swift 6 в 2026 году

Native iOS в 2026 году — это Swift 6 со строгой конкурентностью по умолчанию, SwiftUI с макросом @Observable, MVVM-архитектура с координаторами, Swift Package Manager, Xcode 16 и Swift Testing. Главный сдвиг с 2024 года: гонки данных теперь становятся ошибками на этапе компиляции, а не приводят к сбоям во время работы. Для нового кода это преимущество, а для старых проектов — сложный и трудоёмкий процесс обновления перед переходом на новую версию.

Сильные стороны

Холодный старт 0,5–0,8 с, максимально плавный скролл 60/120 Гц на Apple silicon, самый глубокий доступ к «железу» (HealthKit, HomeKit, ARKit, Core ML, Metal, on-device Apple Intelligence). Выручка с одного пользователя в App Store на западных рынках по-прежнему в 2–5 раз выше, чем на Android. Для премиальных потребительских приложений и интерфейсов с богатой анимацией нативная разработка под iOS — очевидный выбор.

Слабые стороны

Узкие Swift-специалисты — самая дорогая статья расходов в мобильном бюджете. Ревью в App Store добавляет к каждому релизу 1–3 дня. Окно обратной совместимости короче, чем на Android: большинство команд поддерживают 3–4 версии iOS, а не 5 и более.

Если хочется глубже разобраться в архитектуре, у нас есть отдельный материал — плейбук по iOS MVVM-C в 2026 году, а также гайды по ключевым фичам Swift 6 и оптимизации производительности iOS.

Native Android — Kotlin 2, Compose и правило 16 КБ

Native Android в 2026 году — это Kotlin 2.х, Jetpack Compose, Material Design 3, корутины и Flow, Hilt для внедрения зависимостей и Android Studio Ladybug+. Требование Google Play к размеру страниц в 16 КБ теперь обязательно для новых приложений — старые Gradle-цепочки просто не пройдут загрузку в магазин. Сборка по требованию сокращает время инкрементальных сборок на 40–50% по сравнению с уровнем 2023 года.

Сильные стороны

Крупнейшая пользовательская база в мире, самое быстрое ревью (Play Console одобряет за часы, а не за дни), более широкий охват устройств (BLE, NFC, складные смартфоны, Wear OS, Auto) и больше недорогих тестовых устройств. Кадровый пул шире и немного дешевле, чем по iOS.

Слабые стороны

Фрагментация устройств — реальность: у пользователей более 10 000 моделей. Политика Google Play обновляется 4–6 раз в год и ломает приложения, которые не поддерживают актуальные требования. ARPU на западных рынках ниже, чем у iOS, поэтому модели монетизации между платформами часто приходится разделять.

Flutter — кросс-платформенный выбор по умолчанию в 2026

Flutter 3.27+ с Dart 3.x и рендерером Impeller — то, к чему большинство команд тянутся в первую очередь, когда хотят одну команду и одну кодовую базу. Холодный старт занимает около 1,2–1,8 с, скролл держится на уровне 59–60 FPS на среднем Android и 120 FPS на флагманском iOS, а hot reload — самый быстрый цикл в мобильной разработке (обычно меньше 2 секунд). В экосистеме сейчас более 35 000 пакетов.

Сильные стороны

Одна команда, одна кодовая база, одна дизайн-система на iOS и Android — обычно запуск на 30–40% быстрее и на 25–35% дешевле, чем у двух нативных команд. Поддержка sound null safety. Impeller устранил баги рендеринга Skia, которые мучили Flutter в версиях 2–3.0. Flutter for Web (на WASM с 3.24) позволяет запускать приложение на десктопе и в вебе почти без дополнительных затрат.

Слабые стороны

Размер приложения на 15–25 МБ больше минимальной нативной сборки. Накладные расходы по памяти выше на 15–20%. Выполнение ML-инференса на устройстве через TensorFlow Lite + Dart на 15–20% медленнее, чем в нативном коде — это сказывается на AR-сценариях и продуктах с акцентом на ИИ. Поддержка раскладок для планшетов и iPad пока требует дополнительной доработки.

Более подробный взгляд на Flutter с точки зрения заказчика — в нашем плейбуке о плюсах и минусах Flutter с финансовыми моделями и стратегией гибридной разработки или реплатформинга.

React Native — для команд, ориентированных на веб, и интеграции в существующие приложения

React Native 0.76+ с новой архитектурой (Fabric + TurboModules), движком Hermes и Expo SDK 52+ значительно сократил отставание от Flutter по удобству разработки. Накладные расходы на мост снизились на 50% по сравнению со старым мостом. Сообщество огромное: более 50 000 звёзд на GitHub, более 45 000 пакетов в npm, а технологии прошли проверку в Meta, Shopify, Microsoft, Airbnb и Discord.

Сильные стороны

Если у вас команда на JavaScript или TypeScript, React Native — самый дешёвый способ нанять разработчиков и масштабироваться. Интеграция в существующее нативное приложение хорошо отработана: можно вставить один экран на React Native внутрь десятилетнего Swift-кода. EAS Build от Expo делает CI/CD таким же простым, как в Vercel.

Слабые стороны

Холодный старт (1,8–2,5 с) уступает Flutter и нативным решениям. Прирост размера приложения на iOS больше, чем у Flutter. Накладные расходы по памяти — 20–30%. Новая архитектура хорошая, но экосистема пока отстаёт: 30–40% продуктовых приложений и многие сторонние библиотеки всё ещё используют старый мост.

Если ваш продукт — это общение в реальном времени, у нас есть отдельная статья о разработке видеочата на React Native.

Kotlin Multiplatform — тёмная лошадка

Kotlin Multiplatform Mobile стабилен с 2023 года и сейчас используется в продакшене в Яндексе, Philips, McDonald’s и VMware. Идея в том, что общая бизнес-логика — работа с сетью, авторизация, хранение данных, модели и валидация — пишется на Kotlin, а интерфейс остаётся нативным: на SwiftUI для iOS и на Compose для Android. Compose Multiplatform от JetBrains также позволяет делать общий UI, цель — выйти на версию 1.0 в 2025–2026 годах.

KMP — хороший выбор, если ваша команда хорошо владеет Kotlin и вам нужен единый код для не-UI-логики без потери качества нативного интерфейса. Это плохой выбор, если у команды нет опыта с Kotlin — инструменты и отладка на стороне iOS пока недостаточно зрелые по сравнению с чистым Swift, а количество доступных библиотек значительно меньше, чем у Flutter или React Native.

PWA — что уже умеет, а чего всё ещё не может

Progressive Web App — это веб-приложение, использующее сервис-воркеры, манифест для установки, push-уведомления и кэширование с приоритетом офлайн-режима. Twitter Lite, Pinterest, Starbucks и Spotify внедряют PWA в массовом масштабе: Twitter Lite занимал всего 1 МБ против 100 МБ и более у нативной версии и сохранил 60% пользователей.

Что работает в 2026 году

Сервис-воркеры, push-уведомления (iOS 16.4+, Android 5+), приглашения «Добавить на главный экран», Payment Request API (Apple Pay, Google Pay), доступ к файловой системе и стратегии офлайн-кэширования. По SEO и удобству распространения веб-приложения по-прежнему уверенно опережают нативные.

Что всё ещё не работает на iOS

Фоновая синхронизация ограничена, push-уведомления обрезаны сильнее, чем на Android, интерфейс установки выглядит недоделанным, Bluetooth и NFC недоступны, встроенные покупки запрещены. Если хотя бы один из этих моментов важен — нужен нативный или кросс-платформенный фреймворк с нативной оболочкой.

Бенчмарки производительности — цифры, которые важны для заказчика

Если сравнивать подходы «на ощущения», вас могут уговорить использовать неподходящий стек. Сравнение по цифрам ниже — это разговор, который мы ведём на каждом созвоне перед стартом проекта.

Два неочевидных вывода. Во-первых, FPS при прокрутке у трёх верхних вариантов почти одинаковый — пользователь разницы не почувствует. Во-вторых, цикл «правка — перезагрузка» — это та метрика, которая определяет, выйдете вы в продакшен через 12 или через 18 недель. Здесь Flutter и React Native опережают нативную разработку в 30 раз.

Диапазоны стоимости и сроков в 2026 году

Это консервативные отраслевые ориентиры для сфокусированного MVP — авторизация, 5–7 экранов, API, push-уведомления, платежи, базовый офлайн-режим. У нас сроки и бюджеты, как правило, ниже этих значений, потому что мы применяем spec-ориентированный agentic-инжиниринг внутри команды. Конкретный план мы предпочитаем обсуждать после discovery-звонка, а не публиковать одну цифру в блоге.

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

Модели сотрудничества — T&M, фикс-прайс, ретейнер

Форма контракта определяет форму проекта. Доминируют три модели, а также гибрид — его мы обычно и рекомендуем.

1. Time & Materials. Оплата по часам, счёта раз в неделю. Максимальная гибкость при неопределённом объёме работ — риск роста задач ложится на вас. Подходит, когда аналитика была поверхностной и приходится учиться в процессе разработки.

2. Фикс-прайс. Объём и цена зафиксированы; риск перерасхода лежит на подрядчике. Цена выше — на 15–25% по сравнению с T&M, а изменения в объёме работ происходят медленно. Такой формат подходит только тогда, когда объём работ действительно можно точно определить заранее.

3. Ретейнер. Месячная ёмкость команды, чаще всего после запуска. За 225 тыс. – 1,1 млн ₽/мес вы получаете исправление багов, обновления под новые ОС и реализацию мелкой функциональности.

4. Гибрид (наш дефолт). Фикс-цена на этапы исследования и дизайна, T&M на разработку с ограничениями по трудозатратам в рамках спринта и чётким процессом обработки изменений. Такой подход даёт предсказуемость бюджета и гибкость для адаптации к новым данным.

Фреймворк решения — выберите стек за пять вопросов

Q1. Какое соотношение iOS/Android в вашей аудитории? >70% одной платформы — делайте нативное приложение под неё, вторую — позже. 50/50 — кросс-платформенное решение почти всегда выгоднее по общей стоимости владения (TCO).

Q2. Насколько UX перегружен анимацией или аппаратными возможностями? AR/VR, фильтры по камере в реальном времени, сложная физика, скролл 120 Гц, кастомные шейдеры — всё это лучше делать нативно. CRUD, списки, ленты, дашборды — тут кросс-платформенные решения справятся.

Q3. Что уже знает ваша команда? У нас сильная команда по вебу и JavaScript — работает с React Native. Сильная команда на Kotlin — делает нативный Android или использует KMP. Если команды ещё нет — нанимайте разработчиков под тот стек, с которым планируете остаться.

Q4. Насколько быстро нужно выйти в продакшен? <12 недель — Flutter или React Native. 12–20 недель — любой из native под одну платформу, Flutter или RN. >20 недель — в игру вступает и двойной native.

Q5. Каков долгосрочный план? Если в ближайшие два года в дорожной карте есть десктоп- или веб-спутник, Flutter (с целями Web/Desktop) получает серьёзный бонус. Та же логика работает и для KMP, если у вас уже используется Kotlin на сервере.

Что изменилось в 2026 году по сравнению с 2022

1. Строгая конкурентность Swift 6. По умолчанию включена. Перед обновлением старые кодовые базы нужно будет переработать — обычно это занимает 10–20% усилий.

2. Требование Google Play по выравниванию страниц 16 КБ. Обязательно для новых приложений. Старые Gradle-цепочки не загрузятся — закладывайте бюджет на обновление CI/CD.

3. Сайдлоадинг по DMA в ЕС. Apple и Google обязаны разрешить сторонние магазины в Евросоюзе. AltStore, Epic Games Store и другие теперь распространяют iOS-приложения в регионе. Оптимизация под несколько магазинов и соблюдение сроков проверки приложений стали важны.

4. Продолжение App Tracking Transparency. Окна атрибуции SKAdNetwork сузились, поэтому стратегии работы с собственными данными стали необходимостью — от этого теперь зависит рекламная выручка.

5. On-device AI. Apple Intelligence (iOS 18+) и Gemini Nano (Android 14+) позволяют выполнять полноценный инференс LLM прямо на устройстве. Функции, ориентированные на приватность, которые раньше требовали подключения к серверу — умные ответы, распознавание речи и генеративный интерфейс — теперь работают локально.

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

Пять ловушек, в которых тонут мобильные проекты

1. Раздутый MVP. «Нам нужно 27 фич на запуск» превращает 16-недельную разработку в 14-месячный марафон. Ограничьтесь 3–5 функциями, которые проверят ключевую гипотезу. Протестируйте — потом расширяйте.

2. Кросс-платформа на продукте с тяжёлой анимацией. Flutter и RN отлично работают, пока не придётся интегрировать ARKit, кастомные Metal-шейдеры или физику в реальном времени. Тогда в отзывах App Store начнут появляться жалобы на подтормаживания — в 30–50% случаев. Выбирайте технологический стек под продукт, а не под бюджет.

3. Игнорирование ежегодных апгрейдов ОС. И iOS, и Android выпускают крупный релиз каждый сентябрь. Закладывайте 1–3 недели в год на каждую платформу на работу с совместимостью — иначе однажды утром обнаружите, что приложение сломалось. Все ошибки мы разбираем в нашем гиде по топовым ошибкам в мобильной разработке.

4. Нет внятной ASO-стратегии. Отличное приложение с плохо оформленной карточкой в магазине скачивается в 1–3% случаев из органического трафика; то же приложение с оптимизированной карточкой — в 10–15%. На настройку платформы до запуска закладывайте 225–750 тыс. ₽. Что именно тестировать — в нашем плейбуке по ASO для iOS.

5. Хрупкий CI/CD. Если релиз может сделать только один разработчик — это бутылочное горлышко. Настаивайте на автотестах, автосборках и плане отката уже с первой недели.

KPI — что измерять после запуска

KPI по качеству. Доля сессий без сбоев — не менее 99,5%. Время запуска с нуля — менее 1,5 с на устройстве среднего класса. FPS при прокрутке — не ниже 58 на 95-м перцентиле устройств. Размер приложения — менее 50 МБ.

Бизнес-метрики. Удержание D1 — не менее 35%, D7 — не менее 15%, D30 — не менее 8% для потребительских приложений. Активационное событие происходит в течение 60 секунд с момента первого запуска. Доля пользователей, дающих согласие на push-уведомления — не менее 50%. Конверсия в App Store / Google Play — не менее 25%.

KPI надёжности. P95-задержка бэкенда <300 мс. Доставка push ≥95%. Каденс релизов: минимум раз в месяц, чтобы оставаться актуальным в алгоритмах сторов.

Как выбрать подрядчика — что спрашивать и что проверять

Короткий, но плотный чек-лист для оценки подрядчика:

• Соответствие портфолио. Три кейса в вашей категории с именами клиентов и конкретными результатами (не просто логотипы).
• Сеньоры в ключевых ролях, а не только в продажах. Попросите ссылку на GitHub у ведущего разработчика. Тот, кого вы видите на старте проекта, должен быть и на ревью спринтов.
• Права на интеллектуальную собственность. «Работа выполняется как work made for hire; все права на IP переходят к клиенту» — прямо в договоре. Исходный код, дизайн-файлы, CI/CD-пайплайны, документация. Наш взгляд на это — в материале «Как сэкономить время и деньги, поделившись кодом с разработчиками».
• Discovery как полноценная услуга. Платный этап аналитики на 2–4 недели — хороший знак; «оценим за 24 часа» — повод насторожиться. Подробнее о том, как устроен этот этап у нас, расскажем на созвоне.
• Прозрачность оценки. Отдельные строки на QA, DevOps, ASO и поддержку после запуска. Как выглядит обоснованная оценка, мы разбираем в материале «Как разработчику оценить трудозатраты».
• Каденс коммуникации. Демо — раз в неделю, обновления — в Slack или асинхронно, ревью со стейкхолдерами — раз в месяц. Если в процессе продаж не удаётся наладить такой ритм, после заключения контракта это будет ещё сложнее.
• SLA на поддержку после запуска. Реакция на критический баг — не более 4–8 часов, устранение крупного бага — не более 1–2 дней, ежемесячный минорный релиз. В письменном виде.

Мини-кейс — от MVP до продакшена в типичном проекте

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

Что мы делаем. Двухнедельный этап исследования (пользовательские сценарии, шорт-лист функций, выбор стека — обычно Flutter для такого объёма), четыре недели на UX/UI с параллельной подготовкой бэкенда, затем 10 недель разработки и постоянного тестирования с выходом в TestFlight и внутреннюю дорожку Play для бета-теста на 200 пользователей. Публикация, ASO и публичный релиз — в последние две недели.

Результат. Живое приложение в обеих магазинах через 12–14 недель после старта, с исходным кодом и пайплайнами, переданными в GitHub-организацию клиента уже с первой недели. Нужен похожий план под вашу идею? Позвоните или напишите нам.

Когда мобильное приложение строить НЕ стоит

Кастомный мобайл — не всегда правильный выбор, и об этом мы скажем уже на первом созвоне. Если ваша аудитория заходит в продукт реже трёх раз в неделю и не нуждается в офлайн-режиме, работе с аппаратными сенсорами или пуш-уведомлениях, то качественный адаптивный сайт или PWA справятся с задачей первые 12 месяцев, пока вы работаете над удержанием, — и обойдутся на 30–50% дешевле. Если вы — B2B-инструмент для рабочего стола, то в большинстве случаев комбинация десктоп и веб-версии будет эффективнее мобильного приложения. А если у вас ещё нет ни Product-Market Fit, ни бюджета на его поиск, прототип на no-code поможет быстрее проверить, готовы ли пользователи платить, чем разработка кастомного приложения.

FAQ

Что почитать дальше

Готовы заказать разработку мобильного приложения?

Услуги разработки мобильных приложений в 2026 году сводятся к четырём реальным вариантам — native iOS, native Android, кросс-платформенная разработка (Flutter или React Native) и PWA — и к одному важному вопросу: кто будет в команде? Выбор фреймворка подскажет правильный подход, таблица стоимости поможет определить обоснованный бюджет, а чек-лист для подрядчика — найти партнёра, который не оставит вас с кодом, который вы не сможете поддерживать. Всё остальное — это уже дело исполнения.

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