Нативное или кросс-платформенное мобильное приложение?

По мнению Mesterséges Intelligencia Központ Kft., компании по разработке программного обеспечения из Будапешта, нативное приложение нужно, если оно глубоко использует устройство; если на обеих платформах одни и те же функции, общую кодовую базу сопровождать проще.

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

Что означают нативное, кросс-платформенное и веб-приложение?

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

Нативное приложение

При нативной разработке версии для iOS и Android создаются отдельно, на собственном языке и собственными средствами интерфейса каждой платформы. На iOS сегодня это, как правило, язык Swift и SwiftUI: по словам Apple, SwiftUI с декларативным синтаксисом, опираясь на язык Swift, позволяет строить интерфейс на всех платформах Apple (Apple: SwiftUI). На Android это Kotlin и Jetpack Compose: Google называет Jetpack Compose рекомендуемым современным набором инструментов Android для создания нативного интерфейса (Android Developers: Jetpack Compose) и советует начинать новое Android-приложение на Kotlin (Android Developers: Kotlin-first). Преимущество нативного пути в том, что каждая новая возможность платформы доступна напрямую с первого дня; недостаток же в том, что нужно разрабатывать и сопровождать две кодовые базы.

Кросс-платформенные фреймворки

С кросс-платформенными фреймворками приложения для iOS и Android создаются из общей кодовой базы. Четыре распространённых подхода:

Flutter: фреймворк на языке Dart. Согласно документации, Flutter сам реализует каждый элемент интерфейса вместо использования системных, а для отрисовки применяет движок Impeller; собственный код платформы можно вызывать через так называемый платформенный канал (Flutter: Architectural overview).
React Native: на основе React и JavaScript; по формулировке самого проекта, код пишется на JavaScript, но отображается нативно, потому что базовые компоненты сопоставляются с нативными строительными блоками интерфейса платформы (React Native). Начиная с версии 0.76 по умолчанию используется так называемая новая архитектура, которая заменяет асинхронный мост интерфейсом JavaScript Interface (JSI) (React Native: New Architecture).
Kotlin Multiplatform: технология JetBrains с открытым исходным кодом, позволяющая использовать общий код для Android, iOS, десктопа, веба и серверной стороны. Общей можно сделать только бизнес-логику, сохранив нативный интерфейс, или, с помощью Compose Multiplatform, и интерфейс (Kotlin: Kotlin Multiplatform). Согласно документации Kotlin, Compose Multiplatform имеет стабильный статус и на iOS (Kotlin: stability of supported platforms, проверено 17 октября 2026 года).
.NET MAUI: фреймворк Microsoft на C# и XAML для разработки приложений под Android, iOS, macOS и Windows из единой общей кодовой базы; развитие Xamarin.Forms. Для сборки приложений под iOS и macOS нужен Mac (Microsoft Learn: What is .NET MAUI?).

Прогрессивное веб-приложение (PWA)

PWA представляет собой работающее в браузере веб-приложение, которое можно установить на главный экран и которое за счёт постепенного расширения функций (progressive enhancement) работает надёжнее. Согласно обзору web.dev, сильнейшая сторона платформенных приложений заключается в их возможностях, тогда как веб-приложения выигрывают охватом: одна кодовая база доступна кому угодно на любом устройстве (web.dev: Progressive Web Apps). На iOS и iPadOS начиная с версии 16.4 веб-приложение, добавленное на экран «Домой», тоже может запрашивать разрешение на push-уведомления (WebKit: Web Push for Web Apps). Важное ограничение: согласно пункту 4.2 правил App Store, приложение должно давать больше, чем переупакованный веб-сайт, поэтому выносить в магазин сайт, просто обёрнутый в приложение, не стоит (Apple: App Store Review Guidelines).

Сравнение в одной таблице

Критерий	Нативное (Swift, Kotlin)	Кросс-платформенное (Flutter, React Native, KMP, .NET MAUI)	PWA
Производительность	оптимизируется напрямую средствами платформы	ресурсоёмкие части можно вынести в нативный код	определяется браузером и веб-технологиями
Доступ к устройству	все функции платформы, с первого дня	через фреймворк или плагин; новая функция появляется позже или требует дополнительного нативного кода	ограничен веб-интерфейсами, которые поддерживает браузер
Внешний вид и ощущения	в точности собственные элементы платформы	Flutter отрисовывает элементы сам, React Native использует нативные элементы	как у веб-сайта, зависит от браузера
Общий код	нет, две отдельные кодовые базы	общая логика и, как правило, интерфейс	одна кодовая база для всех устройств
Команда	отдельные специалисты по iOS и Android	одна команда, но нужны и знания нативных слоёв	команда веб-разработчиков
Сопровождение	две кодовые базы следуют за регулярными изменениями платформ	одна кодовая база плюс собственные обновления фреймворка	нет выпусков в магазинах, нужно следить за изменениями браузеров
Размер приложения	опирается на собственные библиотеки системы	в приложение попадает и движок фреймворка	нет установочного пакета, браузер кэширует
Присутствие в магазинах	да	да	не требуется; при упаковке для магазина действует ограничение пункта 4.2

Документация Flutter прямо говорит, что пакет Flutter-приложения самодостаточен и содержит весь код и все ресурсы, нужные для работы, поэтому его размер может иметь значение (Flutter: Measuring your app's size). На практике эта разница редко бывает решающей, но о ней стоит знать, если целевая аудитория пользуется приложением на старых устройствах или при слабом соединении.

Когда что подходит?

Нативное, если

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

Кросс-платформенное, если

на обеих платформах одни и те же функции и важно, чтобы изменения появлялись одновременно;
приложение в основном состоит из форм, списков, отображения данных и уведомлений, как большинство бизнес-приложений;
приложение долгосрочно сопровождает одна команда;
компания уже использует язык фреймворка: например, опыт с React в вебе ведёт к React Native, а опыт в .NET ведёт к .NET MAUI.

PWA или веб-приложение, если

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

Границы и здесь не резкие. С Kotlin Multiplatform, например, бизнес-логика может быть общей, а интерфейс остаётся нативным; во Flutter и React Native отдельную критичную часть можно написать и на нативном коде. Игра на нашем собственном сайте работает как веб-приложение: она запускается в браузере без установки, одинаково на компьютере и на телефоне. О веб-пути мы пишем на странице Создание сайтов и разработка веб-приложений.

Серверная часть и панель администратора

Мобильное приложение редко существует само по себе. Как только у него появляются учётные записи пользователей, общие данные или уведомления, за ним нужен сервер: там хранятся учётные записи, данные и права доступа, и оттуда отправляются уведомления. Push-уведомления серверная часть, как правило, отправляет через специальный сервис; Firebase Cloud Messaging, например, представляет собой кросс-платформенное решение для обмена сообщениями, в котором доверенная серверная среда формирует и отправляет сообщения приложениям для Apple, Android и веба (Firebase: Cloud Messaging).

Панель администратора выполняет роль пульта управления серверной частью: в браузере можно редактировать контент, управлять пользователями и настройками, чтобы для повседневных изменений не требовался разработчик. Сюда же мы подключаем существующие корпоративные системы (CRM, складской учёт или сервис выставления счетов), чтобы приложение работало с теми же данными, что и остальная компания. Если такой системы ещё нет, мы создадим и её как заказное ПО. Выбор между нативной и кросс-платформенной разработкой на серверную часть не влияет: один и тот же сервер может обслуживать и нативное приложение, и приложение на Flutter.

Публикация в магазинах приложений: на что обратить внимание в октябре 2026 года?

Правила магазинов приложений часто меняются, поэтому сведения ниже приводятся с датой (проверено 17 октября 2026 года).

App Store (Apple)

Правила проверки: App Store Review Guidelines последний раз обновлялись 16 октября 2026 года. Согласно пункту 2.1, на проверку нужно отправлять готовую, полную версию; если в приложении есть вход, нужно предоставить демо-аккаунт, а серверная часть должна работать и во время проверки. Согласно пункту 5.1.1, каждое приложение должно ссылаться на свою политику конфиденциальности, а если приложение позволяет создать учётную запись, оно должно предлагать и её удаление внутри приложения (Apple: App Store Review Guidelines).
Сведения о конфиденциальности: в App Store Connect нужно указать, как приложение обрабатывает данные, в том числе встроенные сторонние компоненты (например, аналитические SDK); это требуется для отправки и нового приложения, и обновления (Apple: App privacy details).
Требование к инструментам разработки: с 28 апреля 2026 года приложения, загружаемые в App Store Connect, нужно собирать в Xcode 26 или новее с iOS 26 SDK, а с 9 сентября 2026 года целевая версия приложений для iOS и iPadOS должна быть не ниже iOS 13 (Apple: Upcoming requirements).
Аккаунт компании: для регистрации в качестве организации компания должна быть юридическим лицом и иметь номер D-U-N-S, а регистрирующий должен иметь право принимать обязательства от имени компании (Apple: Enrollment).
Статус торговца в ЕС: Apple просит разработчика заявить, считается ли он торговцем (trader) по праву ЕС; контактные данные торговцев в ЕС отображаются на странице приложения в магазине (Apple: Digital Services Act trader requirements).

Google Play

Целевой уровень API: с 31 августа 2026 года новые приложения и обновления для телефонов должны быть ориентированы как минимум на Android 16 (уровень API 36); существующие приложения должны быть ориентированы как минимум на Android 15 (уровень API 35), чтобы оставаться доступными новым пользователям на устройствах с более новыми версиями Android. При продлении, запрошенном в Play Console, крайним сроком является 1 ноября 2026 года (Android Developers: Target API level).
Тестирование для личных аккаунтов: для личных аккаунтов разработчика, созданных после 13 ноября 2023 года, перед публикацией рабочей версии нужно провести закрытое тестирование минимум с 12 тестировщиками, которые непрерывно участвуют в нём не менее 14 дней (Play Console Help: testing requirements).
Аккаунт организации: аккаунт разработчика для организации нельзя создать без номера D-U-N-S (Play Console Help: creating an account).
Форма безопасности данных: её нужно заполнить для каждого приложения, опубликованного в Google Play, даже если приложение не собирает пользовательские данные (Play Console Help: Data safety).
Удаление учётной записи: если в приложении можно создать учётную запись, запросить удаление учётной записи и связанных данных должно быть можно и внутри приложения, и по веб-ссылке (Play Console Help: account deletion requirements).

Эти правила действуют независимо от технологии: приложение на Flutter или React Native должно выполнять те же требования к целевому API и SDK, что и нативное, и обновления фреймворка должны за ними поспевать. Мы рекомендуем, чтобы аккаунт разработчика принадлежал компании заказчика: тогда приложение выходит под названием вашей компании, а страница приложения в магазине тоже остаётся за компанией.

Доступность

Обе платформы работают со встроенной программой чтения с экрана (VoiceOver на iOS, TalkBack на Android) и предоставляют интерфейсы, через которые приложения взаимодействуют с этими вспомогательными технологиями (React Native: Accessibility). Документация Flutter, например, рекомендует, чтобы программа чтения с экрана понятно описывала каждый элемент управления, контрастность текста и фона составляла не менее 4,5:1, а каждый элемент, которого можно коснуться, был не меньше 48×48 пикселей (Flutter: Accessibility). Документация Android рекомендует для выявления проблем руководство Material Design, инструмент Accessibility Scanner и автоматические проверки (Android Developers: Accessibility).

Это не только хорошая практика: согласно Директиве (ЕС) 2019/882, государства-члены ЕС с 28 июня 2025 года должны применять требования доступности к услугам электронной торговли для потребителей, в том числе к оказываемым через мобильные приложения (венгерские правила основаны на транспонировании директивы); микропредприятия, оказывающие услуги, должны освобождаться от этих требований (EUR-Lex: Директива (ЕС) 2019/882). Подробности для интернет-магазинов разобраны в статье Интернет-магазин: арендуемая платформа или заказная разработка?

Искусственный интеллект: на устройстве или в облаке?

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

На устройстве (Apple): фреймворк Foundation Models от Apple начиная с iOS 26 даёт доступ к моделям, созданным для Apple Intelligence и работающим на устройстве и в Private Cloud Compute; его можно использовать для генерации текста, структурированного вывода и вызова собственных инструментов, но только на устройствах с поддержкой Apple Intelligence (Apple: Foundation Models).
На устройстве (Android): Gemini Nano работает в системном сервисе Android AICore и доступен через интерфейсы ML Kit GenAI, например для реферирования, исправления текста, перефразирования и описания изображений. По данным Google, он работает и без сети, а конфиденциальные данные остаются на устройстве, но возможности модели ограничены лимитом токенов и аппаратным обеспечением устройства (Android Developers: Gemini Nano).
В облаке: большие языковые модели OpenAI (ChatGPT), Anthropic (Claude) и Google (Gemini) для более сложных задач: ассистент на основе собственных материалов компании, обработка документов и изображений, резюмирование. Ключ доступа к ИИ-сервису хранится в серверной части, а не на телефоне: так его нельзя извлечь из приложения, а использование можно контролировать на сервере.

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

От чего зависит сопровождение?

Мобильное приложение не становится окончательно готовым и после передачи: его окружение постоянно меняется. Объём работ по сопровождению определяют главным образом:

Требования операционных систем и магазинов приложений: Apple требует для загрузки более новые версии Xcode и SDK, а Google Play ждёт более высокого целевого уровня API; даты выше показывают, что эти планки регулярно поднимаются.
Изменения правил магазинов: новые декларации о конфиденциальности, правила удаления учётных записей или тестирования.
Обновления фреймворка: в кросс-платформенном приложении смена основной версии Flutter, React Native или .NET MAUI может потребовать работы в собственном коде и в используемых плагинах.
Сторонние компоненты: платёжные, картографические, аналитические SDK, у которых тоже есть требования к обновлениям.
Серверная часть и интеграции: изменения интерфейсов подключённых корпоративных систем и ИИ-сервисов.
Число кодовых баз: два нативных приложения требуют изменений в двух местах.

Частые ошибки

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

Частые вопросы

Нативная разработка или Flutter/React Native?

Если приложение глубоко использует устройство (камеру, датчики, фоновые процессы) или требует высокой производительности, надёжнее выбрать нативную разработку. Если на обеих платформах одни и те же функции, приложение с общей кодовой базой на Flutter или React Native проще сопровождать. С Kotlin Multiplatform возможен и промежуточный путь: общая бизнес-логика, нативный интерфейс. На первой консультации мы дадим рекомендацию на основе конкретных функций.

Когда достаточно веб-приложения (PWA)?

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

Нужна ли серверная часть?

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

Кто публикует приложение в магазинах?

Публикацию берём на себя мы: готовим материалы для страницы в магазине и декларации о конфиденциальности, отправляем приложение и сопровождаем его на протяжении всей проверки. Мы рекомендуем, чтобы аккаунт разработчика принадлежал вашей компании; для аккаунта организации оба магазина требуют номер D-U-N-S, поэтому его стоит получить заблаговременно.

От чего зависит стоимость сопровождения?

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

Как мы можем помочь?

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

Функциональный размер разработки мы измеряем в функциональных точках COSMIC (ISO/IEC 19761), и на его основе составляются предложение и график работ. Первая консультация бесплатна, по запросу мы заключаем соглашение о неразглашении (NDA), а после передачи также берём на себя эксплуатацию и сопровождение. Вопросы исходного кода и прав на использование регулируются договором. Опишите свою идею в нескольких предложениях и свяжитесь с нами.