DEV Community: Aleksandr Sakov

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

Aleksandr Sakov — Fri, 17 Apr 2026 17:18:53 +0000

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.

Deploy Apps to Samsung Smart TV: The Bash Script That Saves Hours

Aleksandr Sakov — Tue, 31 Mar 2026 16:28:17 +0000

If you've ever deployed a web app to a Samsung Smart TV, you know the pain. Connect via sdb, resolve the device name, package the .wgt file with the right certificate, uninstall the old version, install the new one, run it, pray it doesn't crash. Every. Single. Time.

After 9+ years of doing this across dozens of OTT projects — including platforms serving 80M+ viewers — I finally snapped and wrote a script that automates the entire thing.

I'm sharing it here because I wish someone had shared something like this with me years ago.

What You Need Before Starting

Before the script can do its magic, you need three things set up on your machine and your TV.

1. Install Tizen Studio. Download it from the official Tizen Studio page. You need the CLI tools — specifically sdb and the tizen command-line utility. The script expects them at ~/tizen-studio/tools/. After the base installation, open Package Manager, go to the Extension SDK tab, and install TV Extensions and Samsung Certificate Extension. The full process is described in the Samsung TV SDK installation guide.

2. Create a Samsung certificate. This is the part that trips most people up. You need a signing certificate to package and install apps on a physical TV. Follow the Samsung certificate guide: open Certificate Manager in Tizen Studio, create a Samsung certificate profile (not a Tizen one), authenticate with your Samsung Developer account, and register your TV's DUID as the target device. Keep the certificate backed up — future updates must use the same author certificate or the TV treats them as a completely new app.

3. Enable Developer Mode on the TV. On the TV itself, go to the Apps panel, open App Settings, and enter the code 12345. This opens the Developer Mode popup. Toggle it on, enter your computer's IP address, and reboot the TV. After restart you'll see "Develop Mode" at the top of the Apps panel. The full walkthrough is in the Samsung device setup guide.

Also required: Java 8. Tizen CLI tools still depend on Java 8, not newer versions. On macOS, install it with brew install --cask temurin8. The script automatically detects and switches to Java 8 for the session, so it won't mess with your system Java.

What the Script Does

The script gives you an interactive menu powered by gum (a terminal UI toolkit that it auto-installs if missing). You get 8 options:

Run All Steps — connect, resolve device, package, uninstall old version, install, and run. One selection, done.
Connect to TV — establishes sdb connection to your TV's IP.
Resolve device name — reads the device identifier from sdb, needed for all Tizen CLI commands.
Package app — signs your build directory as a .wgt file with your certificate. Handles filename sanitization automatically.
Uninstall app — removes the existing version from the TV (gracefully ignores if not installed).
Install app — pushes the .wgt to the TV.
Debug app — launches a debug session and forwards the debug port so you can attach Chrome DevTools.
Run app — launches the app in non-debug mode.

You can also pass a pre-built .wgt file directly, and the script skips the packaging step entirely.

Config Persistence: Set Once, Deploy Forever

On first run, the script asks you four things: TV IP address, certificate name, package ID, and the path to your build directory (or .wgt file). The package ID comes from your project's config.xml — it's the combination of the tizen:application package attribute, in the format AbCdEf1234.MyApp. The script saves all of this to ~/.tizen_deploy_config, so every subsequent run just works — no re-entering values.

Working on a different project or switched TVs? Run the script with --clear-config to reset everything:

./tizen_deploy.sh --clear-config

This wipes the saved config and prompts you fresh.

The Full Script

Here's the complete source. Save it as tizen_deploy.sh, make it executable with chmod +x tizen_deploy.sh, and run it.

#!/bin/bash

# PLATFORM DETECTION
OS_TYPE="$(uname -s)"
IS_MAC=false
IS_LINUX=false
IS_WIN=false

case "$OS_TYPE" in
  Darwin*) IS_MAC=true ;;
  Linux*) IS_LINUX=true ;;
  MINGW*|MSYS*|CYGWIN*) IS_WIN=true ;;
esac

# CONFIG PATH
CONFIG_PATH="$HOME/.tizen_deploy_config"
$IS_WIN && CONFIG_PATH="$HOME/_tizen_deploy_config"

# --clear-config ARG HANDLING
if [[ "$1" == "--clear-config" ]]; then
  echo "Clearing config at $CONFIG_PATH"
  rm -f "$CONFIG_PATH"
fi

# INSTALL GUM IF NOT FOUND
install_gum() {
  if command -v gum &>/dev/null; then return; fi
  echo "'gum' is not installed. Installing..."

  if $IS_MAC; then
    if ! command -v brew &>/dev/null; then
      echo "Homebrew is required on macOS." >&2
      exit 1
    fi
    brew install charmbracelet/tap/gum
  elif $IS_LINUX; then
    if command -v apt &>/dev/null; then
      sudo apt update && sudo apt install -y gum
    elif command -v dnf &>/dev/null; then
      sudo dnf install -y gum
    elif command -v pacman &>/dev/null; then
      sudo pacman -Sy gum
    else
      echo "Unsupported package manager." >&2
      exit 1
    fi
  elif $IS_WIN; then
    echo "On Windows, install gum manually:"
    echo "  scoop install gum"
    read -p "Press Enter when installed..."
  fi
}

if ! command -v tizen &>/dev/null; then
  echo "Tizen CLI not found. Install Tizen Studio first."
  exit 1
fi

install_gum

# FORCE JAVA 8 FOR TIZEN
if command -v /usr/libexec/java_home &>/dev/null; then
  JAVA_8_HOME=$(/usr/libexec/java_home -v 1.8 2>/dev/null)
  if [[ -z "$JAVA_8_HOME" ]]; then
    echo "Java 8 is required. Install: brew install --cask temurin8"
    exit 1
  fi
  export JAVA_HOME="$JAVA_8_HOME"
  export PATH="$JAVA_HOME/bin:$PATH"
fi

# LOAD / PROMPT CONFIGURATION
prompt_or_load() {
  local var_name=$1
  local prompt_msg=$2
  local current_value=$(grep "^$var_name=" "$CONFIG_PATH" 2>/dev/null | cut -d'=' -f2-)
  if [ -n "$current_value" ]; then
    eval "$var_name=\"$current_value\""
  else
    read -p "$prompt_msg: " user_input
    echo "$var_name=\"$user_input\"" >> "$CONFIG_PATH"
    eval "$var_name=\"$user_input\""
  fi
}

prompt_or_load TV_IP "Enter TV IP address"
prompt_or_load CERTIFICATE_NAME "Enter Certificate/Profile name"
prompt_or_load PACKAGE_ID "Enter PACKAGE_ID (e.g., abc123.MyApp)"
prompt_or_load INPUT_PATH "Enter build dir or .wgt file path"

# Derive behavior based on INPUT_PATH
if [[ "$INPUT_PATH" == *.wgt ]]; then
  BUILD_DIR="$(dirname "$INPUT_PATH")"
  APP_NAME="$(basename "$INPUT_PATH")"
  SKIP_PACKAGE=true
else
  BUILD_DIR="$INPUT_PATH"
  APP_NAME="$(echo "$PACKAGE_ID" | cut -d. -f2).wgt"
  SKIP_PACKAGE=false
fi

SDB="$HOME/tizen-studio/tools/sdb"
TIZEN_CLI="$HOME/tizen-studio/tools/ide/bin/tizen"

TV_PORT="26101"
DEVICE_NAME=""
DEBUG_PORT=""

# STEP FUNCTIONS
connect() {
  echo "Connecting to $TV_IP:$TV_PORT..."
  CONNECT_OUTPUT=$($SDB connect "$TV_IP:$TV_PORT" 2>&1)
  echo "$CONNECT_OUTPUT" | grep -Eq "connected to|is already connected" \
    && echo "Connected." || { echo "Failed."; echo "$CONNECT_OUTPUT"; exit 1; }
}

resolve_device() {
  DEVICE_NAME=$($SDB devices | grep "$TV_IP:$TV_PORT" | awk '{print $3}')
  [[ -z "$DEVICE_NAME" ]] && { echo "Could not resolve device."; exit 1; }
  echo "Device: $DEVICE_NAME"
}

package_app() {
  $SKIP_PACKAGE && { echo "Skipping packaging (.wgt provided)"; return; }
  PACKAGE_OUTPUT=$($TIZEN_CLI package -s "$CERTIFICATE_NAME" -t wgt -- "$BUILD_DIR" 2>&1)
  if echo "$PACKAGE_OUTPUT" | grep -q "Package File Location"; then
    PKG_FILE=$(echo "$PACKAGE_OUTPUT" | grep "Package File Location" | sed -E 's/.*:\s*//' | xargs)
    NEW_BASENAME=$(basename "$PKG_FILE" | tr -d ' ')
    mv "$PKG_FILE" "$(dirname "$PKG_FILE")/$NEW_BASENAME" 2>/dev/null
    APP_NAME="$NEW_BASENAME"
    echo "Packaged: $APP_NAME"
  else
    echo "Packaging failed."; echo "$PACKAGE_OUTPUT"; exit 1
  fi
}

uninstall_app() {
  $TIZEN_CLI uninstall -t "$DEVICE_NAME" -p "$PACKAGE_ID" 2>&1 | \
    grep -q "uninstall completed" && echo "Uninstalled." || echo "Not installed, skipping."
}

install_app() {
  INSTALL_OUTPUT=$($TIZEN_CLI install --name "$APP_NAME" -t "$DEVICE_NAME" -- "$BUILD_DIR" 2>&1)
  echo "$INSTALL_OUTPUT" | grep -q "successfully installed" \
    && echo "Installed." || { echo "Install failed."; echo "$INSTALL_OUTPUT"; exit 1; }
}

debug_app() {
  DEBUG_OUTPUT=$($SDB shell 0 debug "$PACKAGE_ID" 2>&1)
  DEBUG_PORT=$(echo "$DEBUG_OUTPUT" | grep -oE "port: [0-9]+" | awk '{print $2}')
  [[ -z "$DEBUG_PORT" ]] && { echo "Debug failed."; echo "$DEBUG_OUTPUT"; exit 1; }
  $SDB forward "tcp:$DEBUG_PORT" "tcp:$DEBUG_PORT" 2>&1
  echo "Debug on port $DEBUG_PORT"
}

run_app() {
  RUN_OUTPUT=$($TIZEN_CLI run -t "$DEVICE_NAME" -p "$PACKAGE_ID" 2>&1)
  echo "$RUN_OUTPUT" | grep -q "successfully launched" \
    && echo "Launched." || { echo "Launch failed."; echo "$RUN_OUTPUT"; exit 1; }
}

run_all() { connect; resolve_device; package_app; uninstall_app; install_app; run_app; }

# INTERACTIVE MENU
choice=$(gum choose \
  "Run All Steps (1-5, 7)" \
  "1. Connect to TV" \
  "2. Resolve device name" \
  "3. Package app" \
  "4. Uninstall app" \
  "5. Install app" \
  "6. Debug app + forward port" \
  "7. Run app (non-debug)" \
  "8. Disconnect from TV")

case "$choice" in
  "Run All Steps (1-5, 7)") run_all ;;
  "1. Connect to TV") connect ;;
  "2. Resolve device name") resolve_device ;;
  "3. Package app") package_app ;;
  "4. Uninstall app") resolve_device && uninstall_app ;;
  "5. Install app") resolve_device && install_app ;;
  "6. Debug app + forward port") resolve_device && debug_app ;;
  "7. Run app (non-debug)") resolve_device && run_app ;;
  "8. Disconnect from TV") disconnect ;;
  *) echo "Invalid selection." && exit 1 ;;
esac

echo "Done."

How to Debug Your App with Chrome DevTools

One of the most useful features of the script is remote debugging. Here's how to connect Chrome DevTools to your app running on the TV.

Step 1: Close the app on the TV. If the app is already running, close it first. The debug session needs to launch the app itself — it won't attach to an already running instance.

Step 2: Run the debug command. Launch the script and select "Debug app + forward port" from the menu. The script will output a port number — copy it.

Step 3: Open Chrome DevTools for devices. In Chrome, go to chrome://inspect/#devices. Make sure "Discover network targets" is checked, then click Configure...

Step 4: Add the debug port. In the Target discovery settings dialog, add localhost:{port} where {port} is the number the script returned. Click Done.

Step 5: Inspect. Your TV app should appear under Remote Target. Click inspect on the first item in the list — a full Chrome DevTools window opens, connected to your app on the TV. You can inspect DOM, debug JavaScript, profile performance, and see network requests just like you would on a regular web page.

Important Notes and Limitations

A few things to keep in mind:

Tested on macOS. The script has platform detection for Linux and Windows (Git Bash), but I've only battle-tested it on macOS. Linux should work with minor adjustments. Windows via Git Bash/MSYS is experimental — your mileage may vary.
Java 8 is mandatory. Tizen CLI refuses to work with Java 11+. The script handles this by temporarily switching JAVA_HOME for the session only — your system Java stays untouched.
Certificate issues are the #1 problem. If install fails with a signing error, check three things: the certificate profile name must match exactly, the TV's DUID must be registered in the distributor certificate, and the certificate type matters — you need a Samsung certificate (not Tizen), and the privilege level must be correct (Partner for apps using privileged APIs, Public for basic apps).
gum is auto-installed. The interactive menu uses gum from Charm. If it's not installed, the script installs it via Homebrew (macOS), apt/dnf/pacman (Linux), or asks you to install it manually (Windows).

About Me

I'm Aleksandr Sakov — a full-stack developer with 9+ years of experience building OTT streaming platforms, mobile apps, and web products. The platforms I've built serve 80M+ viewers across 15+ device types including Samsung Tizen, LG WebOS, Android TV, Roku, and more.

If you're building a Smart TV app or any streaming product and want someone who's already solved the hard problems — book a free 30-minute call or try the project calculator for a quick estimate.

sundr.dev | LinkedIn