React Native Cross-Platform Development: One Codebase for Mobile, TV, and Beyond

Every article about React Native says the same thing: it lets you build iOS and Android apps from one codebase. That's true, but it's only half the story. I've spent 9+ years building cross-platform applications — not just for phones, but for Smart TVs, set-top boxes, and streaming platforms serving 80M+ viewers. React Native cross-platform development in 2026 means targeting 7+ platforms from a single monorepo. Here's what that actually looks like in production.

React Native in 2026: More Than a Mobile Framework

When people say "cross-platform," they usually mean iOS and Android. That definition is 5 years out of date. React Native now runs on iOS, Android, tvOS, Android TV, Fire TV, Web, Windows, macOS, and as of February 2026 — Meta Quest VR.

The New Architecture is no longer optional. RN 0.82 made it mandatory — the old bridge code is physically removed from compiled binaries in 0.84. Hermes V1 is the default engine, delivering ~55% faster startup times and 26% lower memory usage compared to JavaScriptCore. Libraries that still depend on bridge APIs simply will not compile.

Enterprise adoption tells the real story. Shopify reported 86% code unification with 59% faster screen loads after migrating to the New Architecture. Microsoft runs 40+ Office experiences on React Native for Windows, including parts of Copilot. Discord, Coinbase, and the Call of Duty companion app all ship on React Native.

But the most significant development for cross-platform is Amazon Vega OS. Launched in October 2025, it integrates React Native at the operating system level — the Hermes runtime is pre-loaded and pre-warmed by the OS, giving apps near-instant cold starts. Currently Vega ships with RN 0.72, which means maintaining a separate build configuration. But RN 0.82 support is coming in May 2026, and when it lands, we'll target Vega OS from the same monorepo as our mobile and other TV builds. That's a turning point for teams building cross-platform products.

The Business Case: Why One Codebase Changes the Economics

Let me put this in terms that matter to the person signing the check.

Building a content app for 7 platforms the traditional way — native iOS, native Android, native tvOS, native Android TV/Fire TV, and a web-based Tizen (Samsung)/webOS (LG) app — means 5 codebases, potentially 5 different teams, and 5 separate bug-tracking cycles. A conservative estimate for a mid-complexity streaming app: $400K-600K and 6-9 months.

With React Native and a monorepo architecture, I build one codebase that targets all five. Business logic, state management, API layer, and data models are written once. Platform-specific work — focus management for TV, touch interactions for mobile — accounts for 20-40% of the total effort. In practice:

• One senior developer instead of 5 platform specialists
• 3-4 months instead of 6-9
• One test suite, one CI pipeline, one deployment process
• Bug fixes ship to all platforms simultaneously

I ship mobile and TV apps as a solo developer. That's not theoretical — it's how I work daily. AI-powered workflows handle the boilerplate, while I focus on architecture and platform-specific edge cases that require real expertise. The result: startup-speed delivery at a fraction of agency cost.

What Code Gets Shared Between Mobile and TV (And What Doesn't)

The "60-80% code sharing" claim gets thrown around a lot. Let me be specific.

The shared 60-80% is almost entirely business logic and data. Zustand stores, API clients, data models, authentication flows, feature flags, validation — all platform-agnostic. A simplified example of a store that runs identically on phones and TVs:

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) }
  )
)

This store works everywhere without a single line of platform-specific code. Same for hooks, utilities, and the entire networking layer.

The platform-specific 20-40% is disproportionately expensive because it covers the parts that determine whether users feel the app is native or a bad port:

• Focus management and spatial navigation. On mobile, users tap what they want. On TV, they navigate with a D-pad. Every focusable element needs explicit spatial relationships. More on this below — it's an architectural concern, not a widget toggle.
• Input handling. Samsung Tizen's back button sends keycode 10009. LG webOS sends 461. tvOS uses a gesture-based Siri Remote. Each needs explicit handling.
• Layout and sizing. A phone screen is 375px wide at arm's length. A TV is 1920px wide at 3 meters. Font sizes, spacing, focus targets — everything changes.
• Animation strategies. A phone with 8 GB RAM handles 10 parallel animations. A TV with 512 MB gets one, and you hope the GC doesn't stutter.

The ratio depends on your product. A content browsing app (movie catalogs, channel guides) pushes toward 80% shared. An interactive app with live features drops to 55-60%. Even at 55%, that's one codebase instead of five.

React Native vs Flutter: The TV Factor Nobody Mentions

Every "React Native vs Flutter" comparison frames them as mobile frameworks. Flutter leads in market share — 46% to React Native's 35%. Flutter's Impeller rendering engine delivers excellent animation performance. For a mobile-only product, it's a legitimate choice.

But if your product needs to run on a TV, the comparison ends before it starts.

React Native has a production-grade TV ecosystem. Amazon built an entire operating system on it. DIRECTV ships their app on it. The react-native-tvos fork tracks core releases. Expo has official TV build support. Callstack publishes enterprise guides for TV development.

Flutter's TV support is experimental. No official TV framework exists, no major streaming platform ships Flutter on TV, and community effort is fragmented.

Kotlin Multiplatform is the more interesting comparison — it's tripled its adoption to 23% and Airbnb chose it for shared business logic. But KMP shares logic, not UI. For a team that wants to share the entire component layer across mobile and TV, React Native is the only framework that delivers this in production.

If you're evaluating frameworks for a multi-surface product, read my post on what Smart TV development actually involves before deciding.

The Architecture: How One Project Targets 7+ Platforms

Here's the monorepo structure I use for cross-platform projects:

├── apps/
│   ├── expo/          # iOS, Android, tvOS, Android TV, Fire TV
│   └── web/           # Samsung Tizen, LG webOS
├── packages/
│   ├── platform/      # Device detection, keycodes, capabilities
│   ├── uikit/         # Focus-aware UI components
│   ├── shared/        # Hooks, state, API client, navigation
│   └── theme/         # Design tokens via React Context
└── turbo.json

The dependency direction is deliberate. uikit depends on platform and theme. shared depends on platform. Apps depend on all four. Nothing flows backwards. When I change a keycode map, only platform and its dependents rebuild — Turborepo's caching handles the rest.

The platform package is the anti-corruption layer. It abstracts the hardware zoo behind a capability-based API:

// Samsung Tizen keycodes
export const tizenKeyCodes: KeyCodes = {
  ENTER: [13],
  BACK: [10009],   // Samsung's unique back button
  RED: [403],      // Color buttons on Samsung remote
  GREEN: [404],
}

// LG webOS keycodes — completely different
export const webosKeyCodes: KeyCodes = {
  ENTER: [13],
  BACK: [461],     // LG's back code
  RED: [403],
  GREEN: [404],
}

We program against capabilities, not platform names. The package exposes PlatformCapabilities — hasColorButtons, maxResolution, hasVoiceControl — so the UI adapts to what the remote can actually do. Detection uses platform-native APIs first (tizen.systeminfo, webOS.platform, Platform.isTV) with user agent parsing as a fallback.

The dual-build strategy. Expo with the react-native-tvos fork handles native platforms (tvOS, Android TV). Vite with react-native-web handles web-based TVs (Tizen, webOS). Platform-specific file extensions — .tizen.tsx, .webos.tsx, .web.tsx — are resolved at build time. The same component can have a shared version and platform-specific overrides, and the bundler picks the right one automatically.

Real Gotchas: What I Learned Shipping to Phones and TVs

Focus management is architecture, not a widget. This is the single biggest misconception about TV development. On mobile, navigation is solved — stack, tabs, drawer. On TV, spatial navigation is a cross-cutting concern that affects your entire application.

When a user presses DOWN on a hero carousel, the focus system must calculate which item in the content rail below should receive focus. This depends on the rail's horizontal scroll position, the width of the focused hero item, and whether the rail has finished layout. Get this wrong and focus jumps to an unexpected item across the screen.

Focus requires a history stack — not just current state, but the ability to restore focus on back navigation. It shapes your testing strategy: you can't test a TV app with click events, you need D-pad sequence simulation. And it's the primary performance bottleneck — traversing a grid of 200 items to find the nearest focusable neighbor must complete in under 16ms or the UI feels broken.

Every component in our UIKit declares whether it's focusable, defines its spatial boundaries, and knows how to animate focus transitions. This is what separates a "React Native app on TV" from a "TV app built with React Native."

Memory is your invisible ceiling. A phone has 6-8 GB of RAM. A Smart TV has 512 MB to 1.5 GB, and your app gets a fraction. The same React Native code that runs smoothly on an iPhone will crash a Samsung TV in 10 minutes if you're not virtualizing lists and actively managing image memory. I covered this in detail in my post on Smart TV challenges.

The react-native-tvos fork is a managed risk. Using "react-native": "npm:react-native-tvos@..." as an npm alias creates upgrade friction — every Expo SDK bump needs a compatible fork release. We mitigate by pinning versions and running a dedicated upgrade validation pipeline. The ecosystem is more stable than 2 years ago (Expo SDK 54+ with RNTV 0.81 works well), but it's a cost to budget for.

TV animations need different thinking. Focus-driven animations must coordinate with focus state that lives in JavaScript. This means consciously choosing JS-driven animations for focus transitions — a trade-off between architectural simplicity and raw frame rate. React Native Reanimated 3.x largely solves this with native-level performance while reading JS-side state, but you need to design for it from day one.

How AI Makes This Possible for One Developer

Shipping to 7+ platforms as a solo developer would have been absurd a few years ago. AI-powered development changed that equation.

Claude, Cursor, and Copilot handle boilerplate that used to eat half my day. Scaffolding a new Zustand store, writing test suites, generating platform-specific configuration — tasks that took 30-40 minutes now take 5 minutes of review.

But AI doesn't replace the expertise. It can't decide that focus management needs a history stack. It doesn't know Samsung Tizen's back button is keycode 10009. It won't tell you to virtualize everything because the TV's WebView gets 200 MB of RAM. That's 9+ years of domain knowledge that makes AI output useful rather than plausible-looking but subtly wrong.

The combination — deep platform expertise plus AI acceleration — is what lets one senior developer outperform agency teams. The expertise sets the architecture. The AI fills in the implementation.

Need a React Native App for Phones and TVs?

If you're building a product that needs to run on both mobile and TV — a streaming service, a content platform, a live events app — this is exactly what I do. I've built OTT platforms serving 80M+ viewers across 15+ device types and ship React Native mobile apps with the same monorepo architecture. Whether you need a cross-platform app from scratch or want to extend an existing mobile app to Smart TV, I can give you an honest assessment.

Originally published at sundr.dev.