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

Чем нативная разработка на Swift и Kotlin отличается от Flutter и React Native: производительность, доступ к возможностям устройства, команда, поддержка, типичные сценарии для каждого подхода и вопросы, которые стоит задать до выбора.

Один из первых технических вопросов в любом проекте мобильного приложения — писать ли отдельно под iOS и Android на родных для каждой платформы языках или сделать одно приложение на кроссплатформенном фреймворке, которое будет работать на обеих. Ответ влияет на бюджет, сроки, состав команды, качество интерфейса, доступ к возможностям устройства и то, насколько легко будет развивать продукт через три года. Вокруг этого выбора много устаревших аргументов. «Кроссплатформенные приложения тормозят» было правдой для ранних гибридных решений на веб-технологиях, но плохо описывает современные фреймворки. «Нативная разработка всегда в два раза дороже» тоже упрощение: стоимость зависит от того, какая часть приложения действительно может быть общей. Ниже — чем подходы отличаются на самом деле, какие у каждого сильные и слабые стороны, для каких сценариев подходит каждый и какие вопросы стоит задать до того, как выбор будет зафиксирован в договоре. Отдельный вариант — прогрессивное веб-приложение, которое работает в браузере и устанавливается на экран без магазина приложений. Его сравнение с нативным приложением мы разбирали в статье о Progressive Web Apps , здесь речь только о приложениях, которые публикуются в магазинах. Подходы: что есть на рынке Нативная разработка Два отдельных приложения: для iOS на Swift с интерфейсом на SwiftUI или UIKit, для Android на Kotlin с интерфейсом на Jetpack Compose или классических View. Каждое использует инструменты и компоненты, которые платформа предоставляет разработчикам напрямую. Серверная часть и API обычно общие. Flutter Фреймворк от Google на языке Dart. Отрисовывает интерфейс собственным графическим движком, не используя стандартные компоненты платформы. Благодаря этому приложение выглядит одинаково на всех устройствах, а интерфейс с нестандартной анимацией и графикой реализуется предсказуемо. Из того же кода можно собрать веб- и десктопную версию, хотя их зрелость ниже мобильной. React Native Фреймворк, созданный в Meta, на JavaScript или TypeScript. Использует нативные компоненты платформы, управляя ими из JavaScript-кода. Близок к веб-разработке на React, что позволяет переиспользовать знания команды, часть логики и иногда часть кода с веб-версией продукта. Kotlin Multiplatform Подход, при котором общей делается бизнес-логика — работа с сетью, данными, правилами, — а интерфейс остаётся нативным для каждой платформы или строится на Compose Multiplatform. Промежуточный вариант между полностью нативной и полностью кроссплатформенной разработкой. Чем подходы отличаются на практике Производительность Для большинства бизнес-приложений — каталог, личный кабинет, формы, списки, карточки, чат — современные кроссплатформенные фреймворки дают плавный интерфейс, неотличимый для пользователя от нативного. Разница проявляется в требовательных сценариях: сложные анимации и жесты с большим числом элементов; обработка видео и изображений в реальном времени; дополненная реальность, работа с камерой на низком уровне; большие объёмы данных, обрабатываемых на устройстве; игры и насыщенная графика. Даже в этих случаях кроссплатформенное приложение может вынести тяжёлую часть в нативный модуль. Но если таких частей много, преимущество общего кода уменьшается. Доступ к возможностям устройства Камера, геолокация, push-уведомления, биометрия, платежи — всё это доступно в кроссплатформенных фреймворках через готовые библиотеки. Сложности начинаются там, где нужны: новые функции операционной системы в первые месяцы после выхода — нативная разработка получает их сразу, для кроссплатформенных фреймворков поддержка появляется позже; виджеты на рабочем столе, приложения для часов, интеграция с системными экранами; длительная работа в фоне, Bluetooth-устройства, специализированное оборудование; глубокая интеграция с системными сервисами — голосовыми помощниками, системой файлов, другими приложениями. Всё это реализуемо и в кроссплатформенном приложении через нативные модули, но каждая такая часть пишется отдельно под каждую платформу. Интерфейс и соответствие платформе Пользователи iOS и Android привыкли к разным жестам навигации, расположению элементов, поведению списков и системным диалогам. Нативное приложение соответствует этим ожиданиям естественно. Flutter по умолчанию рисует одинаковый интерфейс, и адаптация под платформенные особенности требует отдельных решений. React Native использует нативные компоненты, поэтому ближе к платформенному поведению, но единый код интерфейса тоже склоняет к одинаковому дизайну. Для многих продуктов единый фирменный интерфейс на обеих платформах — не недостаток, а осознанное решение. Для приложений, где пользователь ожидает «родного» поведения — системные утилиты, приложения для работы с настройками устройства, — нативный подход предпочтительнее. Скорость разработки и общий код Главный аргумент кроссплатформенной разработки — одна кодовая база вместо двух. На практике общими оказываются интерфейс, бизнес-логика, работа с сетью и данными. Отдельно под платформы пишутся нативные модули, настройки сборки, особенности публикации и те места, где платформы ведут себя по-разному. Доля общего кода зависит от приложения: чем больше в нём стандартных экранов и чем меньше специфичных возможностей устройства, тем выше выгода. Поэтому оценивать экономию нужно по конкретному списку функций, а не по общему правилу. Команда Нативная разработка требует специалистов по каждой платформе. Две команды нужно синхронизировать: одна функция реализуется дважды, и выпуск на двух платформах может расходиться по времени. Flutter требует разработчиков на Dart — язык используется в основном во Flutter, поэтому рынок специалистов уже, чем для JavaScript, но стабильно растёт. React Native позволяет привлечь разработчиков с опытом React. Для сложных задач всё равно нужны люди, понимающие нативную разработку. Kotlin Multiplatform естественен для команды, где уже есть Android-разработчики, и требует специалистов по iOS для интерфейса. В любом кроссплатформенном проекте полезно иметь в команде хотя бы одного человека, глубоко понимающего каждую из платформ: проблемы публикации, сертификатов, разрешений и системных ограничений не решаются знанием фреймворка. Долгосрочная поддержка Мобильное приложение живёт годами, а операционные системы выходят каждый год. Нативное приложение зависит от одной платформы и её инструментов. Кроссплатформенное — ещё и от фреймворка и десятков сторонних библиотек, каждая из которых должна успевать за обновлениями систем. Библиотека, которую перестали поддерживать, может заблокировать обновление всего приложения. При выборе кроссплатформенного подхода стоит оценить зрелость и активность поддержки ключевых библиотек, которые понадобятся проекту. Размер приложения и время запуска Кроссплатформенное приложение включает среду выполнения фреймворка, поэтому минимальный размер установочного файла больше, чем у простого нативного. Для большинства продуктов разница несущественна, но для приложений, ориентированных на слабые устройства или медленный интернет, её стоит учитывать. Выпуск обновлений Каждое обновление мобильного приложения проходит модерацию в магазинах, а пользователи устанавливают его не сразу. Поэтому в продакшене одновременно работают несколько версий приложения, и серверная часть должна поддерживать их все. Нативная разработка: выпуск на iOS и Android — два отдельных процесса сборки и публикации. Если команды не синхронизированы, одна платформа получает функцию раньше другой. Кроссплатформенная разработка: одна сборка кода на обе платформы, выпуск проще синхронизировать. Для React Native существуют механизмы обновления части кода без публикации новой версии в магазине, но их применение ограничено правилами магазинов: менять таким способом основную функциональность приложения нельзя. Любой подход: нужны механизм принудительного обновления для несовместимых изменений API, флаги функций для включения возможностей без нового выпуска и мониторинг ошибок по версиям приложения. Когда что выбирать Кроссплатформенная разработка подходит, если приложение состоит в основном из стандартных экранов: каталог, карточки, формы, личный кабинет, лента, чат; важно запустить обе платформы одновременно и развивать их синхронно; дизайн продукта единый для iOS и Android; бюджет ограничен, а продукт на стадии проверки гипотезы; у команды уже есть опыт React или Flutter; приложение — один из каналов продукта, у которого есть и веб-версия. Нативная разработка подходит, если ключевые функции завязаны на возможности устройства: камера, AR, Bluetooth, фоновые процессы, виджеты, часы; критичны производительность и плавность в сложных интерфейсах; важно поддерживать новые функции операционных систем сразу после их выхода; приложение работает с чувствительными данными и требует максимального контроля над безопасностью и зависимостями; продукт рассчитан на долгую жизнь, и компания готова содержать экспертизу по обеим платформам; пользователь ожидает поведения, полностью соответствующего платформе. Гибридные варианты Общая логика, нативный интерфейс — Kotlin Multiplatform, когда важен родной интерфейс, но не хочется дважды писать бизнес-правила и работу с данными. Кроссплатформенное приложение с нативными модулями для отдельных требовательных частей. Нативное приложение с кроссплатформенными экранами — встраивание отдельных разделов, например часто меняющегося каталога, в существующее нативное приложение. Примеры из практики В нашем портфолио есть проекты обоих типов, и это хорошо иллюстрирует, что правильный ответ зависит от продукта, а не от предпочтений команды. Показатели ниже — из опубликованных кейсов. Мобильное приложение финансовых услуг — нативная разработка на Swift и Kotlin с интерфейсами на SwiftUI и Jetpack Compose, биометрической авторизацией и push-уведомлениями. 150 000+ установок за 6 месяцев, рейтинг 4,8 в App Store и Google Play; 65% пользователей предпочитают приложение веб-версии. Кейс . Приложение для клиентов юридической компании — нативная разработка на Swift и Kotlin: этапы процедуры, документы и график платежей, чат с юристом, вход по SMS-коду и далее по биометрии, единый контур с веб-кабинетом. Кейс . Маркетплейс детских товаров — React Native: навигация по возрасту, AI-подбор подарков, умные фильтры. 500 тыс.+ активных родителей, 2 млн+ заказов, 4,8 в App Store. Кейс . Музыкальный стриминг с AI-рекомендациями — React Native: персональное радио и адаптивный стриминг. 2 млн+ активных пользователей, 100 млн+ прослушиваний в месяц, 4,9 в App Store. Кейс . Два последних примера показывают, что кроссплатформенное приложение способно работать на аудитории в миллионы пользователей с высокими оценками. Два первых — что для приложений с финансовыми и юридически значимыми данными, биометрией и глубокой интеграцией с системой разумно выбирают нативный путь. Вопросы, которые стоит задать до выбора Какие функции устройства нужны сейчас и через год? Составьте список. Если в нём много системных интеграций, это аргумент в пользу нативной разработки или гибрида. Насколько интерфейс стандартный? Экраны из типовых элементов или сложная анимация и графика? Нужны ли обе платформы одновременно? Если аудитория преимущественно на одной платформе, нативное приложение для неё может быть быстрее кроссплатформенного для двух. Есть ли веб-версия и насколько её логика совпадает с мобильной? Кто будет поддерживать приложение через два-три года? Своя команда, подрядчик, и какие специалисты доступны на рынке. Какие требования к безопасности и данным? Требования службы безопасности или регулятора могут ограничивать использование сторонних библиотек. Какие ключевые библиотеки понадобятся в кроссплатформенном варианте, и насколько активно они поддерживаются? Типичные ошибки выбора Выбор по моде Команда выбирает фреймворк, о котором сейчас больше пишут, не соотнося его с функциями конкретного продукта. Через полгода выясняется, что половина ключевых функций требует нативных модулей. Экономия, посчитанная в процентах, а не по функциям Решение принимается на основании общ