Universal App Architecture: Turborepo, Expo Router, Next.js Universal Monorepo (The 2026 Code-Sharing Playbook for Founders)

# Universal App Architecture: Turborepo, Expo Router, Next.js Universal Monorepo (The 2026 Code-Sharing Playbook for Founders)

Summary: Building separate engineering teams for iOS, Android, and Web drains startup capital and fragments product velocity. The 2026 universal app architecture unites Expo Router, Next.js App Router, and Turborepo into a single TypeScript monorepo. By sharing UI primitives through NativeWind, business logic via tRPC and Zod, and universal routing contracts, engineering organizations eliminate duplicated feature work, cut CI build times with remote caching, and substantially reduce early-stage payroll burn to extend startup runway.

---

The Strategic Imperative: Ending the Multi-Platform Tax

For early-stage and growth-stage software companies, platform fragmentation is a silent balance-sheet killer. The traditional paradigm mandates hiring distinct engineering squads: native iOS engineers writing Swift and SwiftUI, Android engineers writing Kotlin and Jetpack Compose, and web frontend engineers writing TypeScript and Next.js.

This siloed structure imposes a heavy multi-platform tax:

1. Triple Implementation Overhead: Every user story, schema change, and analytics event requires three distinct specifications, three pull requests, and three QA validation cycles.

2. Drifting Business Logic: Discrepancies in client-side validation, caching, and state transitions inevitably cause platform-dependent bugs that erode user trust.

3. Severe Runway Burn: Maintaining three distinct platform stacks forces startups to duplicate specialized developer payroll across separate native iOS, native Android, and web silos, rapidly accelerating capital burn before finding true product-market fit.

In 2026, the technology landscape has matured past the brittle cross-platform experiments of the previous decade. With React Native's New Architecture (Fabric renderer and TurboModules) enabled by default, React 19 concurrent features, Hermes bytecode precompilation, and Expo Router v4 bringing file-based routing to mobile, unified application development is no longer a compromise.

By executing a turborepo expo router nextjs universal monorepo strategy, technology leaders establish a universal react native app architecture that shares the substantial majority of production code—spanning domain schemas, API queries, utility functions, and universal design tokens—while maintaining native 120 FPS device performance on iOS and Android alongside server-rendered, SEO-optimized web experiences on Next.js.

---

Architectural Comparison: React Native Web vs. Flutter in 2026

When evaluating cross-platform strategies, engineering leaders frequently compare React Native against Flutter. While Flutter delivers a consistent rendering pipeline across mobile operating systems, it introduces severe architectural liabilities for web-first and SaaS applications.

+-----------------------------------------------------------------------------------+
| Flutter Engine Web Output                                                         |
| [Skia / Impeller Wasm CanvasKit Engine: Multi-Megabyte Initial Runtime Payload]   |
| - Canvas-rendered pixels (DOM is an opaque black box to search engine crawlers)   |
| - Severe SEO indexing penalties & non-existent Server-Side Rendering (SSR)        |
| - Broken browser primitives (middle-click new tab, browser text selection, a11y)  |
+-----------------------------------------------------------------------------------+

+-----------------------------------------------------------------------------------+
| React Native Web + Next.js App Router Output                                      |
| [Semantic HTML5 / CSS Utility Engine: Tiny Hydration Bundle]                      |
| - Native DOM tags (<header>, <nav>, <article>, <a>) for 100/100 Core Web Vitals   |
| - Full Next.js 15+ Server Components (RSC), Edge Rendering, and Static Generation |
| - Native UIKit & Android View primitives rendered natively on mobile devices      |
+-----------------------------------------------------------------------------------+

Why Flutter Fails the Modern Web

Flutter for Web compiles Dart code to a WebAssembly (Wasm) and CanvasKit pipeline that renders pixels to an HTML <canvas> element. While visually identical to its mobile counterparts, this approach creates fundamental friction for web distribution:

• Zero Semantic Accessibility: Web screen readers and accessibility scrapers cannot parse canvas-rendered text natively.
• SEO Penalties: Search engine bots encounter an empty canvas shell without semantic markup or Server-Side Rendering (SSR), crippling organic customer acquisition.
• Payload Overhead: The WebAssembly engine (canvaskit.wasm) and rendering runtime introduce a multi-megabyte initial download payload before the browser can initialize the renderer and produce the First Contentful Paint (FCP), putting web applications at a measurable load-time disadvantage compared to lightweight semantic DOM elements.

Why the Universal React Monorepo Wins

React Native Web and NativeWind take an entirely different approach. On mobile devices, JSX compiles down to native UIView and android.view.ViewGroup containers driven by the C++ Fabric renderer over JSI (JavaScript Interface), bypassing asynchronous JSON bridges. On the web, the exact same React components compile to semantic HTML elements (<div>, <span>, <button>, <a>) styled with atomic CSS.

This enables founders to deploy Next.js 15+ for high-performance marketing pages and authenticated web dashboards while delivering high-speed native binaries to the Apple App Store and Google Play Store from the identical component tree.

---

Monorepo Anatomy: The Enterprise Folder Hierarchy

A production-grade turborepo mobile web setup isolates platform-specific runtime shells from shared core packages. The architecture relies on Turborepo to orchestrate dependency graphs, pipeline caching, and task execution across a unified react native web monorepo.

my-universal-monorepo/
├── apps/
│   ├── expo/                         # Native mobile application (iOS & Android)
│   │   ├── app/                      # Expo Router file-based route tree
│   │   │   ├── (auth)/               # Authenticated route group
│   │   │   ├── _layout.tsx           # Native Stack / Drawer / Tabs layout
│   │   │   └── index.tsx             # Mobile landing view
│   │   ├── app.json                  # Expo application configuration & plugins
│   │   ├── metro.config.js           # Metro bundler config with monorepo resolution
│   │   └── package.json
│   │
│   └── web/                          # Web application (Next.js 15+ App Router)
│       ├── app/                      # Next.js App Router tree
│       │   ├── (auth)/               # Web route groups
│       │   ├── layout.tsx            # Server Root Layout (HTML/body shell)
│       │   └── page.tsx              # High-performance SSR/SSG web view
│       ├── next.config.mjs           # Next.js config (transpilePackages, webpack)
│       └── package.json
│
├── packages/
│   ├── ui/                           # Universal Design System
│   │   ├── src/
│   │   │   ├── button.tsx            # NativeWind + React Native Web button
│   │   │   ├── input.tsx             # Universal text inputs
│   │   │   ├── metric-card.tsx       # Complex data visualization cards
│   │   │   └── navigation-bridge.tsx # Cross-platform link & router primitives
│   │   ├── tailwind.config.ts        # Shared Tailwind theme definitions
│   │   └── package.json
│   │
│   ├── types/                        # Core Contracts & Schema Definitions
│   │   ├── src/
│   │   │   ├── auth.ts               # User session, JWT, and RBAC schemas
│   │   │   ├── billing.ts            # Stripe & subscription schemas
│   │   │   └── index.ts              # Exported Zod schemas and inferred types
│   │   └── package.json
│   │
│   ├── api/                          # End-to-End Type-Safe Backend Layer
│   │   ├── src/
│   │   │   ├── root.ts               # tRPC master application router
│   │   │   ├── routers/              # Domain-specific procedures
│   │   │   └── trpc.ts               # Context, middleware, and procedure builders
│   │   └── package.json
│   │
│   ├── db/                           # Database Schema & Migrations
│   │   ├── src/                      # Drizzle ORM / Prisma schema & clients
│   │   └── package.json
│   │
│   └── config/                       # Shared Tooling Presets
│       ├── eslint/                   # Universal linting standards
│       ├── typescript/               # Strict tsconfig base presets
│       └── tailwind/                 # Base Tailwind configurations
│
├── turbo.json                        # Turborepo task graph & remote caching rules
└── package.json                      # Workspace root (pnpm-workspace.yaml)

Turborepo Pipeline Configuration

The turbo.json file controls task execution and defines dependencies across mobile and web targets:

{
  "$schema": "https://turbo.build/schema.json",
  "globalDependencies": ["**/.env.*local"],
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "!.next/cache/**", "dist/**"]
    },
    "lint": {
      "dependsOn": ["^lint"]
    },
    "typecheck": {
      "dependsOn": ["^typecheck"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}

---

Universal Navigation Bridge: Bridging Expo Router and Next.js

Routing is the single greatest point of architectural friction when sharing code between expo and nextjs. Expo Router uses a native file-based router built on React Navigation primitives (NativeStackNavigation, screen presentation gestures, native transitions). Conversely, Next.js App Router relies on the browser's History API, DOM link prefetching, and React Server Component streaming.

Writing raw <Link href="..."> tags from next/link inside shared components will crash the Metro bundler on mobile. Similarly, importing expo-router into Next.js causes hydration errors and build failures.

To solve this, we engineer a Universal Navigation Bridge in packages/ui/src/navigation-bridge.tsx.

The Universal Link Primitive

// packages/ui/src/navigation-bridge.tsx
import React from 'react';
import { Platform, Pressable, Text, type GestureResponderEvent } from 'react-native';

export interface UniversalLinkProps {
  href: string;
  children: React.ReactNode;
  className?: string;
  onPress?: (e: GestureResponderEvent) => void;
  target?: '_blank' | '_self';
}

/**
 * UniversalLink handles platform-specific link rendering:
 * - On Web: Employs standard Next.js HTML anchor tags for DOM SEO & prefetching
 * - On Native: Employs Expo Router imperative routing over native stack coordinators
 */
export const UniversalLink: React.FC<UniversalLinkProps> = ({
  href,
  children,
  className = '',
  onPress,
  target,
}) => {
  if (Platform.OS === 'web') {
    // Dynamic import to prevent bundler pollution on mobile
    const NextLink = require('next/link').default;
    return (
      <NextLink 
        href={href} 
        className={className} 
        target={target}
        onClick={(e: React.MouseEvent) => {
          if (onPress) onPress(e as unknown as GestureResponderEvent);
        }}
      >
        {children}
      </NextLink>
    );
  }

  // Native execution path (iOS & Android)
  const { useRouter } = require('expo-router');
  const router = useRouter();

  return (
    <Pressable
      className={className}
      accessibilityRole="link"
      onPress={(event) => {
        if (onPress) onPress(event);
        router.push(href);
      }}
    >
      {typeof children === 'string' ? (
        <Text className={className}>{children}</Text>
      ) : (
        children
      )}
    </Pressable>
  );
};

Deep Linking Synchronization

Expo Router aligns mobile route paths directly with web URI conventions:

Web URL:             https://app.startup.com/organizations/org_49a/settings
iOS Universal Link:  https://app.startup.com/organizations/org_49a/settings
Mobile Deep Scheme:  startup://organizations/org_49a/settings
File in Expo:        apps/expo/app/organizations/[id]/settings.tsx
File in Next.js:     apps/web/app/organizations/[id]/settings/page.tsx

By standardizing route structures across apps/expo/app/ and apps/web/app/, both targets consume the identical parameter names ([id]). Deep link handlers require zero manual regex routing tables; Apple Universal Links and Android App Links open the correct native screen automatically.

---

Shared UI Architecture: NativeWind v4 and Design Tokens

Writing cross-platform UI requires an abstraction that translates styling into native primitives without sacrificing runtime frame rates. Deploying nativewind cross platform ui components ensures both web and native targets stay synchronized.

NativeWind v4 operates as a build-time compiler that parses Tailwind CSS classes:

• On Web: Compiles directly to standard CSS style rules, creating tiny, atomic stylesheets with complete support for media queries and pseudo-classes (hover:, focus:).
• On Mobile: Compiles utility classes into static React Native StyleSheet.create() objects evaluated on the Hermes C++ thread. It avoids runtime string parsing overhead.

The Reusable Universal Component

Below is an executive KPI widget defined in packages/ui/src/metric-card.tsx used concurrently in the Next.js web portal and the iOS/Android app:

// packages/ui/src/metric-card.tsx
import React from 'react';
import { View, Text } from 'react-native';
import { UniversalLink } from './navigation-bridge';

export interface MetricCardProps {
  title: string;
  value: string;
  percentageChange: number;
  trend: 'up' | 'down' | 'neutral';
  targetHref: string;
}

export const MetricCard: React.FC<MetricCardProps> = ({
  title,
  value,
  percentageChange,
  trend,
  targetHref,
}) => {
  const isPositive = trend === 'up';

  return (
    <UniversalLink 
      href={targetHref} 
      className="block p-5 bg-white dark:bg-slate-900 rounded-2xl border border-slate-200 dark:border-slate-800 shadow-sm active:opacity-80"
    >
      <View className="flex-col gap-2">
        <Text className="text-xs font-semibold tracking-wider uppercase text-slate-500 dark:text-slate-400">
          {title}
        </Text>
        <Text className="text-3xl font-bold tracking-tight text-slate-900 dark:text-white">
          {value}
        </Text>
        <View className="flex-row items-center gap-1.5 mt-1">
          <View 
            className={`px-2 py-0.5 rounded-full ${
              isPositive ? 'bg-emerald-100 dark:bg-emerald-950/60' : 'bg-rose-100 dark:bg-rose-950/60'
            }`}
          >
            <Text 
              className={`text-xs font-medium ${
                isPositive ? 'text-emerald-700 dark:text-emerald-400' : 'text-rose-700 dark:text-rose-400'
              }`}
            >
              {isPositive ? `+${percentageChange}%` : `${percentageChange}%`}
            </Text>
          </View>
          <Text className="text-xs text-slate-400">vs last period</Text>
        </View>
      </View>
    </UniversalLink>
  );
};

Avoiding Platform Leaks

To maintain clean package boundaries and avoid compilation failures:

1. Never use DOM elements directly in shared packages: Avoid <div>, <span>, or <a>. Always use React Native primitives (View, Text, Pressable).

2. Platform Extension Pattern: When a feature requires distinct native vs. web implementations (such as device biometric scanning or WebAuthn), use .native.tsx and .web.tsx file extensions. Metro and Next.js bundlers automatically pick up their respective target files without complex runtime conditionals.

---

End-to-End Type Safety: Shared Schema with Zod and tRPC

Managing API contracts across separate codebases is notoriously error-prone. A change to a backend database column often breaks mobile clients until an API update is coordinated and deployed.

In a unified trpc expo nextjs monorepo, the contract resides in packages/types and packages/api. Both Next.js and Expo Router consume the identical router instance.

+-------------------------------------------------------------------------+
| packages/types                                                          |
| Zod Schemas: CreateProjectInput, UpdateBillingSchema, UserSession       |
+------------------------------------+------------------------------------+
                                     |
                                     v
+------------------------------------+------------------------------------+
| packages/api                                                            |
| tRPC Routers: projectRouter.create, billingRouter.getInvoices           |
+------------------+-----------------------------------+------------------+
                   |                                   |
                   v                                   v
+------------------+----------------+  +---------------+------------------+
| apps/expo (Mobile)                |  | apps/web (Next.js)               |
| - React Query client via tRPC     |  | - Server Actions / RSC Fetchers  |
| - Automatic TypeScript infer      |  | - Direct Server-Side tRPC Caller |
+-----------------------------------+  +----------------------------------+

Shared Zod Validation Schema

// packages/types/src/project.ts
import { z } from 'zod';

export const createProjectSchema = z.object({
  name: z.string().min(3, 'Project name must exceed 2 characters').max(50),
  tier: z.enum(['starter', 'pro', 'enterprise']),
  billingEmail: z.string().email('Invalid billing contact address'),
  seats: z.number().int().min(1).default(5),
});

export type CreateProjectInput = z.infer<typeof createProjectSchema>;

Shared tRPC Route Handler

// packages/api/src/routers/project.ts
import { router, protectedProcedure } from '../trpc';
import { createProjectSchema } from '@acme/types';

export const projectRouter = router({
  create: protectedProcedure
    .input(createProjectSchema)
    .mutation(async ({ ctx, input }) => {
      const project = await ctx.db.insert(projectsTable).values({
        organizationId: ctx.session.orgId,
        name: input.name,
        tier: input.tier,
        seats: input.seats,
      }).returning();

      return project[0];
    }),
});

Because mobile and web targets import projectRouter from @acme/api, any schema modification instantly triggers TypeScript compiler checks across both applications during the Turborepo typecheck pipeline.

---

Resilient Mobile Architecture: Offline Sync and Push Queues

Founders building universal apps often make the mistake of treating native mobile as a glorified browser tab. Mobile users expect applications to function reliably in intermittent network conditions (elevators, subways, flight modes) and expect prompt, real-time background notifications. Designing a robust cross-platform mobile architecture requires accounting for offline resilience and decoupled messaging pipelines.

Local-First Offline Synchronization

For mission-critical applications, relying on plain HTTP requests creates a fragile mobile user experience. The production standard combines a local-first reactive database with an asynchronous sync protocol:

[Mobile Device (WatermelonDB / PowerSync SQLite)]
       |
       | 1. Instant local write (Zero UI latency)
       v
[Local Mutation Queue (Outbox Pattern)]
       |
       | 2. Re-connection / Background Sync
       v
[Sync Worker / Changeset Engine] <---> [PostgreSQL Master DB]
       |
       | 3. Conflict Resolution (Last-Write-Wins or CRDT)
       v
[State Broadcast via WebSockets / SSE]

1. Client-Side Storage: On native mobile, use an embedded SQLite database managed via WatermelonDB or PowerSync. Next.js can employ IndexedDB or direct HTTP cache fallbacks.

2. Optimistic Outbox: All user mutations are written locally to the outbox table before network dispatch. UI components subscribe reactively to local data tables.

3. Changeset Reconciliation: When network connectivity restores, mutations transmit as a batched changeset. Conflicts resolve on the server using deterministic vector clocks or updated-at timestamps.

Scalable Push Notification Architecture

Push notifications on mobile require coordination between Apple Push Notification Service (APNs) and Firebase Cloud Messaging (FCM). Web push requires distinct VAPID encryption keys.

To prevent API request bottlenecks, push dispatch should execute via a distributed queue:

[Application Event (e.g. Invoice Overdue)]
       |
       v
[Redis Cluster / BullMQ Dispatcher]
       |
       +---> [Worker 1: iOS APNs Token Pipeline (HTTP/2 Provider API)]
       |
       +---> [Worker 2: Android FCM Token Pipeline]
       |
       +---> [Worker 3: Web Push VAPID Protocol]
       |
       v
[Dead-Letter Queue (DLQ) & Expired Device Token Pruning]

• Queue Management: Enqueue notification payloads into BullMQ instances backed by Redis.
• Batch Dispatch: The Expo Server SDK batches notifications up to 100 devices per network frame, respecting APNs payload limits (4KB).
• Token Invalidation: When APNs returns DeviceTokenNotForTopic or FCM returns registration-token-not-registered, background workers immediately flag the token in PostgreSQL as inactive to prevent downstream rate limiting.

---

CI/CD Performance: The Turborepo Remote Caching Benchmark

Monorepos can become sluggish if continuous integration pipelines rebuild every package on every pull request. Turborepo addresses this through computational hashing and remote caching.

Turborepo inspects source file hashes, environment variables, and dependency trees. If a pull request modifies only apps/web, the CI pipeline downloads pre-compiled build artifacts and test results for apps/expo and shared libraries from the remote cache in milliseconds.

Representative CI/CD Pipeline Benchmark

The following representative benchmark profile illustrates task execution timing for a modular SaaS codebase containing 180 components, 45 tRPC routes, and two client applications running on GitHub Actions (ubuntu-latest, 4-core runners). In this test profile, cold execution (clean environment without cache) is evaluated against warm execution utilizing Turborepo remote caching to replay unaltered outputs:

[!NOTE]

Execution figures represent a reference profile modeled under typical multi-package monorepo task workloads on standard GitHub Actions runners. Individual team metrics will vary according to test harness scope, cache hit frequency, and monorepo graph structure.

In an organization with 10 engineers where each developer triggers 3 to 4 CI pull request runs per day, dropping pipeline feedback cycles from ~18 minutes down to ~2 minutes eliminates dozens of cumulative wait hours weekly. By implementing Turborepo remote caching via AWS S3 or Vercel, teams remove the idle pull-request backlog and mitigate the productivity drain caused by frequent context switching.

---

Financial Analysis: 1 Cross-Platform Team vs. 2 Siloed Teams

For technology founders and Chief Financial Officers, software architecture is ultimately a capital allocation decision. Choosing between independent platform silos and a universal monorepo directly impacts company runway and burn multiples.

Headcount and Compensation Comparison

Consider a representative staffing model for building a production SaaS product across iOS, Android, and Web over a 12-month horizon. Compensation benchmarks reflect median US tech market base salaries for mid-to-senior software engineers, referencing published industry datasets from Levels.fyi, Carta Total Compensation, and the US Bureau of Labor Statistics (BLS):

SILOED TEAMS MODEL (Dual/Triple Stack)
├── iOS Squad: 2 Native iOS Engineers (Swift/SwiftUI)      = $360,000
├── Android Squad: 2 Native Android Engineers (Kotlin)     = $360,000
├── Web Squad: 2 Full-Stack Web Engineers (Next.js/React)  = $340,000
├── Specialized Mobile QA Engineer                        = $130,000
└── Platform Project Manager                              = $150,000
TOTAL ANNUAL PAYROLL BURDEN:                                $1,340,000

UNIVERSAL MONOREPO MODEL (Expo + Next.js Unified)
├── 3 Senior Universal Full-Stack Engineers (React/Node)   = $540,000
├── 1 Mobile Systems & Infrastructure Specialist           = $190,000
└── 1 Technical Product Manager / Designer                = $160,000
TOTAL ANNUAL PAYROLL BURDEN:                                $890,000

Capital Savings and Velocity ROI

Under the representative staffing assumptions modeled above, consolidating multi-platform delivery into a unified monorepo can yield over $500,000 in first-year capital savings when accounting for direct salaries and typical recruiting fees. Reinvesting this capital into customer acquisition or extending operational runway by 9+ months often represents the critical buffer between reaching Series A milestones and exhausting capital.

For organizations seeking to transition their existing multi-repository stacks into a high-performance cross-platform monorepo, partnering with specialized architects accelerates delivery. Engaging custom mobile development services from Wise Hustlers provides founders with the production-tested scaffolding, CI/CD pipelines, and design system governance required to execute this architecture flawlessly from day one.

---

Migration Strategy and Failure Modes: How to Ensure Success

Adopting a universal monorepo is an operational transformation. Engineering leaders must watch for key implementation pitfalls:

1. The Package Boundary Leak

Failure Mode: A developer imports an environment variable, native SDK, or Node.js filesystem module (fs, crypto) inside a component in packages/ui.

• Symptom: The mobile Metro bundler throws an unresolvable module error, or Next.js crashes during server component rendering.
• Prevention: Enforce strict ESLint boundary rules (eslint-plugin-import with restricted zones). Ensure that all node-specific utilities live strictly in apps/web or backend packages.

2. Over-Abstraction of Native Hardware

Failure Mode: Attempting to force every native capability (Bluetooth Low Energy, background geolocation, Apple HealthKit) through a generic universal component.

• Symptom: Brittle abstractions that fail when edge-case platform capabilities are needed.
• Prevention: Follow the 80/20 rule. Keep business logic, UI design tokens, API calls, and authentication universal. Treat device hardware access as native-first using platform extensions (.native.tsx).

3. Falsifiability Checklist: Is Your Architecture Succeeding?

To determine whether your monorepo implementation is delivering expected returns, monitor these objective metrics:

• Remote Cache Hit Rate: Must remain above 80% on master and staging branches. If cache hits drop below 60%, check your turbo.json outputs and environment variable invalidation rules.
• Code Sharing Percentage: Shared packages (packages/ui, packages/api, packages/types) should account for at least 60% of total non-test source lines. If duplication exceeds 35%, review team PR practices.
• Native Bundle Size: Production iOS and Android JavaScript bundles should remain under 25MB uncompressed. If sizes expand rapidly, audit imports to ensure web-only libraries are not being bundled by Metro.

---

Frequently Asked Questions

Can Next.js React Server Components (RSC) work inside Expo Router on native mobile?

Not directly out of the box in the same runtime. Next.js App Router renders React Server Components on a Node.js or Edge runtime, outputting a serialized component stream to the browser. Expo Router runs client-side JavaScript on the device's native Hermes engine. However, the universal architecture bridges this cleanly: Next.js uses RSC for server rendering and SEO data fetching on the web, while Expo Router consumes the identical data payloads through typed tRPC queries and mutations over HTTP/WebSockets.

How does a universal monorepo handle platform-specific native SDKs like Apple HealthKit or Stripe Terminal?

Native SDKs that lack web counterparts are isolated using platform extensions. For example, implement packages/ui/src/biometrics/scanner.native.tsx using expo-local-authentication for FaceID and TouchID, and implement packages/ui/src/biometrics/scanner.web.tsx using the standard WebAuthn API. The TypeScript compiler and bundlers resolve the correct file automatically for each target without requiring messy runtime if (Platform.OS === 'ios') branching.

What is the realistic code-sharing percentage in a production Turborepo setup?

In a well-structured universal monorepo, engineering teams typically achieve substantial code sharing—often ranging from 60% to 75% of the total application codebase, depending on device hardware requirements. The shared layer encompasses domain types (Zod), API query definitions (tRPC), authentication logic, business utilities, and universal UI design tokens (NativeWind). The remaining 25% to 40% consists of platform-specific routing layouts, native device permission handling, hardware-specific SDK integrations, and specialized web SEO landing pages.

When should a founder avoid a universal monorepo?

A universal monorepo is counterproductive in two primary scenarios: First, if your product is a high-frequency 3D gaming or intensive audio-processing application that requires raw Metal or Vulkan C++ graphics pipelines. Second, if your business has zero consumer or client mobile requirements and plans to operate exclusively as an internal desktop browser tool. For virtually all other B2B SaaS, marketplace, and consumer platforms, the universal monorepo provides superior capital efficiency.

---

Sources

• Expo Router Documentation & Architecture Guide - Official documentation for file-based routing on iOS, Android, and Web.
• Turborepo Documentation & Remote Caching Benchmarks - Architectural patterns and remote build execution specifications.
• React Native New Architecture Guide - Deep analysis of the Fabric renderer, TurboModules, and Hermes runtime.
• Next.js App Router Specifications - Server Components, layouts, and data streaming architecture.
• NativeWind Universal Styling Documentation - Tailwind CSS compiler mechanics for React Native and Web.
• Flutter Web Rendering Documentation - Analysis of CanvasKit and WebAssembly rendering architectures on the web.
• Levels.fyi Tech Compensation Benchmarks - Software engineering compensation datasets across US metropolitan technology markets.