Кроссплатформенная разработка на React Native: одна кодовая база для мобильных, ТВ и не только

Каждая статья о React Native говорит одно и то же: он позволяет писать приложения для iOS и Android из одной кодовой базы. Это правда, но только половина истории. За 9+ лет я строил кроссплатформенные приложения — не только для телефонов, но и для Smart TV, приставок и стриминговых платформ на 80M+ зрителей. Кроссплатформенная разработка на React Native в 2026 — это 7+ платформ из одного монорепо. Расскажу, как это выглядит в продакшене.

React Native в 2026: больше чем мобильный фреймворк

Когда говорят «кроссплатформенность», обычно имеют в виду iOS и Android. Это определение устарело лет на пять. React Native сегодня работает на iOS, Android, tvOS, Android TV, Fire TV, Web, Windows, macOS и, с февраля 2026 — на Meta Quest VR.

Новая архитектура больше не опциональна. В RN 0.82 она стала обязательной — код старого моста физически удалён из скомпилированных бинарников в 0.84. Hermes V1 — движок по умолчанию, даёт ~55% более быстрый старт и 26% меньше потребления памяти по сравнению с JavaScriptCore. Библиотеки, зависящие от Bridge API, просто не скомпилируются.

О масштабах говорят цифры. Shopify — 86% унификации кода, на 59% быстрее загрузка экранов после миграции на новую архитектуру. Microsoft запускает 40+ интерфейсов Office на React Native для Windows, включая части Copilot. Discord, Coinbase, Call of Duty companion — все на React Native.

Но самое значимое для кроссплатформенной разработки — Amazon Vega OS. Запущена в октябре 2025, интегрирует React Native на уровне операционной системы — рантайм Hermes предзагружен и прогрет ОС, что даёт приложениям практически мгновенный холодный старт. Сейчас Vega работает на RN 0.72, что означает отдельную конфигурацию сборки. Но поддержка RN 0.82 ожидается в мае 2026 — и когда это случится, мы сможем целиться на Vega OS из того же монорепо, что и мобильные приложения. Это переломный момент.

Бизнес-кейс: почему одна кодовая база меняет экономику

Давайте на языке того, кто подписывает счета.

Контентное приложение на 7 платформ классическим способом — нативные iOS, Android, tvOS, Android TV/Fire TV и веб-приложение для Tizen (Samsung)/webOS (LG) — это 5 кодовых баз, потенциально 5 разных команд и 5 циклов отладки. Консервативная оценка для стримингового приложения средней сложности: $400K-600K и 6-9 месяцев.

С React Native и монорепо я пишу одну кодовую базу для всех пяти платформ. Бизнес-логика, управление состоянием, API-слой и модели данных пишутся один раз. Платформенно-специфичная работа — управление фокусом для ТВ, тач-взаимодействие для мобильных — занимает 20-40% усилий. На практике:

• Один senior-разработчик вместо 5 платформенных специалистов
• 3-4 месяца вместо 6-9
• Один набор тестов, один CI-пайплайн, один процесс деплоя
• Фиксы багов выкатываются на все платформы одновременно

Я выпускаю мобильные и ТВ-приложения как соло-разработчик. Это не теория — так выглядит мой рабочий день. AI-инструменты берут на себя бойлерплейт, а я фокусируюсь на архитектуре и платформенных edge cases, требующих реального опыта. Результат — скорость стартапа за долю стоимости агентства. Попробуйте калькулятор проекта для быстрой оценки.

Что реально шарится между мобильными и ТВ (а что — нет)

Цифра «60-80% переиспользования кода» звучит повсюду. Давайте конкретно.

Общие 60-80% — это почти целиком бизнес-логика и данные. Zustand-сторы, API-клиенты, модели данных, авторизация, фичефлаги, валидация — всё платформенно-агностично. Упрощённый пример стора, который работает одинаково на телефоне и телевизоре:

interface ContentStore {
  readonly items: readonly ContentItem[]
  readonly isLoading: boolean
  readonly error: string | null
  fetchItems: (categoryId: string) => Promise<void>
}

export const useContentStore = create<ContentStore>()(
  persist(
    (set) => ({
      items: [],
      isLoading: false,
      error: null,
      fetchItems: async (categoryId) => {
        set({ isLoading: true, error: null })
        const items = await api.getContent(categoryId)
        set({ items, isLoading: false })
      },
    }),
    { name: 'content-store', storage: createJSONStorage(() => AsyncStorage) }
  )
)

Этот стор работает везде без единой строчки платформенного кода. Хуки, утилиты, весь сетевой слой — аналогично.

Платформенные 20-40% непропорционально дороги, потому что именно они определяют, чувствует ли пользователь нативное приложение или плохой порт:

• Управление фокусом и пространственная навигация. На мобильных тапают куда хотят. На ТВ навигация крестовиной — вверх, вниз, влево, вправо, ОК, назад. Каждый фокусируемый элемент требует явных пространственных связей.
• Обработка ввода. Кнопка «назад» на Samsung Tizen — keycode 10009. На LG webOS — 461. На tvOS — жесты Siri Remote. Для каждой платформы нужна своя обработка.
• Размеры и масштаб. Экран телефона — 375px на расстоянии вытянутой руки. ТВ — 1920px на расстоянии 3 метров. Шрифты, отступы, области фокуса — всё другое.
• Анимации. Телефон с 8 ГБ RAM переварит 10 параллельных анимаций. ТВ с 512 МБ — одну, и хорошо бы GC не дёрнулся.

Пропорция зависит от продукта. Каталог контента (фильмы, ТВ-программы) тяготеет к 80% общего кода. Интерактивное приложение с живыми фичами — ближе к 55-60%. Но даже 55% — это одна кодовая база вместо пяти.

React Native vs Flutter: фактор Smart TV, о котором не пишут

Каждое сравнение React Native с Flutter рассматривает их как мобильные фреймворки. Flutter лидирует по рыночной доле — 46% против 35% у React Native. Impeller-рендеринг даёт отличную производительность анимаций. Для чисто мобильного продукта — достойный выбор.

Но если продукту нужно работать на телевизоре — сравнение заканчивается, не начавшись.

У React Native — зрелая ТВ-экосистема. Amazon построил на нём целую операционную систему. DIRECTV выпускает своё ТВ-приложение на нём. Форк react-native-tvos следует за основными релизами. Expo поддерживает сборку для ТВ официально.

У Flutter поддержка ТВ — экспериментальная. Нет официального ТВ-фреймворка, ни одна крупная стриминговая платформа не использует Flutter для ТВ, усилия сообщества разрозненны.

Kotlin Multiplatform — более интересный конкурент: утроил adoption до 23%, Airbnb выбрал его для общей бизнес-логики. Но KMP шарит логику, не UI. Для команды, которая хочет переиспользовать весь компонентный слой между мобильными и ТВ, React Native — единственный фреймворк, который реально работает в продакшене.

Если выбираете стек для мультиплатформенного продукта — прочитайте мой пост о том, что на самом деле представляет разработка под Smart TV.

Архитектура: как один проект собирается на 7+ платформ

Вот структура монорепо, которую я использую:

├── apps/
│   ├── expo/          # iOS, Android, tvOS, Android TV, Fire TV
│   └── web/           # Samsung Tizen, LG webOS
├── packages/
│   ├── platform/      # Определение устройства, keycodes, возможности
│   ├── uikit/         # Focus-aware UI-компоненты
│   ├── shared/        # Хуки, стейт, API-клиент, навигация
│   └── theme/         # Дизайн-токены через React Context
└── turbo.json

Направление зависимостей — осознанный выбор. uikit зависит от platform и theme. shared зависит от platform. Приложения зависят от всех четырёх. Обратных зависимостей нет. При изменении keycode-маппинга пересобираются только platform и его потребители — кеширование Turborepo делает остальное.

Пакет platform — антикоррупционный слой. Абстрагирует зоопарк устройств через API на основе возможностей:

// Samsung Tizen keycodes
export const tizenKeyCodes: KeyCodes = {
  ENTER: [13],
  BACK: [10009],   // Уникальная кнопка назад Samsung
  RED: [403],      // Цветные кнопки на пульте
  GREEN: [404],
}

// LG webOS keycodes  —  совершенно другие
export const webosKeyCodes: KeyCodes = {
  ENTER: [13],
  BACK: [461],     // Код назад LG
  RED: [403],
  GREEN: [404],
}

Мы программируем под возможности, а не под названия платформ. Пакет предоставляет PlatformCapabilities — hasColorButtons, maxResolution, hasVoiceControl — и UI адаптируется к тому, что реально умеет пульт. Определение платформы — сначала нативные API (tizen.systeminfo, webOS.platform, Platform.isTV), UA-парсинг как фоллбэк.

Стратегия двойной сборки. Expo с форком react-native-tvos — для нативных платформ (tvOS, Android TV). Vite с react-native-web — для веб-ТВ (Tizen, webOS). Платформенные расширения файлов — .tizen.tsx, .webos.tsx, .web.tsx — резолвятся при сборке. Один компонент может иметь общую версию и платформенные оверрайды, бандлер выбирает нужный автоматически.

Реальные грабли: чему я научился, выпуская приложения на телефоны и ТВ

Управление фокусом — это архитектура, а не виджет. Главное заблуждение о ТВ-разработке. На мобильных навигация решена — стек, табы, дравер. На ТВ пространственная навигация — сквозная проблема, затрагивающая всё приложение.

Когда пользователь нажимает ВНИЗ на карусели hero-контента, система фокуса должна вычислить, какой элемент в рейле ниже получит фокус. Это зависит от горизонтальной прокрутки рейла, ширины текущего hero-элемента и того, завершился ли лейаут рейла. Ошибёшься — фокус прыгает на непредсказуемый элемент на другом краю экрана.

Фокусу нужен стек истории — не просто текущее состояние, а возможность восстановить фокус при навигации назад. Это определяет стратегию тестирования: ТВ-приложение нельзя тестировать кликами, нужна симуляция D-pad-последовательностей. И это основное бутылочное горлышко производительности — обход сетки из 200 элементов для поиска ближайшего соседа должен уложиться в 16 мс, иначе интерфейс ощущается сломанным.

Каждый компонент в нашем UIKit объявляет, фокусируемый ли он, определяет свои пространственные границы и знает, как анимировать переходы фокуса. Это отличает «React Native приложение на ТВ» от «ТВ-приложения, построенного на React Native».

Память — невидимый потолок. У телефона 6-8 ГБ RAM. У Smart TV — 512 МБ — 1.5 ГБ, и приложение получает лишь часть. Тот же React Native код, который летает на iPhone, уронит Samsung TV через 10 минут, если не виртуализировать списки и не управлять памятью картинок. Подробнее — в моём посте о проблемах Smart TV.

Форк react-native-tvos — управляемый риск. Использование "react-native": "npm:react-native-tvos@..." как npm-алиаса создаёт трение при обновлениях — каждый новый Expo SDK требует совместимый релиз форка. Мы хеджируем: фиксируем версии и запускаем отдельный пайплайн валидации обновлений. Экосистема стабильнее, чем 2 года назад (Expo SDK 54+ с RNTV 0.81 работает хорошо), но это стоимость, которую надо закладывать.

Анимации на ТВ требуют другого мышления. Focus-driven анимации должны координироваться с состоянием фокуса, которое живёт в JavaScript. Это означает осознанный выбор JS-driven анимаций для переходов фокуса — компромисс между архитектурной простотой и количеством кадров в секунду. React Native Reanimated 3.x во многом решает это, обеспечивая нативную производительность при чтении JS-стейта, но проектировать под это нужно с первого дня.

Как AI делает это возможным для одного разработчика

Выпускать продукты на 7+ платформ как соло-разработчик — ещё пару лет назад звучало абсурдно. AI-разработка изменила расклад.

Claude, Cursor, Copilot берут на себя бойлерплейт, который раньше съедал полдня. Скаффолдинг нового Zustand-стора, написание тест-сьютов, генерация платформенных конфигов — задачи по 30-40 минут превращаются в 5 минут ревью.

Но AI не заменяет экспертизу. Он не решит, что управлению фокусом нужен стек истории. Не знает, что кнопка «назад» на Samsung Tizen — keycode 10009. Не подскажет виртуализировать всё, потому что WebView телевизора получает 200 МБ RAM. Это 9+ лет доменных знаний, которые делают вывод AI полезным, а не правдоподобным, но незаметно ошибочным.

Комбинация — глубокая платформенная экспертиза плюс AI-ускорение — позволяет одному senior-разработчику конкурировать с командами агентств. Экспертиза задаёт архитектуру. AI заполняет реализацию.

Нужно React Native приложение для телефонов и Smart TV?

Если вы строите продукт, который должен работать и на мобильных, и на ТВ — стриминговый сервис, контентную платформу, приложение для live-событий — это именно то, чем я занимаюсь. Я строил OTT-платформы на 80M+ зрителей на 15+ типах устройств и выпускаю мобильные React Native приложения с той же архитектурой монорепо. Нужно кроссплатформенное приложение с нуля или расширить существующее мобильное на Smart TV — дам честную оценку. Запишитесь на бесплатный 30-минутный звонок или попробуйте калькулятор проекта для быстрой оценки.