AIexpo性能react-native小组件

2026 年，做一款能赚钱的移动应用，最好的方式是什么

对 Expo 最佳技术栈的一家之言，应用变现的数据说明了什么，以及为什么你仍然应该选择 React Native 来取胜

Expo BlogPerttu Lähteenlahti13 分钟阅读

中文
中文日本語
复制
Best way to build a mobile app that makes money in 2026

本文是 Perttu Lähteenlahti 的客座文章——他是 RevenueCat 的开发者布道师，主要工作是帮助开发者通过应用赚钱。

移动应用这门生意已经变得非常残酷，而这一点被讨论得远远不够。根据 RevenueCat 的《2026 年订阅应用现状报告》，该报告覆盖了超过 115,000 款应用、约 160 亿美元收入，排名前 25% 的应用同比增长了 80%，而排名后 25% 的应用则萎缩了 33%。市场正在分化为赢家和输家两个阵营。

问题在于，这个差距其实并不来自更好的点子。排名前四分之一的应用里，大多数并没有做什么别人没想到的事。它们做的事和别人一样，只是发布更快、测试更多，并且把变现当作一个持续迭代的过程，而不是事后才想起来的事。

本文将讨论如何打造一款能赚钱的移动应用：选对技术栈，借鉴最优秀应用在变现上的做法，并看看 Expo 应用要胜出需要什么。这篇博客是我下周在 App.js 大会演讲的开胃菜，我在那里要讲的是 AI 是否正在让 React Native 过时。这些观点直接来自我为回答这个问题所做的研究，以及另一个问题：用 React Native 应用能赚到钱吗，还是干脆让 agent 把你用 Swift 或 Kotlin 写的应用移植到其他平台？

2026 年的技术栈，观点鲜明

我的技术栈观点非常鲜明，随着文章深入你会明白为什么。归根结底，这套技术栈围绕几个核心理念：

  • 构建要快，交付要更快

  • 尽可能利用操作系统层面的原生 API

  • 离线体验要令人愉悦且响应迅速

遵循这些核心理念，我的技术栈这些年一直在变，不断用更好用或 DX 更佳的新工具替换旧工具：

  • Expo 和 EAS 负责构建、提交和更新应用。一切都从这里开始。几年前我会选择裸 React Native 应用，现在没有 Expo 我根本不会考虑发布。

  • Tanstack query：管理数据获取、mutation 以及一般意义上的服务端状态。搭配 react-native-network-info 和 react-native-mmkv，可以构建出能优雅处理离线状态的应用。

  • expo-apple-targets：用来切入原生代码。原生集成很重要。别做那种用不上 widget、App Intents、Spotlight 搜索和实时活动的应用。用户期待这些功能。

  • RevenueCat：负责订阅、付费墙和权益。当然我有立场——我在 RevenueCat 工作。但就算你不打算在这件事上听我的，也请记住这条经验：别自己搭订阅基础设施。你的应用和它的变现才是你的业务，支付基础设施不是。

上面每一项选择都能帮你省回时间，而省回来的时间，就是「一个周末上线」和「一个季度上线」之间的差距。一个独立开发者，配上一个调教得当的 agent 和这套技术栈，几天之内就能在一个真实应用里收真金白银了。

这套技术栈之所以对变现重要，是因为从统计上看，React Native 应用更会赚钱。State of Subscription Apps 报告按框架拆分了收入，而 React Native 应用在几乎所有关键指标上都领先原生应用和 Flutter 应用：每次安装带来的收入、付费用户留存、生命周期价值。过去两年的数据都差不多，所以不能说这只是 AI 驱动开发带来的异常。

React Native 为什么变现表现好，我以前写过：一句话总结，React Native 吸引的是那种从一开始就冲着上线速度和跨平台覆盖去优化的开发者，而这类人往往把变现当成产品问题，而不是事后才想的事。React Native 还让快速迭代成为可能，迭代带来更好的质量，更好的质量带来更好的终端用户体验，而更好的体验让你赚更多钱。

应用变现速查表

关于应用变现的建议，要么空泛得离谱（“找到产品市场契合点！”），要么只是基于个别应用的表现。对一个人管用的方法，换个人未必行得通。这件事和产品开发中的几乎所有事情一样，归根结底要靠实验。

不过为了写这篇文章，我花功夫把那份 330 页的《订阅应用现状》报告从头读了一遍，挑出对 React Native 开发者最重要的洞察，并把它们整理成一套可以用来搭建变现策略的思路。

1. 用户是在第 0 天决定去留的

三天试用期的取消，有 55% 发生在第 0 天。不是直觉上以为的第 3 天——试用即将转化为付费的那一刻。用户安装应用的当天，很可能在下载并订阅试用后几分钟内，就已经取消了。

这说明，争夺订阅用户的整场战斗都发生在第一次会话里。一旦输了，就永久失去这个订阅用户。实际操作中，你得假设自己只有一次机会去制造那个“原来如此”的时刻。不要让用户在看到应用是否带来他们想要的价值之前，先等待、注册、填一堆字段。注意力本来就短，对繁琐界面的容忍度更低。

我自己做应用或给其他开发者提建议时，总是强调要把流程做成这样：用户第一次打开应用后 30 秒内就能看到自己的数据。比如我的应用 Netli.fyi，引导流程只有三条要点、一次授权，然后就直接显示你的项目和部署。用户喜欢的其他功能，比如通知，放到后面再引入，因为请求权限会在流程中造成摩擦。

我发现这种“让我看到我的东西”的做法对工具类应用（比如开发者工具）很有效，但其他类型的应用需要不同的策略。比如健康类应用，数据没那么重要，重要的是让用户为使用这款应用设定长期目标。

Over-the-air updates 正是为此而生。借助 Expo 的 OTA Updates 这类方案，你可以在周一上线一套新的引导流程，过几天看数据，一周之内就能部署一套摩擦更小的流程，完全不用等 App Store 或 Google Play 审核——尤其是在两家商店的审核时间都从几小时慢慢拖到几天的现在。

对新用户来说，引导页就是最重要的页面，你应该像迭代落地页那样迭代它：分析流失、做 A/B 测试，搞清楚用户到底在哪一步走掉。把引导流程打磨到位，你就已经改善了第一个指标：下载到付费。

2. 付费墙是产品，不是一个页面

我经常见到的一个错误是：花几周时间打磨 App，最后却配上一个最欠考虑的付费墙。付费墙做得敷衍，下载量转化不成订阅又有什么奇怪？付费墙是产生收入的那个页面，它至少该得到和你的功能同等的重视。

这里的数据很有意思，也有点反直觉。硬付费墙——也就是必须先订阅才能解锁任何内容的付费墙——在安装时的转化率大约是 freemium 的五倍：10.7% 对 2.1%。差距大到如果你的主要目标是转化，那就只该做硬付费墙。

但与此同时，一年之后，硬付费墙和 freemium 的留存率几乎一样。硬付费墙在前期拉来更多付费用户，带软付费墙的 freemium 转化更慢，但两者最终走到的地方差不多。问题不再是哪个更好，而是哪个适合你的 App。

拿同类 App 做基准对比，有助于判断该选哪种。冥想类或健身类 App，用户需要几周时间才能感受到价值，freemium 大概率更合适；而像照片编辑器这种，用户第一分钟就知道自己想不想要，这时候不做硬付费墙就是在白白丢钱。

软付费墙很诱人，目标是让尽可能多的用户至少用上一部分功能。我自己也多次掉进过这个思路里。但免费使用应用的用户，目标往往和最终付费的用户完全不同。想象你是一家餐厅老板，主营业务是一份人人都爱的五道菜套餐。你推出一个免费档位，只提供面包棒和自来水，就为了让餐厅坐满人，这几乎不会让你的核心业务变好。一切看起来肯定更热闹了，也许那些吃面包棒的人里有些最终会买套餐，但你会真的把他们叫做顾客吗？

这一节归根结底还涉及另一件事：测试。无论你选哪种模式，都应该对它做测试。最好的付费墙可以远程配置，并提供实验功能，也就是说你不需要发新版本就能改文案、改优惠、改价格或改 UI。既然付费墙是一个产品，你就应该经常改动它，然后测试哪些改动改善了体验。

3. 你的试用期很可能设错了

《订阅应用现状》里有一个数据让我脑子卡了一下：17 天及以上的试用期，转化率比 3 天及以内的试用期高 70%。42.5% 对 25.5%。然而报告里近一半的应用现在都在用 4 天及以内的试用期。你自己大概也见过，很多应用给月度订阅配一个三天试用。

这种情况下可以放心地说，整个行业一直在朝错误的方向走。直觉告诉人们，试用期越短越有紧迫感。数据却说，试用期越长，用户才越有可能真正把应用融入日常，而这才是他们在试用结束时付费的原因。

根据我和开发者的交流，人们选三天试用期，是想优化现金流：更快拿到转化，更快看到指标变化。但这样做，你是用一个大得多的转化率提升，去换一个稍微快一点的信号。这笔交易不划算。

如果你现在跑的是三天试用，这个月最容易做的实验就是拿 14 天或 21 天的版本和它对比。

4. Android 的扣款失败是白白丢掉的收入

这一条只针对 Android，而且属于那种没人会聊、直到某天翻数据才发现自己三分之一的流失本来可以避免的问题。

Google Play 上大约 30% 的订阅取消是非自愿的。也就是说，用户根本没打算走，只是扣款失败了——原因可能有很多，比如卡过期了，或者银行的风控拦下了它不认识的扣款。在 App Store 上这个数字大约是 14%。所以如果你做的是 Android，你因为纯机械原因流失的用户比例是 iOS 的两倍还多。

好消息是这不是产品问题，是管道问题，而管道问题属于修一次就能忘掉的那种。加上更长的宽限期、扣款重试逻辑、账号冻结恢复流程——这些功能大多只要在后台打开开关就行。第一次开启之后，你大概率能挽回相当一部分本来会被你算作流失的用户。除此之外，你还顺带改善了 App 的使用体验。

如果你的 App 以 Android 为主，而你还没审查过扣款失败的挽回流程，那这是你现在能做的投入产出比最高的一件事。

一个周末就能做出来

到目前为止我们聊的策略都可执行，但未必对得上工程师的思路。为了不停留在空谈产品，我们来看看怎么通过接入 RevenueCat 把这些功能全部做出来：从零到能收真钱的最短路径。用这些功能需要一个 RevenueCat 账号，完全免费，直到你的 App 月收入达到 2.5k 美元。

新建一个 Expo 项目，装两个包：react-native-purchases 和 react-native-purchases-ui。前者提供 RevenueCat SDK，用来处理应用内购买、订阅和权益。后者让你能展示在 RevenueCat 后台创建的付费墙。

npx create-expo-app my-app

cd my-app

npx expo install react-native-purchases react-native-purchases-ui

SDK 集成的大部分工作，agent 默认就能处理得不错。不过 RevenueCat 也为各大平台提供了 skills，帮你遵循 SDK 集成的最佳实践。RevenueCat skills 在这里。

下一步是把 RevenueCat 接入 App Store Connect 和 Google Play Console，并在两边配置好产品。前者可以照着这份指南做。后者过去非常痛苦，因为 Google 和 Apple 对配置产品有一堆要求，现在直接用 RevenueCat MCP 就行。MCP 让你能同时在两家商店和 RevenueCat 里添加产品和 entitlement，只需要一句这样的 prompt：

用 RevenueCat MCP 添加两个订阅，年付和月付，前者定价 49.99，后者 5.99。给月付订阅设置 14 天试用。把订阅关联到名为 ‘Pro’ 的 entitlement。订阅通过 RevenueCat Paywall 展示。

初始化 RevenueCat SDK 并展示 paywall

在应用里初始化 SDK 只需要几行：

import { Platform } from 'react-native';
import Purchases from 'react-native-purchases';

const apiKey = Platform.select({
  ios: 'appl_xxxxxxxxxxxxxxxxxxxxxxxxx',
  android: 'goog_xxxxxxxxxxxxxxxxxxxxxxxxx',
  default: 'appl_xxxxxxxxxxxxxxxxxxxxxxxxx',
});

Purchases.configure({ apiKey });

检查用户是否有生效的 entitlement（也就是能否访问应用的某些功能）只要两行：

const info = await Purchases.getCustomerInfo();
const isPro = info.entitlements.active['pro'] !== undefined;

entitlement 检查就这么多。你也可以把这些都塞进一个自定义 hook，用起来更方便：

import { useEffect, useState } from 'react';
import Purchases, { CustomerInfo } from 'react-native-purchases';

type UseEntitlementResult = {
  isActive: boolean;
  isLoading: boolean;
};

export function useEntitlement(entitlementId: string): UseEntitlementResult {
  const [isActive, setIsActive] = useState(false);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    let cancelled = false;

    const update = (info: CustomerInfo): void => {
      if (cancelled) return;
      setIsActive(info.entitlements.active[entitlementId] !== undefined);
      setIsLoading(false);
    };

    const load = async (): Promise<void> => {
      try {
        const info = await Purchases.getCustomerInfo();
        update(info);
      } catch (e: unknown) {
        if (cancelled) return;
        console.warn('RevenueCat: failed to fetch customer info', e);
        setIsLoading(false);
      }
    };

    void load();
    Purchases.addCustomerInfoUpdateListener(update);

    return () => {
      cancelled = true;
      Purchases.removeCustomerInfoUpdateListener(update);
    };
  }, [entitlementId]);

  return { isActive, isLoading };
}

export const useIsPro = (): UseEntitlementResult => useEntitlement('pro');

用 hook 的返回值包住需要付费才能用的功能，就完事了。

把 RevenueCat Paywalls 组件放到实际的购买页面上，你就得到了一个可以直接在 dashboard 里更新、无需重新发版的 paywall：

import RevenueCatUI from 'react-native-purchases-ui';

function PaywallScreen({ navigation }) {
  return (
    <RevenueCatUI.Paywall
      onPurchaseCompleted={() => navigation.goBack()}
      onRestoreCompleted={() => navigation.goBack()}
      onDismiss={() => navigation.goBack()}
    />
  );
}

这个 Paywall 可以在 RevenueCat dashboard 里创建，用拖拽式构建器，或者直接用 AI builder 写 prompt。如果你在找 paywall 灵感：看看这个。

最后一件事是提交应用到 EAS，好把它送到你妈手里，或者任何你想打动的人手里：

eas build --platform all
eas submit

这些内容你大概早就熟悉了，所以这一节想强调的其实只有一点：整件事主要靠产品策略，而不是开发本身。全部加起来就是一个周末的工作量。你花的大部分时间会在 App Store Connect 和 Google Play 的各种手续上，而不是代码上。

我之所以在这个问题上花这么多笔墨，是因为一年前，我刚才描述的那些工作至少需要一两周。再往前几年，耗时还要翻好几倍。工程流程变快了，但做出好产品依然需要时间，只不过现在的起点，已经比你过去一周的成果还要高。

时间到底该花在哪里

基础设施的问题解决之后，你大概省下了原本要投入在基建上的 80% 工程时间。接下来该拿这些时间做什么，才是真正的问题。我认为只有三件事值得做。

第一是新手引导。你可以用 EAS 更新持续迭代，不必等漫长的商店审核。无论今天的激活漏斗长什么样，六个月后的版本都应该让人认不出来——因为这中间你至少应该上线过 20 个变体。

第二是付费墙。道理一样。把它当成一个每周都要测试的活界面：新的文案、新的价格展示、新的套餐排序、新的试用时长。有了 RevenueCat Paywalls，这些测试大多根本不需要发版。

第三是跟用户聊天（对，我知道）。这是工程师最容易投入不足的一件事，也是复利效应最强的一件事。你不需要专门的用户研究团队，你只需要读评论、回客服邮件，主动联系那些真正付钱给你的人。这些对话里浮现出的规律，比任何增长黑客手段都值钱。

技术栈接管了其余的一切之后，工作就只剩这些：做产品、迭代漏斗、跟人聊天。

关于 AI 应用和用 AI 做应用

这里有一个值得单独拎出来的注脚，因为 2026 年上线的应用里，有一半都会带点 AI。State of Subscription Apps 报告里的数据很有意思：AI 驱动的应用，每位付费用户带来的收入比非 AI 应用高 41%。热度是真的，付费意愿是真的，每用户平均收入也是真的。

但有一点你必须先接受，才能动手做：AI 应用的流失速度也快 30%。用户注册、兴奋一阵、用上一周，新鲜感过去，然后取消订阅。

这说明，如果你在做 AI 应用，你的变现问题不在定价，而在留存。如果根本问题是应用到了第二周就不再让人觉得有用，那就别把时间花在优化试用期长度和付费墙文案上。先解决留存——让留下来的理由大过离开的理由。只有当你有了一个人们愿意持续使用的产品，定价优化才有意义。

今天就去把你的应用做出来

独立开发者和团队现在手上的工具，几年前我们只能想想。AI 接管了实现中枯燥的部分。Expo 和 React Native 解决了发布到两个平台的成本。

剩下的，是一直以来本来就最难的那部分：找到一个真正值得解决的真问题，然后不停地发布。基础设施不再是瓶颈了。你才是。

如果你读到了这里，想要更长的版本，我这个月在 App.js 有一场演讲，题目是 Is AI making React Native obsolete?。里面讲了我做了几个月的副业项目——用三种方式构建同一个应用，包括完全通过 agentic coding 把一个 SwiftUI 应用转成 Kotlin——以及这个实验告诉我们，在 AI 辅助开发时代 React Native 处在什么位置。剧透一下：这篇文章我是在 Expo 博客上写的，所以你大概能猜到我的结论。但细节很有意思。如果你会到场，来打个招呼。

来源: Expo Blog← 返回首页