我必須坦白說：三年前，我會建議任何詢問行動版的網頁代理商就直接建構 PWA 然後收工。那個建議老化得很快。行動應用市場在 2025 年達到 9,350 億美元的收入，用戶端期望劇烈改變，React Native 成熟為我真正喜歡使用的東西。如果你的代理商已經使用 Next.js 和 React 開發，你正坐在可轉移技能的金礦上。但有真實的陷阱存在，而我已經跌入其中大多數，所以你不用這樣做。

這篇文章是我希望在開始認真對待行動客戶端時就擁有的指南。它涵蓋工程現實、業務經濟，以及你需要的部署管線。沒有關於「協同作用」的空談——只是來自於發佈生產應用的辛苦獲得的經驗。

目錄

React Native for Web Agencies: Adding Mobile to Your Next.js Practice in 2026

為什麼 2026 年是網頁代理商進軍行動的正確時機

時機論證不僅僅是關於市場規模。它是關於三個特定的轉變匯聚：

React Native 的新架構已穩定。 Fabric 渲染器和 TurboModules 多年來一直「即將推出」，現在已是預設值。React Native 與原生 Swift/Kotlin 之間的性能差距縮小到對 90% 的應用類別而言無關緊要。JSI（JavaScript Interface）意味著你不再為每個原生呼叫都跨越橋樑——它是同步的且快速的。

Expo 成為完整平台。 Expo SDK 53（2026 年初發佈）支援幾乎所有你需要的原生 API。從 Expo 中彈出來以獲取藍牙或後台定位等基本功能的日子已過去。EAS Build 處理整個編譯管線。對於大多數項目，你再也不需要在你的機器上安裝 Xcode。

用戶端需求轉變。 我在我們網絡中的代理商看到一個模式：過去要求「網站」的用戶端現在要求「數位產品」。他們期望網頁存在和行動應用，並且他們期望它們共享設計系統。如果你能從一個團隊交付兩者，你不是與個別的網頁和行動商店競爭——你正替代它們兩者。

市場數字

根據 Statista 的 2025 年數據，全球行動應用收入預計到 2027 年將達到 1.1 兆美元。但對代理商更相關的是：2025-2026 年企業用戶端行動應用預算平均介於 15 萬至 50 萬美元之間用於 MVP。這是大多數代理商網頁項目命令價格的 2-3 倍。

React 生態系統重疊：什麼真正可轉移

讓我們先打破迷思：React Native 不是「只是手機版的 React」。你的開發人員會有學習曲線。但相比從頭開始學習 Swift 和 Kotlin，這是一個短得多的曲線。

以下是關於什麼可轉移、什麼不可轉移的誠實分解：

技能/技術 可轉移到 React Native？ 備註
React 元件模式 ✅ 是，直接 Hooks、context、狀態管理——全部相同
TypeScript ✅ 是，直接 相同語言，相同工具
狀態管理（Zustand、Jotai、Redux） ✅ 是，直接 直接相容
React Query / TanStack Query ✅ 是，直接 相同 API、相同快取策略
CSS / Tailwind ⚠️ 部分 沒有 CSS 級聯。NativeWind 橋接這個間隙
Next.js 路由 ⚠️ 部分 Expo Router 也是基於文件的，但導航範例不同
DOM 操控 ❌ 否 沒有 DOM。句點。
HTML 元素 ❌ 否 用 <View>、<Text>、<Pressable> 代替
瀏覽器 API ❌ 否 需要 Expo 模組或原生模組
CSS 動畫 ❌ 否 使用 Reanimated 3（實際上更好）

甜蜜點是這樣的：你的 React 開發人員可以在 2-3 週內在 React Native 中提高生產力。他們不會是專家，但他們可以發佈功能。與招聘原生開發人員相比，這是一個巨大的優勢。

最令我驚訝的事

轉移得比我預期好得多的是思維模型。React 的元件組合、單向數據流和聲明式 UI 範例——這些是難以學習的部分。API 表面差異（<div> vs <View>）相比之下是微不足道的。

轉移得比我預期差得多的是佈局。是的，React Native 使用 Flexbox。但這是 Flexbox，預設為 flexDirection: 'column'、沒有 display: grid、沒有媒體查詢（你使用 useWindowDimensions），以及沒有級聯樣式。我們團隊中的每個開發人員在前一周都為此絆倒了。

2026 年的 Expo：改變一切的平台

如果你在 2019-2020 年嘗試過 React Native 並將其棄置，我理解。開發人員體驗很糟。Expo 從根本上改變了這一點。

以下是 Expo 在 2026 年給你的東西：

  • Expo Router v4：基於文件的路由，鏡像 Next.js 約定。你的開發人員立即會感到家般的熟悉。
  • Expo Modules API：用 Swift/Kotlin 撰寫原生模組，帶著乾淨的 TypeScript 介面。不再有古怪的橋接代碼。
  • EAS Build：iOS 和 Android 的基於雲的構建。iOS 構建不需要 Mac。
  • EAS Submit：自動化的 App Store 和 Play Store 提交。
  • EAS Update：超越應用商店審查的空中更新，用於僅 JS 的更改。
  • Expo Dev Client：包含你的原生模組但保持快速重新整理 DX 的自訂開發構建。
# 在 2026 年創建新 Expo 項目
npx create-expo-app@latest my-app --template tabs
cd my-app
npx expo start

就這樣。你在不到兩分鐘的時間內在 iOS Simulator 和 Android Emulator（或透過 Expo Go 的實體設備）上執行。

Expo Router：來自 Next.js 的橋樑

Expo Router 值得特別關注，因為它是 Next.js 開發人員快速適應的單一最大原因。看看結構：

app/
  (tabs)/
    index.tsx        # 首頁分頁
    settings.tsx     # 設定分頁
    _layout.tsx      # 分頁佈局
  profile/
    [id].tsx         # 動態路由
  _layout.tsx        # 根佈局

如果你使用 Next.js App Router 構建，這個結構幾乎相同。動態路由、佈局、嵌套導航——概念直接對應。主要區別是行動導航使用堆疊和分頁而不是頁面和 URL 路徑，但 Expo Router 完美地抽象了這一點。

React Native for Web Agencies: Adding Mobile to Your Next.js Practice in 2026 - architecture

Next.js 和 React Native 之間的代碼共享

這是代理商獲得真實投資回報率的地方。在網頁和行動之間共享代碼不僅僅是擁有最好的——它是提供兩項服務的經濟理由。

什麼可共享

積極共享：

  • 業務邏輯和實用程式
  • API 用戶端和數據取得 hooks
  • 狀態管理存儲
  • 類型定義和驗證模式（Zod 在這裡運作得很好）
  • 認證邏輯

謹慎共享：

  • 設計代幣（顏色、間距、排版刻度）
  • 元件邏輯（但不是元件呈現）

不共享：

  • UI 元件直接（呈現基元不同）
  • 導航邏輯
  • 平台特定動畫

Monorepo 設置

2026 年的標準方法是 Turborepo 或 Nx monorepo。以下是典型結構：

packages/
  shared/
    src/
      hooks/
        useAuth.ts
        useProducts.ts
      utils/
        formatCurrency.ts
        validateEmail.ts
      types/
        user.ts
        product.ts
      api/
        client.ts
apps/
  web/          # Next.js 應用
  mobile/       # Expo 應用

// packages/shared/src/hooks/useProducts.ts
import { useQuery } from '@tanstack/react-query';
import { apiClient } from '../api/client';
import type { Product } from '../types/product';

export function useProducts(categoryId: string) {
  return useQuery<Product[]>({
    queryKey: ['products', categoryId],
    queryFn: () => apiClient.get(`/products?category=${categoryId}`),
    staleTime: 5 * 60 * 1000,
  });
}

這個 hook 在你的 Next.js 應用和 React Native 應用中運作完全相同。數據取得、快取和狀態管理完全共享。只有呈現產品的 UI 層不同。

Solito / Universal 方法

對於想要進一步推進代碼共享的代理商，Solito（由 Fernando Rojo 製作）在 Next.js 和 Expo 之間啟用通用導航和某些共享元件。在 2026 年，React Native react-native-web 函式庫也足夠成熟以共享設計系統，儘管我只會為已發佈至少一個 React Native 項目的團隊推薦這種方法。它增加複雜性。

我們的典型代碼共享比率：總代碼庫的 40-60% 在網頁和行動之間共享。那不是行銷絨毛——那是在六個客戶項目中測量的。

EAS Build 和部署：你的 CI/CD 管線

部署是行動開發在歷史上一直很痛苦的地方。應用簽署、配置文件、Play Store 合規性——這是一個迷宮。EAS 使其可管理。

EAS Build 定價（2026）

計劃 價格 每月構建額度 構建速度
免費 $0 30 iOS + 30 Android ~40 分鐘/構建
生產 $99/月 200 總計 ~15 分鐘/構建
企業 $999/月 無限制 ~8 分鐘/構建（優先）

對於大多數代理商，生產計劃是甜蜜點。一旦你有超過一個活躍項目，你將快速用完免費級別額度。

真實 CI/CD 管線

以下是我們使用的管線，它在多個客戶項目中運作良好：

# .github/workflows/mobile-deploy.yml
name: Mobile Deploy
on:
  push:
    branches: [main]
    paths:
      - 'apps/mobile/**'
      - 'packages/shared/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx eas-cli build --platform all --non-interactive --profile production
        env:
          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}

  submit:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npx eas-cli submit --platform all --non-interactive
        env:
          EXPO_TOKEN: ${{ secrets.EXPO_TOKEN }}

對於不涉及原生代碼的僅 JavaScript 更新，使用 EAS Update 而不是完整構建：

# 推送 OTA 更新——用戶在下一次應用啟動時獲得它
eas update --branch production --message "修復結帳按鈕對齊"

這對代理商來說很重要。會花 1-3 天等待 App Store 審查的錯誤修復現在在數分鐘內到達用戶。

代理商經濟：定價、人員配置和利潤

讓我們談談金錢。這是我看到代理商犯最大錯誤的地方。

行動項目定價

不要像網頁項目那樣為行動項目定價。它們構建成本更高、維護成本更高，並帶著持續的平台成本。以下是我們看到有效的方案：

項目類型 典型代理商費率 時間線 總範圍
簡單應用（內容、認證、基本 CRUD） $180-250/小時 8-12 週 $90K-$180K
中等應用（付款、實時、整合） $180-250/小時 12-20 週 $180K-$400K
複雜應用（離線優先、沉重原生功能） $200-300/小時 20-32 週 $350K-$750K
網頁 + 行動捆綁（共享代碼庫） $180-250/小時 16-28 週 $250K-$550K

網頁 + 行動捆綁是你的競爭武器。一個為 $350K 獲得兩者的用戶端獲得比為網頁支付 $200K 且為行動支付 $300K 給不同商店更好的交易。而且你的利潤更好，因為代碼共享。

人員配置模型

你不需要立即招聘專業行動開發人員。以下是有效的進展：

  1. 階段 1（首個行動項目）：你的資深 React 開發人員領導，有 React Native 經驗的承包商作為指南。預算承包商費用 $15-25K。
  2. 階段 2（2-3 個項目）：你的團隊有足夠經驗。招聘一位具有強大 React Native 背景的開發人員作為行動領導。
  3. 階段 3（行動是 30%+ 的收入）：建立一個 2-3 名開發人員的專業行動團隊。

維護收入流

以下是沒有人告訴你的行動應用事項：即使用戶端沒有新增功能，它也需要持續維護。iOS 和 Android 每年發佈主要 OS 版本。依賴需要更新。App Store 政策改變。這是經常性收入。

我們根據應用複雜性為行動應用維護保留費用收費 $3,000-$8,000/月。在 8-10 個用戶端中，這是平滑掉基於項目收入波動的有意義的經常性收入。

何時說是（和否）給行動客戶端

不是每個行動項目都適合你的代理商。我以艱難的方式學會了這一點。

說是時機：

  • 用戶端已經有你構建的網頁產品——你知道域名、API、業務邏輯。你在第一天前就完成了 40%。
  • 應用主要是數據驅動的——CRUD 應用、儀表板、電子商務、內容交付。React Native 在這方面表現出色。
  • 用戶端有現實的時間線——最少 8 週任何有意義的東西。
  • 預算是 $80K+——低於此，你無法交付品質並保持利潤。

說否時機：

  • 應用需要沉重的 GPU/圖形——遊戲、AR 體驗、複雜 3D。使用 Unity 或原生。
  • 應用需要深度硬體整合——藍牙 LE 周邊、自訂相機管線、NFC 付款處理。在 React Native 中可能，但原生模組開發會炸毀你的預算。
  • 用戶端想要「像素完美平台原生」設計——如果他們想要他們的 iOS 應用感覺完全像 SwiftUI 應用，且他們的 Android 應用感覺完全像 Jetpack Compose，React Native 會增加開銷。
  • 預算低於 $50K——你會虧錢。將他們轉介給自由職業者或無代碼平台。
  • 用戶端沒有 API——如果你需要構建後端、行動應用和網頁應用，謹慎範圍化。這是三個項目，不是一個。

工程成本：沒有人談論的數字

除了開發人員薪資，行動增加網頁代理商不考慮的成本：

成本 年度金額 備註
Apple 開發人員帳戶 $99/年/用戶端 App Store 必需
Google Play 開發人員帳戶 $25 一次性/用戶端 Play Store 必需
EAS Build（生產） $1,188/年 跨項目共享
App Store 螢幕截圖和資產 $500-2,000/應用 通常在範圍中被遺忘
設備測試實驗室 $2,000-5,000/年 實體設備或 BrowserStack
推送通知服務 $0-500/月 Firebase 免費開始，規模擴大
代碼簽署憑證 包含在 Apple 開發人員帳戶 但管理它們需要時間
App Store 最優化 $500-2,000/啟動 如果你為用戶端做這個

偷偷的成本是在真實設備上測試。 模擬器說謊。我們維護一個有 6 部 iPhone（各種型號）和 4 部 Android 設備（三星、Pixel、一部廉價手機用於性能測試）的設備實驗室。預算為此。

時間成本

App Store 審查通常需要 24-48 小時，但在假期季節可能需要一周。Play Store 審查通常更快（數小時到一天）。在你的項目時間線中考慮這個——你不能像網頁應用那樣「週五就部署」。

首次應用提交需要更長時間。Apple 尤其審查新開發人員帳戶。我們曾有首次提交花費 5-7 天伴著拒絕重新提交週期。

網頁代理商的實用遷移路徑

如果你對向你的實踐添加行動感到滿意，以下是我推薦的路徑：

第 1-2 月：內部項目 使用 Expo 構建簡單的內部應用。時間追蹤器、項目儀表板，任何東西。讓你的團隊熟悉工具而不用戶端壓力。使用它來設置你的 monorepo 結構、CI/CD 管線和設備測試過程。

第 3-4 月：現有用戶端向上銷售 向你最好的現有用戶端談論行動伴侶應用。你已經知道他們的域名、他們的 API、他們的團隊。以輕微折扣提供它作為參考案例交換。

第 5-8 月：首個外部行動用戶端 採取具有現實範圍的行動項目。將其保持在 12 週最大值。使用你的內部項目和首個用戶端項目作為能力證明。

第 9 月+：產品化 創建標準行動項目模板、估算電子表格和入門過程。這是行動成為真實服務線而不是實驗的時機。

在整個這個過程中，投資你的 headless CMS 能力——從網頁相同 CMS 中提取的內容驅動行動應用是你可以提供用戶端的最高價值捆綁之一。

技術棧推薦

對於在 2026 年開始的代理商，以下是我會賭的堆疊：

  • Expo SDK 53+ 帶著 Expo Router v4
  • NativeWind v4 用於樣式設置（React Native 用 Tailwind CSS）
  • TanStack Query 用於服務器狀態
  • Zustand 用於用戶端狀態
  • React Native Reanimated 3 用於動畫
  • Turborepo 用於 monorepo 管理
  • EAS Build + EAS Update 用於 CI/CD

如果你的網頁實踐使用 Astro 而不是 Next.js，共享代碼策略仍然有效——你只是共享數據層和業務邏輯套件而不是 React 元件。

常見問題

React/Next.js 開發人員在 React Native 中變得有生產力需要多長時間？ 根據我們增加五個網頁開發人員的經驗，預期 2-3 週達到基本生產力（可以構建螢幕並實現功能）和 2-3 個月達到我稱之為自信獨立性（可以架構功能、調試原生問題、處理平台特定邊界情況）。初始學習曲線主要關於導航模式、行動特定 UX 約定和樣式設置差異。

我可以在 Next.js 和 React Native 中使用相同的元件嗎？ 不直接——呈現基元不同（<div> vs <View>、<span> vs <Text>）。但是，你可以透過自訂 hooks 共享元件邏輯、共享設計代幣，並使用 Solito 或 react-native-web 之類的函式庫橋接間隙。實際上，我們在平台之間共享 40-60% 的總代碼，主要是業務邏輯和數據層代碼。

每年維護 React Native 應用的成本是多少？ 對於典型中等複雜性應用，預期每年 $36K-$96K 的維護成本。這涵蓋 OS 相容性更新（iOS 和 Android 每年發佈主要版本）、依賴更新、錯誤修復、次要功能添加和 App Store 政策合規。這是用戶端需要預算的真實成本。

在 2026 年，React Native 在生產應用中足夠快嗎？ 是的，明確地。使用新架構（Fabric + TurboModules + JSI）現在預設，React Native 應用對標準 UI 達到 60fps 一致。Discord、Shopify Shop 和 Coinbase 之類的應用大規模使用 React Native。與原生的性能差距對 90%+ 的應用類別而言無關緊要。它仍然滯後的地方是沉重動畫或 GPU 密集型工作量。

我應該使用 Expo 還是裸露 React Native？ Expo。在 2026 年，這根本不是近乎的選擇。Expo 支援幾乎每個原生 API，Expo Modules API 讓你在需要時寫入自訂原生代碼，EAS Build 消除了原生工具鏈頭痛。關於「如果你需要 X 就從 Expo 中彈出」的舊建議已過時。現在大約 85-90% 的生產 React Native 應用使用 Expo，包括主要應用。

行動項目的最小可行團隊是什麼？ 兩名開發人員和一名理解行動約定的設計師。一名開發人員應該有 React Native 經驗（即使透過你的內部培訓項目）。你可以從那裡向上規模，但在用戶端行動項目上獨自進行很危險——有太多平台特定知識需要。對於你的首個項目，考慮兼職 React Native 承包商作為安全網。

我如何處理 app store 提交和審查？ EAS Submit 自動化二進制上傳過程。但你仍然需要為元數據、螢幕截圖、隱私聲明和審查回應手動管理 App Store Connect 和 Google Play Console。Apple 的審查過程通常需要 24-48 小時。預算 1-2 週首次提交因為潛在拒絕。常見拒絕原因：缺失隱私政策、不充分登入功能和不完整元數據。

如果我們只有 5-10 名開發人員，是否值得提供行動開發？ 絕對地——那實際上是開始的理想規模。你不需要從第一天開始一個專業行動團隊。通過培訓 2-3 個你最強的 React 開發人員開始，一次承擔一個行動項目，並從那裡增長。網頁和行動之間的代碼共享意味著你的團隊沒有被分割——他們跨平台工作帶著共享基礎。查看我們的 pricing page 或 直接聯繫，如果你想討論類似規模的其他代理商如何完成這次過渡。