React Native for Web Agencies: 2026年向Next.js实践添加移动应用
客户要求开发iOS应用。你打开Expo的文档，快速浏览设置指南，心想：这能有多难？ 三周后，你在晚上11点调试导航库，你的设计师问为什么字体在Android上的渲染方式不同，而你的利润率就此消失在你没有计费的平台特定问题中。我用昂贵的代价学会了React Native——在发布四个代理项目后，我才破解了真正保护你时间表的代码共享数学。价值935亿美元的移动市场在2025年到来，客户现在期望原生应用与你的Next.js构建相伴，如果你已经写React，你已经走完了68%的路。但在"在我的模拟器上运行"和发布不会耗尽你周末时间的生产应用之间存在一个雷区。这是我希望在2023年就拥有的扩展行动指南——真实成本、能让你远离Xcode地狱的Expo + EAS Build技术栈，以及将移动从风险转变为你最高利润率服务的定价结构。
本文是我希望在我们开始认真接待移动客户时拥有的指南。它涵盖了工程现实、商业经济学和你需要的部署管道。没有关于"协同效应"的空头说法——只是来自发布生产应用的来之不易的经验教训。
目录
- 为什么2026年是Web代理转向移动的正确时机
- React生态系统重叠：什么实际上会转移
- Expo在2026年：改变一切的平台
- Next.js和React Native之间的代码共享
- EAS Build和部署：你的CI/CD管道
- 代理经济学：定价、人员配置和利润
- 何时说是（和否）移动客户
- 工程成本：没人谈论的数字
- Web代理的实际迁移路径
- 常见问题
为什么2026年是Web代理转向移动的正确时机
时机论证不仅仅关于市场规模。它关于三个汇聚的具体转变：
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万亿美元。但对代理更相关的是：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>对<View>）相对而言是微不足道的。
转移得比我预期差的是布局。是的，React Native使用Flexbox。但它是Flexbox，其中flexDirection: 'column'是默认值，没有display: grid，没有媒体查询（你使用useWindowDimensions），也没有级联样式。我们团队中的每个开发人员在第一周都在这上面绊倒了。
Expo在2026年：改变一切的平台
如果你在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模拟器和Android模拟器（或通过Expo Go的物理设备）上运行，用时不到两分钟。
Expo Router：从Next.js的桥接
Expo Router值得特别关注，因为它是Next.js开发人员适应快速的最大单一原因。看看结构：
app/
(tabs)/
index.tsx # Home标签
settings.tsx # Settings标签
_layout.tsx # 标签布局
profile/
[id].tsx # 动态路由
_layout.tsx # 根布局
如果你使用Next.js App Router进行构建，这个结构几乎相同。动态路由、布局、嵌套导航——概念直接映射。主要区别是移动导航使用栈和标签而不是页面和URL路径，但Expo Router优美地抽象了这一点。
Next.js和React Native之间的代码共享
这是代理获得真实ROI的地方。在网络和移动之间共享代码不仅仅是很好有的——它是提供两种服务的经济理由。
共享什么
积极共享：
- 业务逻辑和工具函数
- API客户端和数据获取hooks
- 状态管理存储
- 类型定义和验证模式（Zod在这里效果很好）
- 身份验证逻辑
谨慎共享：
- 设计令牌（颜色、间距、排版比例）
- 组件逻辑（但不是组件渲染）
不共享：
- UI组件直接（渲染基元不同）
- 导航逻辑
- 平台特定动画
单仓库设置
2026年的标准方法是Turborepo或Nx单仓库。这是一个典型结构：
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 "Fix checkout button alignment"
这对代理来说是巨大的。原本需要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阶段（第一个移动项目）：你的资深React开发人员领导，有React Native经验的承包商作为指南。为承包商预算$15-25K。
- 第2阶段（2-3个项目）：你的团队有足够的经验。雇用一个具有强大React Native背景的开发人员作为移动领导。
- 第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天进行拒绝-重新提交周期的情况。
Web代理的实际迁移路径
如果你对向你的实践添加移动持乐观态度，这是我推荐的路径：
第1-2个月：内部项目 使用Expo构建一个简单的内部应用。时间跟踪器、项目仪表板，无论什么。让你的团队在没有客户压力的情况下熟悉工具。使用它来设置你的单仓库结构、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用于单仓库管理
- 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>对<View>、<span>对<Text>）。但是，你可以通过自定义hooks共享组件逻辑、共享设计令牌，并使用Solito或react-native-web等库来桥接差距。实际上，我们在平台之间共享总代码的40-60%，主要是业务逻辑和数据层代码。
维护React Native应用年度成本是多少？ 对于典型的中等复杂度应用，预期每年$36K-$96K的维护成本。这涵盖OS兼容性更新（iOS和Android每年发布主要版本）、依赖项更新、错误修复、小功能添加和App Store政策合规性。这是一个真实成本，客户需要为其预算。
React Native在2026年对生产应用足够快吗？ 是的，明确地。随着新架构（Fabric + TurboModules + JSI）现在成为默认值，React Native应用一致地达到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承包商作为安全网。
我如何处理应用商店提交和审查？ EAS Submit自动化二进制上传过程。但你仍然需要手动管理App Store Connect和Google Play Console用于元数据、屏幕截图、隐私声明和审查回复。Apple的审查过程通常需要24-48小时。由于潜在拒绝，为首次提交预算1-2周。常见的拒绝原因：缺失隐私政策、不充分的登录功能和不完整的元数据。
如果我们只有5-10名开发人员，提供移动开发值得吗？ 绝对值得——那实际上是开始的理想规模。你不需要从第一天开始的专门移动团队。先培训2-3个最强的React开发人员，一次进行一个移动项目，从那里增长。网络和移动之间的代码共享意味着你的团队没有分裂——他们跨平台工作，具有共享基础。如果你想讨论其他相似规模的代理如何进行了这种过渡，请查看我们的定价页面或直接联系我们。