Нативная vs кроссплатформенная разработка

iOS App Store - 1.7 миллиона приложений. Google Play - 3.5 миллиона. Каждое создавалось командой с конкретным выбором: нативный Swift/Kotlin, Flutter, React Native или гибрид. Airbnb сделал ставку на React Native, потратил 2 года - и вернулся на натив. Shopify сделал то же самое и остался. Правильного ответа нет. Есть контекст.

• **Airbnb и React Native**: 2016-2018 - масштабный эксперимент; в 2018 вернулись на нативный из-за сложности синхронизации iOS/Android поведения
• **Shopify**: остался на React Native и доволен - e-commerce паттерны хорошо ложатся на JS-стек
• **Flutter в Google/Alibaba**: Google Pay, Xianyu (Alibaba) - pixel-perfect UI на 6 платформах из одного кодбейза
• **Netflix + Kotlin Multiplatform**: shared бизнес-логика (сеть, аналитика, A/B), нативный UI - лучший UX без дублирования логики

Native

Нативная разработка - создание приложений родными инструментами платформы. iOS: Swift + UIKit/SwiftUI + Xcode. Android: Kotlin + XML Views/Jetpack Compose + Android Studio. Приложение компилируется напрямую в машинный код. SwiftUI (2019) заменяет UIKit как современный стандарт, но UIKit до сих пор живёт в 90% legacy-кода - знать оба обязательно.

**Нативная разработка** означает: - **iOS:** Swift (или Objective-C), SwiftUI / UIKit, Xcode - **Android:** Kotlin (или Java), Jetpack Compose / XML Views, Android Studio - Полный доступ ко всем API платформы без мостов и обёрток - Максимальная производительность: прямой вызов системных API

Главное преимущество: нативные приложения «ощущаются» как часть ОС. Анимации, жесты, системные элементы (share sheet, notifications, widgets) работают без компромиссов. День релиза iOS 18 - нативное приложение может использовать новые API немедленно. Кроссплатформа ждёт, пока фреймворк выпустит обёртку.

Главный минус: **два отдельных кодбейза**. Фича, написанная на Swift для iOS, должна быть переписана на Kotlin для Android. Это удваивает стоимость разработки и создаёт риск расхождения функциональности между платформами.

Cross Platform

Кроссплатформенные фреймворки решают ключевую проблему нативной разработки: один код → два (или больше) приложения. Три лидера рынка - React Native, Flutter и Kotlin Multiplatform - используют принципиально разные архитектурные подходы.

**Кроссплатформенная разработка** - один кодбейс, компилируемый/транслируемый для нескольких платформ: - **React Native** (Meta): JavaScript/TypeScript, рендерит нативные компоненты через мост - **Flutter** (Google): Dart, собственный rendering engine (Skia/Impeller), рисует каждый пиксель - **Kotlin Multiplatform** (JetBrains): общая бизнес-логика на Kotlin, UI нативный на каждой платформе

**Flutter** выделяется тем, что вообще не использует нативные UI-компоненты. Движок Impeller (ранее Skia) рисует каждый пиксель самостоятельно, достигая 120 FPS. Это даёт pixel-perfect одинаковый вид на обеих платформах, но приложение может «ощущаться» не совсем нативно.

**Kotlin Multiplatform** - самый гибкий подход: бизнес-логика (сеть, БД, модели) общая, а UI пишется нативно на каждой платформе (SwiftUI + Compose). Меньше shared code, но максимально нативный UX. Netflix выбрал KMP именно для этого.

Hybrid

Гибридные приложения - третий подход: веб-приложение, «обёрнутое» в нативный контейнер. По сути это WebView (встроенный браузер) с доступом к нативным API через JavaScript-мост.

**Гибридная разработка:** - Код пишется на HTML/CSS/JavaScript - как обычный сайт - Запускается в WebView внутри нативного приложения - Нативный «мост» даёт доступ к камере, GPS, файловой системе - Фреймворки: **Ionic**, **Capacitor**, **Apache Cordova** (устаревший)

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

Недостаток: **производительность** ограничена WebView. Сложные анимации, длинные списки, тяжёлая графика - всё работает медленнее, чем в нативных или кроссплатформенных приложениях. Пользователи чувствуют «задержку» при скролле и переходах.

Tradeoffs

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

**Когда выбрать нативный:** приложение с тяжёлой графикой (игры, AR/VR), сложными анимациями, глубокой интеграцией с ОС (виджеты, Siri Shortcuts, App Clips). Примеры: банковские приложения, мессенджеры уровня iMessage.

**Когда выбрать кроссплатформенный:** типичное бизнес-приложение, маркетплейс, социальная сеть. Один кодбейз экономит 30-50% бюджета. Flutter - если важен идентичный UI на обеих платформах. React Native - если команда из веб-разработчиков. KMP - если критичен нативный UX.

**Когда выбрать гибридный:** MVP/прототип, внутреннее корпоративное приложение, обёртка над существующим веб-сервисом. Команда - веб-разработчики, бюджет минимальный, UX не критичен.

Реальный тренд 2024: крупные компании идут в разные стороны. Airbnb - нативный. Shopify - React Native. Google Pay, BMW, Alibaba - Flutter. Netflix, Cash App - KMP. Правильного ответа нет: есть контекст команды, требования UX и техдолг. Airbnb потратил 2 года на React Native и вернулся - потому что их продукт требует сложных нативных анимаций и глубокой интеграции с ОС, которых JS-мост не тянет.

Ключевые идеи

• **Нативный** (Swift+SwiftUI / Kotlin+Compose) - лучший UX, день-в-день поддержка новых API ОС, два кодбейза
• **Flutter** (Dart, Skia/Impeller, 120fps) - pixel-perfect UI на 6 платформах; Google Pay, BMW, Alibaba в продакшне
• **React Native** (TypeScript, нативные компоненты через мост) - JS-команды пишут нативный look; Shopify доволен, Airbnb ушёл
• **KMP** (Kotlin, shared logic + нативный UI) - Netflix, Cash App; минимум дублирования бизнес-логики
• **Гибридный** (Ionic/Capacitor) - веб в WebView; MVP за дни, UX страдает при сложных анимациях

Связанные темы

Понимание подходов к разработке - основа для изучения конкретных технологий:

• Жизненный цикл мобильных приложений — Все подходы должны учитывать lifecycle ОС - foreground, background, уничтожение процесса
• Swift и SwiftUI — Конкретный стек нативной iOS-разработки - язык, UI-фреймворк, concurrency

Вопросы для размышления

• Если бы вы начинали стартап сегодня, какой подход выбрали бы и почему?
• Почему Airbnb отказался от React Native, а Shopify - нет? Какие факторы могли повлиять на решение?
• Как появление Kotlin Multiplatform меняет ландшафт - может ли он заменить Flutter и React Native?

Связанные уроки

• web-01 — Веб и мобильная разработка решают схожие задачи (UI, state, networking), но с разными ограничениями платформы
• net-01-intro — Мобильные приложения зависят от сети: HTTP, WebSocket, REST API - базовые знания необходимы
• se-01 — Паттерны проектирования (MVC, MVVM) применяются напрямую в архитектуре мобильных приложений
• mob-02 — Выбор платформы определяет, как работать с lifecycle приложения
• comp-01-intro