Apple 上海开发者中心，这个工作坊开始还不到十分钟，第一个认真讨论的话题，是电压。

来自 Blackmagic 的工程师举起一块电池，提出问题：升压模块把 18 伏拉到 24 伏以上，能不能稳定录制？

房间里安静了一下。

答案是不能——这台造价二十多万元的 Blackmagic URSA Cine Immersive 摄影机，需要 112 瓦以上持续供电才能正常运转，而升压后只能到 90 多瓦。看起来在工作，但真到 90 帧高规格录制的时候，素材很有可能会丢帧。

这是摄制高规格沉浸式内容时才会遇到的问题，迄今业内也没有多少人知道这个点。

一年前，这个问题还不存在——彼时，Blackmagic URSA Cine Immersive 摄影机才刚启动发货。

迄今为止，Apple Vision Pro 依然是地球上唯一能够完美显示这些内容的设备。

现场的几十个团队，大多已经用过 Apple Vision Pro，为这台设备拍过东西，有些甚至交付了项目。他们来这里，只想解决一件事：怎么制作高规格的沉浸式内容？

但他们面对的具体问题多如牛毛，没有人知道标准答案。

从工程问题，到影视问题

这个开发者中心过去接待的，大多是做编程、设计和游戏的开发者，内容创作者如此集中出现，还是头一次。

制作高规格的沉浸式影像，门槛高到不可思议——

当时，没有专用摄影机，也没有能处理这种格式的剪辑软件，有的只是苹果给出的一份格式规范。

想从拍摄走到交付，每一步要么自己写代码，要么改造现有工具。一个项目组踩过的坑，下一个项目组还得从头再来。这块领域的早期创作团队，掌镜的往往是工程师，而不是摄影师。

2024 年 12 月，Blackmagic 推出了第一台专门为沉浸式影像设计的摄影机，但直到一年后，DaVinci Resolve 20.1 发布，才第一次全面支持沉浸式影像工作流。

RAW 文件直接进达芬奇，剪辑、调色、空间音频混音，元数据全程保留，整个链路终于可以不靠代码跑通。

新的障碍紧跟着就来了。

仅仅拍了 16 分钟，原始素材就超过了 1.2TB，这意味着存储和传输方案要从头设计。

监看更麻烦，2D 监视器展示不了真实的双目景深，左右眼对齐误差在平面屏上根本看不出来，等后期发现基本只能重拍。有摄影师说，宽角预监画面几乎是「有误导性的」，只有在头显端实时看，才知道实际拍到了什么。

机位逻辑也完全不同——空间影像没有变焦，拍一场演唱会可能要同时架二三十台定焦机器，由剪辑师在后期选镜头。什么时刻该切镜头、切去哪、观众的注意力在哪？

很多传统影像的经验在这里失效。

The Weeknd 的沉浸式短片「Open Hearts」只剪了 30 刀，但同一首歌拍成普通 MV 要剪 300 到 400 刀。

当观众可以自己转头扫视整个空间时，快速剪辑的英雄镜头就失去了意义。内容的主动权，一部分还在导演手里，但大部分已经被交还到观众手上。

观众到底想看什么？

我们联系到了一家位于广州的 XR 体验店，店主 Jeffrey 也是一位 XR 领域的资深媒体人，他告诉爱范儿，短短一个多月，他们已经做到了这个片区的团购第一，全靠一台 Apple Vision Pro。

CORTIS 是 2025 下半年才声名鹊起的 K-pop 男团，在工业化高度发达的韩国演艺圈，为偶像拍摄零距离的沉浸式影片是一种常见的营销方式——而 CORTIS 选择了用 Apple Vision Pro，显然是看中了其绝佳的清晰度和沉浸感。

2026 年 1 月 30 日，CORTIS 练舞的沉浸式影片《NEAREST: CORTIS》在 Apple TV 免费上线，凭借浸入感极强的演出和身临其境的视听效果，收获了极佳的口碑，在粉丝群体间口口相传——但真正能看到这条影片的人凤毛麟角。

以 Apple Vision Pro 为核心设备的体验店得到了破圈的机会。

一般来说，这类体验店的辐射半径是 5 公里，但随着粉丝们的种草笔记在小红书上自发扩散，梦想和偶像零距离接触的观众从四面八方涌来。

Jeffrey 说，客人觉得这个内容好到能忽略设备的一切缺点——压脸、闷热、弄乱发型……都不介意。过去这么多年里，VR 内容的出圈和推广是极其艰难的，但 Apple Vision Pro 的沉浸式影片，打破了这样的困境。

沉浸式影片里呈现的，是现实世界的真实视差。成员就站在你旁边，你看向他时，就像真的站在练舞室里。无数立体的细节扑面而来，营造前所未有的真实感，真实得像做梦一样。

苹果官方有一套评估沉浸式影像的画质标准，其中最重要的尺度，不是分辨率也不是像素密度（PPI），而是「感知清晰度」——简单来说，就是视力表。

苹果希望每一部登录 Apple Vision Pro 的高品质沉浸式影片，都能还原肉眼观看世界的体验——近处的内容细节丰富，远处的画面自然会有些模糊，但他们的帧率、色彩、亮度都尽可能贴近真实的视觉感受。

唯有如此，才能保证绝佳的沉浸感。

于是，当我们戴上 Apple Vision Pro，才能置身万米高空的索道、来到 NBA 全明星现场、伫立在西班牙斗牛跟前——这些难以亲临的造梦现场，是观众真正想看到的内容，是一种前所未有的稀缺体验。

造梦，AI 时代的稀缺体验

根据 IDC 的预测，2025 年，Apple Vision Pro 出货量只有 10 万台左右，上市两年仅仅卖出了 50 多万台——这可能是 iPhone 面世以来，苹果最滑铁卢的产品。

太重，太贵，太超前，成为判 Apple Vision Pro 死刑的理由。

但苹果在 Apple Vision Pro 内容上的投资从未停过。

过去两年，Apple TV 已经上线了超过 30 部沉浸式影片，每隔一两个月总会有些新东西看——

从棒球场到篮球场，从恐龙纪元到动物世界，从二战潜艇到高空钢丝，从男团练舞室到演唱会现场……很难想象，苹果会为一台出货量跌了九成的设备，稳定持续地更新生产成本高昂的内容。

显然，苹果从来没有觉得 Apple Vision Pro 完蛋了，倒不如说，苹果正在给 Apple Vision Pro 的未来下注——为未来注定更加稀缺的造梦体验下注。

在过去两年使用 Apple Vision Pro 的过程中，我经常会有类似的感受——戴在我头上的，到底是未来的 iPhone、Mac 还是 iPad？

Apple Vision Pro 是一个没有经过「剪裁」的产品，苹果也不知道用户想要什么，于是把所有的东西都给了用户。

未经剪裁的 Apple Vision Pro 搭载了太多的功能，也面临太多的妥协。但至少，让人真假难辨的造梦体验，是 Apple Vision Pro 无可取代的部分。

三年前，Apple Vision Pro 和 ChatGPT 分别代表了科技行业最受瞩目的技术方向，但前者是卖了 50 万台的极客玩具，而后者则改变了 10 亿人的生活方式。

于是，当生成式 AI 把内容的生产门槛降到最低时，我们也将迎来数字内容最饱和的时代。

那时候，观众到底想看什么？

1984 年，威廉·吉布森在《神经漫游者》里描绘了一种全新的媒介——「拟感」（simstim）。

那是把一个人的完整感官体验录成数据，传进另一个人的神经系统，从而实现感同身受的体验。

在经典赛博朋克世界观里，这是将电视电影取而代之的东西。

Apple Vision Pro 的沉浸式影片，提供了当下最接近「拟感」的体验——那是一种要求你必须在场，要求你用自己的感官，去经历真实与虚妄的造梦体验。

我说不好这到底是不是未来，但我看到全球各地已经有许多人，他们在拍了，他们在做了。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

uni-app scroll-view 滚动卡死？一行CSS直接复活（iOS必看）

做uni-app开发的同学，有没有遇到过这种崩溃场景：页面用了scroll-view做滚动容器，点击Tab切换锚点后，整个页面突然不能滑动了，刷新也没用，只有重新进入页面才能恢复？

我最近就踩了这个坑，花了大半天排查，最后发现居然只要一行CSS就能解决，今天把整个排查过程和原理分享出来，帮大家避坑，尤其是做iOS端开发的同学，建议直接收藏备用！

一、问题复现（和我遇到的一模一样）

先给大家还原下我遇到的场景，方便大家对号入座：

• 页面结构：用 scroll-view 包裹整个页面内容，内部分3个模块（基本信息、买车意向、卖车意向），顶部有Tab切换，点击Tab通过 scroll-into-view 实现锚点定位。

• 问题现象：进入页面后，点击「卖车意向」Tab，锚点直接定位到模块最底部；此时尝试上下滑动页面，发现整个页面完全卡死，不能向上滑，只能向下滑（甚至向下滑也不流畅），刷新页面也无法恢复。

• 环境：iOS端（真机+模拟器+Safari浏览器都复现），Android端正常，小程序端正常。

一开始我以为是锚点定位逻辑写错了，反复检查scroll-into-view、锚点高度计算，改了半天还是卡死，直到加上一行CSS，瞬间复活！

二、排查过程（踩坑记录，帮你省时间）

排查过程中，我走了3个弯路，大家可以跳过这些无效操作，直接看解决方案：

弯路1：怀疑锚点高度计算错误

一开始觉得是锚点高度获取有误——页面有「展示完整信息」的折叠/展开功能，初始化时获取的锚点高度是折叠状态的，展开后高度变化，导致定位偏移，进而触发滚动异常。

于是封装了锚点高度重新计算方法，在折叠/展开、Tab切换后重新查询DOM高度，虽然解决了锚点定位到底部的问题，但滚动卡死依然存在。

弯路2：怀疑scroll-view滚动逻辑错误

接着检查scroll-view的滚动监听方法（scrollChange），发现里面有复杂的高度判断逻辑，比如用anchor2TopCopy动态计算偏移量，以为是判断条件出错导致滚动锁死。

简化了滚动监听逻辑，改成简单的三段式判断（根据滚动距离切换Tab），锚点定位更精准了，但滚动卡死问题还是没解决。

弯路3：怀疑scroll-view样式配置错误

检查scroll-view的样式，确认已经设置了scroll-y="true"、flex:1、height:100%，没有多余的overflow样式冲突，排除了样式配置问题。

关键突破：定位到iOS原生回弹冲突

因为只有iOS端有问题，Android端正常，猜测是iOS原生特性和uni-app scroll-view的冲突。想起iOS有个「橡皮筋回弹」效果（overscroll），当scroll-view滚动到边界时，继续拉拽会出现空白回弹，会不会是这个回弹导致滚动状态错乱？

抱着试试看的心态，加了一行禁止回弹的CSS，没想到——滚动瞬间恢复正常，卡死问题彻底解决！

三、解决方案（一行CSS搞定，直接复制）

就是这行CSS，直接复制到你的页面样式中，iOS端滚动卡死问题瞬间解决：

::v-deep .uni-scroll-view, 
::v-deep .uni-scroll-view-content {
  /* 禁止iOS橡皮筋回弹，解决scroll-view滚动卡死 */
  overscroll-behavior: none;
}

补充说明：

• ::v-deep 必须加：因为uni-app的scroll-view是组件封装的，需要穿透样式到子组件。

• 适配范围：同时作用于.uni-scroll-view和.uni-scroll-view-content，确保所有滚动容器都禁止回弹。

• 不影响其他功能：这行代码只禁止“边界回弹”，不影响正常滚动、锚点定位，Android端不受影响（overscroll-behavior在Android上兼容性有限，不会生效，也不需要生效）。

完美搭配（解决锚点+滚动双重问题）

如果你的页面也有折叠/展开模块，建议搭配锚点高度重新计算方法，实现“锚点精准+滚动流畅”：

// 重新计算所有锚点高度（折叠/展开后调用）
updateAnchorTop() {
  const query = uni.createSelectorQuery().in(this);
  query
    .select('#anchor1') // 基本信息锚点
    .select('#anchor2') // 买车意向锚点
    .select('#anchor3') // 卖车意向锚点
    .boundingClientRect((res) => {
      if (res[0]) this.anchor1Top = res[0].top;
      if (res[1]) this.anchor2Top = res[1].top;
      if (res[2]) this.anchor3Top = res[2].top;
    })
    .exec();
},

// 折叠/展开按钮点击事件
arrowClick() {
  this.arrow = !this.arrow;
  // 等待DOM渲染完成后重新计算锚点高度
  this.$nextTick(() => {
    this.updateAnchorTop();
  });
}

四、问题原理（为什么这行CSS能解决？）

核心原因：iOS的橡皮筋回弹（overscroll）与uni-app的scroll-view锚点定位冲突，导致滚动状态锁死。

1. 当点击Tab触发scroll-into-view锚点定位时，若定位到模块底部，会触发iOS的“越界回弹”（overscroll）。

2. uni-app的scroll-view组件底层对滚动状态的处理，与iOS原生回弹机制不兼容，回弹后会导致scroll-view的滚动事件被阻塞，出现“卡死”。

3. overscroll-behavior: none 的作用就是禁止元素的越界回弹行为，从根源上避免了冲突，滚动状态自然恢复正常。

补充：这不是你的代码写错了，而是uni-app在iOS端的一个经典兼容性bug，很多开发者都遇到过，一行CSS就能规避。

五、常见补充场景（避坑延伸）

如果加上这行CSS后，滚动还是有问题，大概率是以下2个原因，对应解决即可：

场景1：scroll-view高度计算错误

确保scroll-view的父容器有明确高度，scroll-view本身设置：

scroll-view {
  flex: 1;
  height: 100%;
  overflow-y: auto; /* 兜底，避免滚动异常 */
}

场景2：Tab切换锚点定位不精准

在Tab点击事件中，等待DOM渲染完成后再赋值锚点，避免异步高度问题：

tabClick(e) {
  this.indexNum = e;
  this.$nextTick(() => {
    this.anchor = e === 0 ? 'anchor1' : e === 1 ? 'anchor2' : 'anchor3';
    // 定位后兜底校准高度
    setTimeout(() => this.updateAnchorTop(), 100);
  });
}

六、总结

如果你在uni-app开发中，遇到iOS端scroll-view滚动卡死、不能滑动的问题，尤其是结合锚点定位、Tab切换时，直接用这行CSS就能解决：

::v-deep .uni-scroll-view, 
::v-deep .uni-scroll-view-content {
  overscroll-behavior: none;
}

本质是规避iOS原生回弹与uni-app scroll-view的兼容性冲突，属于“一招制敌”的解决方案。

另外，结合锚点高度重新计算方法，能同时解决“锚点定位偏移”和“滚动卡死”两个问题，适配更多复杂页面场景。

希望这篇文章能帮你节省排查时间，避免踩坑～ 如果还有其他uni-app滚动相关的问题，欢迎在评论区交流！

最后，求个点赞收藏，你的支持是我分享的动力 😊

前言

大家好，我是 笨笨狗吞噬者，uni-app、varlet、nrm 等众多知名仓库的核心开发，专注于分享前端技术和 AI实践知识，本篇文章是 uni-app 小程序源码解读的第一期，欢迎关注我的微信公众号 前端笨笨狗！

很多人在使用 uni-app 时，会很自然地写出 uni.showToast()、uni.login() 这样的代码，但很少会继续追问一个问题：为什么同样是 uni.xxx，到了微信能落到 wx.xxx，到了支付宝又能落到 my.xxx？

这个问题背后，藏着一个巧妙的设计思路。它既不是简单的字符串替换，也不是把所有平台 API 硬编码映射一遍，接下来我们慢慢揭秘。

问题背景

在 uni-app 小程序端，开发者写的是：

uni.showToast({ title: 'Hello' })
uni.login()

但真正运行时：

• 微信里调用的是 wx.xxx
• 支付宝里调用的是 my.xxx

这一层统一，核心就靠两样东西：

• Proxy：决定 uni.xxx 这次到底取哪个实现
• wrapper：把不同平台之间的参数、方法名、返回值差异包起来

对应源码入口在 https://github.com/dcloudio/uni-app/blob/uni-app-vue3-dev/packages/uni-mp-core/src/api/index.ts#L61。

Proxy：统一入口分发

先看核心代码：

export function initUni(api, protocols, platform = __GLOBAL__) {
  const wrapper = initWrapper(protocols)
  const UniProxyHandlers = {
    get(target, key) {
      if (hasOwn(api, key)) {
        return promisify(key, api[key])
      }
      if (hasOwn(baseApis, key)) {
        return promisify(key, baseApis[key])
      }
      return promisify(key, wrapper(key, platform[key]))
    },
  }

  return new Proxy({}, UniProxyHandlers)
}

这段代码的意思很简单：

uni 不是一个提前写死所有方法的对象，而是一个“访问属性时再决定返回什么”的代理对象。

比如你写：

uni.showToast

这时会触发 get(target, key)，其中：

• key 就是 showToast
• 代理会临时判断这个方法应该从哪里来

也就是说，Proxy 的作用不是执行 API，而是做一次统一分发。

为什么这里一定要用 Proxy

因为 uni 的目标不是“绑定某个平台”，而是“对外提供稳定名字，对内按平台切换实现”。

如果不用 Proxy，那就只能：

• 提前把所有 API 全部挂到 uni 上
• 或者每个平台都维护一套映射逻辑

这样会很笨重。

用了 Proxy 之后，框架就可以做到：

1. 开发者永远写 uni.xxx
2. 真正访问到 uni.xxx 时，再动态决定用谁
3. 同一个入口，底层可以切到不同平台对象

这正是代理最适合的场景：入口统一，底层实现可变。

这段 get 其实分了三层

源码里的分发顺序很清楚：

1. 先看 api

if (hasOwn(api, key)) {
  return promisify(key, api[key])
}

如果这个方法 uni 自己实现过，就优先返回 uni 自己的实现。

2. 再看 baseApis

if (hasOwn(baseApis, key)) {
  return promisify(key, baseApis[key])
}

像事件总线、拦截器这类基础能力，不一定来自小程序原生对象，也统一挂在 uni 上。

3. 最后兜底到平台对象

return promisify(key, wrapper(key, platform[key]))

这里的 platform 默认是 __GLOBAL__，可以理解成当前平台全局对象：

• 微信环境下接近 wx
• 支付宝环境下接近 my

所以 Proxy 最终做成了这件事：

uni.showToast -> 当前平台的 showToast
uni.login -> 当前平台的 login

wrapper：翻译平台差异

如果只是：

return platform[key]

表面上也能调用，但问题是不同小程序平台并不完全一致，常见差异有三种：

1. 方法名不一致
2. 参数名不一致
3. 返回值结构不一致

所以 Proxy 只能解决“分发给谁”，解决不了“怎么适配差异”。

这就是 wrapper 的职责。

wrapper 在这里干了什么

看最关键的一句：

const returnValue = __GLOBAL__[options.name || methodName].apply(
  __GLOBAL__,
  args
)

这里能看出两件事。

第一，wrapper 允许改方法名。

• 默认调用 methodName
• 如果协议里配置了 options.name，就改成另一个平台方法名

第二，wrapper 会先处理参数，再调用平台方法。

前面的 processArgs、后面的 processReturnValue，本质上都在做一件事：

把 uni 暴露给开发者的统一接口，翻译成当前平台真正认识的接口。

所以可以把 wrapper 理解成一个“翻译层”。

举一个最容易理解的例子

假设 uni 对外想统一成这样：

uni.showToast({
  title: '保存成功'
})

但某个平台底层不是 title，而是 content。

那 Proxy 只能做到：

uni.showToast -> 找到这个平台的方法

真正把参数从：

{ title: '保存成功' }

改成：

{ content: '保存成功' }

这一步必须由 wrapper 做。

也就是说：

• Proxy 负责“找到人”
• wrapper 负责“翻译话”

这两个配合起来，开发者才能始终写统一的 uni.xxx。

简易实现

下面写一个极简版，只保留 Proxy 和 wrapper 两层核心思想。

const wx = {
  showToast(options) {
    console.log('wx.showToast', options)
  },
}

function wrapper(name, method) {
  if (name === 'showToast') {
    return function (options) {
      const newOptions = {
        content: options.title,
      }
      return method(newOptions)
    }
  }
  return method
}

function initUni(platform) {
  return new Proxy(
    {},
    {
      get(target, key) {
        const method = platform[key]
        if (typeof method !== 'function') {
          return undefined
        }
        return wrapper(key, method)
      },
    }
  )
}

const uni = initUni(wx)

uni.showToast({
  title: '保存成功',
})

执行时虽然外部写的是：

uni.showToast({ title: '保存成功' })

但实际到平台方法时，已经被改成了：

wx.showToast({ content: '保存成功' })

总结

不是“用了 Proxy 很高级”，而是职责拆得很清楚：

• Proxy 只做入口分发
• wrapper 只做平台适配

这样设计的好处是：

• uni 对开发者始终保持统一
• 平台差异被收口在框架内部
• 后续要支持更多小程序平台时，只需要补适配逻辑，不需要改开发者写法

微信交流群

我有个 uni-app 微信交流群，大家有想进群的可以加我的微信 13460036576

刚刚，阿里巴巴 ATH 确认 HappyHorse 为阿里 ATH 旗下创新事业部研发。

前段时间网友们一直在猜测的神秘视频生成模型 HappyHorse，正式在微博介绍自己，来自阿里 ATH 创新事业部的内测产品，目前尚未上线，网上流传的「官网」都不是真的。

阿里巴巴 ATH 方面表示：HappyHorse 是阿里 ATH 旗下创新事业部研发的模型，目前正处于内测中，也会于近期开放 API。

ATH 创新事业部已启动一个 AI 时代的全新交互方式探索计划，HappyHorse 是这个探索方向的一部分，更多的产品我们会陆续推出。

APPSO 独家获悉，负责此次 HappyHorse 视频生成模型的是来自阿里 ATH 的郑波团队。

郑波是阿里巴巴副总裁，清华大学计算机系博士，2006 年到 2017 年，领导谷歌的展示广告算法团队以及中国地图团队。

他在 2017 年 9 月加入阿里巴巴，曾担任淘宝搜推算法负责人、阿里妈妈 CTO、淘天集团算法技术负责人，主要研究方向为大模型，多模态，决策智能，深度学习，搜索、推荐和广告算法以及引擎优化等领域。

本周三，HappyHorse-1.0 视频生成模型突然出现在 AI 评测平台 Artificial Analysis 的视频竞技场榜单上，以压倒性的表现登顶文生视频、图生视频等多个赛道，直接超越前段时间大火的 Seedance 2.0。

网友们都在猜测 HappyHorse 究竟是哪一家模型厂商的作品，一些山寨的「快乐马」网站也开始在社交媒体上传播，声称可以提供模型访问权限。

直到今天，HappyHorse 通过官方微博账号 HappyHorse_AI 正式发文，确认是由阿里 ATH 创新事业部研发。

AI 评测平台 Artificial Analysis 也在阿里确认这一消息后，在 X 平台迅速发文，表示 HappyHorse-1.0 目前已经在视频竞技场的所有排行榜上都取得了第 1 或第 2 名的好成绩。

在平台「无音频」排行榜上，HappyHorse-1.0 稳居第一；「有音频」排行榜中，它的 Elo 分数几乎与字节的 Seedance 2.0 完全相同。

Artificial Analysis 还提到 HappyHorse-1.0 支持四种视频生成模式：文本转视频、图像转视频，每种模式均可选择是否添加原生音频，而 API 接口计划于 4 月 30 日开放。

在这则推文下，Artificial Analysis 给出了多个 HappyHorse 视频生成的实例。

通过与Seedance 2.0、Kling 3.0 Pro、grok-video-imagine 和 PixVerse V6 的对比，我们能看到 HappyHorse 这匹突然杀出来的黑马，潜力确实不小。

在阿里今天正式宣布之前，前阿里千问大模型负责人林俊旸昨天就在 X 转发了关于 HappyHorse 的消息，附文「happy horse is insanely happy」。评论区当时就有人在猜测，看来 HappyHorse 可能是千问的视频模型。

阿里这段时间以来，关于 AI 的调整相当频繁。

3 月 16 日，阿里巴巴正式成立 Alibaba Token Hub「ATH」事业群，由 CEO 吴泳铭直接负责，ATH 覆盖了通义实验室、MaaS 业务线、千问事业部、悟空事业部、AI 创新事业部，几乎把阿里现有 AI 关键拼图全部装进了一个框架里。

4 月 8 日，CEO 吴泳铭发布全员信，再宣布 AI 相关组织的重大调整，成立集团技术委员会，原通义实验室升级为通义大模型事业部。

短短 23 天，完成了两次 AI 组织架构的调整。

HappyHorse 模型的推出，大概能看到阿里 AI 战略的主线，会不断地从模型能力，到平台分发，再到具体应用，都要争做第一，实现完整的闭环。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

这里是后厂村阴影中最神秘的“全栈侦探事务所”。当你的 if-else 走到尽头，当你的 Bug 堆积如山，资深探长“老司机”就是你最后的救命稻草。本期案卷记录了一次关于“像素与文字”的离奇遭遇：实习生阿强因“人肉 OCR”识别截图密码失败，险些引发上线事故。面对这起“视力危机”，我们拒绝蛮力，祭出了 Apple 强大的 Vision 框架。这不仅是一篇关于如何用 Swift 实现 OCR（文字识别）的硬核教程，更是一场从构建“文字捕手”到破解“坐标迷宫”的技术探险。准备好了吗？泡好你的枸杞咖啡，跟随老司机的代码，一起揭开隐藏在图片像素背后的真相。

🕵️‍♂️ 引子

在一个雷雨交加的周五深夜，位于后厂村的“全栈侦探事务所”依然灯火通明。传说中，这里有一位代号为“老司机”的资深工程师，他不仅能用汇编语言写情书，还能在没有任何文档的遗留代码（Legacy Code）中自由穿梭。

就在刚刚，事务所的大门被撞开了。实习生阿强跌跌撞撞地跑进来，手里挥舞着一张模糊不清的截图，脸上写满了被产品经理折磨后的绝望。“老大！出大事了！这图片里藏着服务器的 Root 密码，但我手抄了三次都提示错误！现在上线倒计时只剩 30 分钟了！”

老司机缓缓放下手中早已凉透的黑咖啡，推了推鼻梁上那副防蓝光眼镜，嘴角勾起一抹神秘的微笑。“阿强，把你的‘人肉 OCR’停一停吧。在 Apple 的地盘上，我们有更优雅的武器——Vision 框架。”

在本次探案之旅中，您将学到如下内容：

• 🕵️‍♂️ 引子
• 🤖 第一章：不仅是扫码工具人的 Vision
• 🛠️ 第二章：打造“文字捕手” (The Text Recognizer)
• ⚠️ 老司机的技术批注：
• 🎯 第三章：给真相画个圈 (Highlighting Found Text)
• 🤝 终章：真相大白

他指尖在机械键盘上飞舞，屏幕上开始跳动起绿色的代码符文。“坐好，今晚带你见识一下，如何用机器学习的‘天眼’，让图片里的文字自己‘招供’。”

---

🤖 第一章：不仅是扫码工具人的 Vision

听好了，阿强。大多数人对 Apple Vision 框架的印象，还停留在扫个二维码或者条形码这种“小儿科”的阶段。这就好比你拿着一把激光剑去切西瓜——简直是暴殄天物！

实际上，Vision 就像是给你的 App 装上了一双“写轮眼”。它不仅能从图片中识别并定位文字（Text Detection），还能把图片里的特定区域剥离出来、在连续的视频帧里追踪物体、甚至检测你那僵硬的手势和坐姿！

我第一次跟 Vision 打交道的时候，是写了一个 Swift 命令行工具来移除图片背景 ✂️。那时候我就意识到，这玩意儿简直是修图师的噩梦，程序员的福音。但今天，我们要用它来做点更硬核的——文字识别。

---

🛠️ 第二章：打造“文字捕手” (The Text Recognizer)

要在茫茫像素中提取文字，我们得先组装一个名为 TextRecognizer 的“审讯室”。在这个环节，我们要用到 Vision 的核心组件：RecognizeTextRequest。

这就好比我们向系统提交一份“搜查令”，告诉它：“嘿，帮我把这张图里的字儿都给我找出来，而且要准（Accurate）！”

来看看这段代码，这可是我们的核心武器：

import Foundation
import SwiftUI
import Vision
 
struct TextRecognizer {
    var recognizedText = ""
    // 保存识别到的所有“线索”（观察结果）
    var observations: [RecognizedTextObservation] = []
 
    // 这个初始化器是异步的，因为查案需要时间，急不得
    init(imageResource: ImageResource) async {
        // 1. 创建搜查令：RecognizeTextRequest
        var request = RecognizeTextRequest()
        // 2. 将识别精度设置为 .accurate（我们要的是精准打击，不是瞎猜）
        request.recognitionLevel = .accurate
        
        // 3. 将 ImageResource 转换为 UIImage
        let image = UIImage(resource: imageResource)
        
        // 4. 重点来了！Vision 不吃 UIImage 这一套，它只认二进制数据 Data
        // 所以我们必须把图片“粉碎”成 PNG 数据
        if let imageData = image.pngData(),
           // 执行搜查任务（perform）。这一步可能会失败，所以用了 try? 来“掩耳盗铃”
           // 注意：这里是异步等待结果
           let results = try? await request.perform(on: imageData) {
            
            // 5. 将抓获的嫌疑人（观察结果）关进 observations 数组
            observations = results
        }
 
        // 6. 审讯环节：遍历每一个观察结果
        for observation in observations {
            // 获取可能性最高的那个“候选词”（topCandidates(1)）
            // 就像指认现场，我们通常只信最像的那个
            let candidate = observation.topCandidates(1)
            if let observedText = candidate.first?.string {
                // 把招供的文字拼接到结果字符串里
                recognizedText += "\n\(observedText) "
            }
        }
    }
}

⚠️ 老司机的技术批注：

这里有个坑你要注意，阿强。RecognizeTextRequest 是个挑剔的家伙，它不能直接处理 Swift 的 Image 或 UIImage 对象，它需要生肉——也就是 Image Data。

所以我们必须先把图片转成 Data 格式。另外，整个过程是 async（异步）的，毕竟机器学习这玩意儿虽然快，但也没快到能超越光速，我们得给 CPU 一点“思考”的时间。

接下来，我们把这个“文字捕手”集成到 SwiftUI 的视图里，让你亲眼看看效果：

import SwiftUI
 
struct TextRecognitionView: View {
    let imageResource: ImageResource
    // 状态变量，一旦侦探有了结果，界面就会刷新
    @State private var textRecognizer: TextRecognizer?
 
    var body: some View {
        List {
            // 展示嫌疑图片
            Section {
                Image(imageResource)
                    .resizable()
                    .aspectRatio(contentMode: .fill)
                    .clipShape(RoundedRectangle(cornerRadius: 8))
            }
            .listRowBackground(Color.clear)
 
            // 展示审讯结果（识别出的文字）
            Section {
                // 如果 textRecognizer 还没初始化好，就先显示空字符串
                Text(textRecognizer?.recognizedText ?? "")
            } header: {
                Text("从图片中提取的证词")
            }
        }
        .navigationTitle("文字侦探")
        .task {
            // 重点：在 .task 修饰符里调用异步初始化器
            // 就像在后台偷偷干活，不阻塞主线程 UI 的渲染
            textRecognizer = await TextRecognizer(imageResource: imageResource)
        }
    }
}

这时候，阿强凑过来看着模拟器屏幕，只见原本模糊的截图下方，整整齐齐地列出了识别出来的文字。“卧槽，神了！连那个像‘1’又像‘l’的字符都分清了！”

---

🎯 第三章：给真相画个圈 (Highlighting Found Text)

“别急着庆祝，阿强。”我敲了敲桌子，“光把字认出来还不够，我们要做到按图索骥。既然 Vision 已经告诉了我们文字在哪里，我们就得在图片上把它们圈出来，就像犯罪现场的粉笔线一样。”

这里涉及到一个让很多新手头秃的概念：坐标系转换。

Vision 返回的坐标是归一化的（Normalized），也就是说，它的 x 和 y 都在 0.0 到 1.0 之间。左下角是 (0,0)，右上角是 (1,1)。但我们的屏幕图片是按像素画的，而且 UIKit/SwiftUI 的坐标原点通常在左上角。这就好比火星人给地球人指路，如果不好好翻译一下坐标，你画的框可能会飞到姥姥家去。

我们需要定义一个 Shape，专门用来画框：

import Foundation
import SwiftUI
import Vision
 
struct BoundsRect: Shape {
    // 这里存的是 Vision 给我们的“火星坐标”（归一化矩形）
    let normalizedRect: NormalizedRect
 
    func path(in rect: CGRect) -> Path {
        // 关键时刻！将归一化坐标转换为图片的实际像素坐标
        // origin: .upperLeft 是为了适配 SwiftUI 的坐标系习惯
        let imageCoordinatesRect = normalizedRect
            .toImageCoordinates(rect.size, origin: .upperLeft)
        return Path(imageCoordinatesRect)
    }
}

---

🔍 技术扩展： toImageCoordinates 这个方法虽然原文没细说，但它大概率是一个扩展方法（Extension），用于把 0~1 的小数映射到图片的 width 和 height 上，并处理坐标原点的翻转。这一步至关重要，不做这一步，你的框框就会像没头苍蝇一样乱撞。

---

现在，我们把这个“现形符”贴到图片上：

struct TextRecognitionView: View {
    // ... 前面的代码 ...
    
    // 定义一个深红色的框，充满了悬疑感
    let boundingColor = Color(red: 0.31, green: 0.11, blue: 0.11)
 
    var body: some View {
        List {
            Section {
                Image(imageResource)
                    .resizable()
                    .aspectRatio(contentMode: .fill)
                    .clipShape(RoundedRectangle(cornerRadius: 8))
                    .overlay {
                        // 如果侦探已经有了观察结果
                        if let observations = textRecognizer?.observations {
                            ForEach(observations, id: \.uuid) { observation in
                                // 遍历每一个观察点，画个圈圈诅咒...啊不，标记它
                                // observation.boundingBox 就是那个归一化的坐标
                                BoundsRect(normalizedRect: observation.boundingBox)
                                    .stroke(boundingColor, lineWidth: 3) // 描边
                            }
                        }
                    }
            }
            // ... 后面的代码 ...
        }
    }
}

随着代码重新编译运行，屏幕上的截图发生了变化。每一个单词周围都被套上了一个暗红色的方框，就像是被狙击手锁定的目标。

---

🤝 终章：真相大白

“看到了吗？”我指着屏幕上被红框圈出的一串字符，“那根本不是 Root 密码。”

阿强瞪大了眼睛，盯着那行被 Vision 精准识别出的文字：WIFI_PASSWORD: 12345678。

“这……这就是隔壁会议室的 WiFi 密码？”阿强瘫软在椅子上，“我为了这个通宵了两天？”

我拍了拍他的肩膀，语重心长地说道：“虽然你是个笨蛋，但好在 Vision 框架足够聪明。记住，Vision 不仅仅能找字，它还能做更多事情——从视频里追踪隔壁老王的身影，到检测你是不是在偷偷抠脚（Body Pose Detection）。今天我们学的只是冰山一角，但也足够你在这个充满像素迷雾的开发世界里防身了。”

就这样，Vision 框架再次拯救了一个无知的灵魂（虽然并没有拯救他的加班费）。

希望宝子们喜欢这个故事，以及它背后的技术，但对于小伙伴们来说，利用 Apple 强大的 ML 能力去探索未知的旅程，才刚刚开始。

保持好奇，保持代码整洁，我们下个案子见。👋🙂 8-)

2026 年 3 月 31 日，距离苹果 50 周年纪念日还剩一天。国行 iPhone 用户的设置页面里，悄悄多了一个选项：「Apple 智能与 Siri」。

没有发布会，没有新闻稿，甚至没有一条来自官方社交媒体的预告。Apple Intelligence 就这样以一种几乎静默的姿态，落在了中国用户的手机上。

从 2024 年 6 月 WWDC 的高调亮相算起，国行用户为这一刻等了整整 21 个月。

爱范儿在第一时间完成了激活和全面实测，先说结论：

体验很「苹果」，但效果很一般。但

如果你期待的是一个能跟 Gemini 或豆包正面交锋的 AI 系统，这不是你想要的。

值得注意的是，这次苹果国行 AI 突然上线可能是一次意外，并非正式发布，目前苹果已经下线这个版本。

一向以苹果爆料闻名的彭博社记者 Mark Guman ，称国行 AI 还没拿到监管批准，他给出了以下理由：

• 苹果国行 AI 上线，官方不可能没有任何宣传动作。
• 苹果不会在中国凌晨发布国行 AI 。
• 它会调用 Google 作为视觉识别引擎，这在中国本就不合理

另据爱范儿最新了解，本次推送是由于软件问题，国行的 iPhone 和 iPad 设备曾短暂地可以下载其他地区适用的设备端 Apple 智能并启用该功能。

在问题出现后，苹果已迅速修复。

据悉， Apple 智能尚未在国行推出，推出时间依监管部门审批情况而定。

国行苹果 AI 怎么激活？

首先，你需要把设备更新 iOS 26.4 系统，然后进入「设置」，会发现原来的「Siri」入口已更名为「Apple 智能与 Siri」。

点击进入，再点亮 Apple 智能的开关，系统开始下载端侧模型。

整个过程需要连接 Wi-Fi，下载时间取决于网络状况，我们实测大约花了十分钟左右。下载完成后，一系列新功能随即解锁。

机型方面有硬性要求：iPhone 15 Pro 及后续机型才能运行 Apple 智能，更早的 iPhone 15 标准版因芯片和内存限制被排除在外。

需要留意的是，部分功能在首批推送中存在激活失败的情况。我们在实测过程中遇到了个别功能无法正常开启的状况，重启后恢复正常，但倒也并不意外。

新功能实测：速度很快，体验一般

打开新的 Siri，最直观的变化是视觉层面，屏幕边缘泛起的柔光替代了过去那个悬浮在底部的圆形动画，整个交互节奏明显更流畅。

Siri 现在同时支持语音和文字输入，这意味着你在会议室或者安静的公共场合也能通过打字跟它交流，不用担心开口说话的尴尬。

语义理解能力有所提升，能处理一些上下文连贯的对话。但在我们的实测中，Siri 的深度对话能力距离 ChatGPT 或者豆包仍然有肉眼可见的差距。

值得注意的一点是大模型调用的问题。

国行版 Apple 智能调用的后端模型情况比较复杂。视觉识别 AI 方面，我们通过 iPhone 16 的「相机控制」按钮实测，调出的视觉识别引擎应该来自 Google。

而在 Siri 的对话和内容生成环节，爱范儿实测发现是有可能调出 GPT 的，网上也有调出百度文心大模型的。

这一点颇为微妙，因为此前业界普遍预期国行版只会接入百度和阿里的模型。具体的模型调用策略，苹果官方尚未给出明确说明，也许跟网络环境高度相关。

写作工具覆盖了系统级文本输入场景，包括备忘录、邮件、信息等原生 App。选中一段文字后，可以调用润色、改写、摘要等功能。

速度是写作工具最令人印象深刻的地方。

由于模型运行在本地，从点击到结果呈现几乎没有感知延迟。在备忘录里选中一段 200 字的草稿，点击「改为专业语气」，不到两秒就输出了完整结果。这种即时反馈对日常使用来说体验非常好。

但端侧模型的能力天花板也肉眼可见。

复杂长文本的摘要有时会遗漏关键信息，语气改写偶尔会产生不够地道的表达。跟调用线上大模型的写作工具相比，它胜在速度和隐私，输在精度和灵活度，在云端模型面前，苹果的 AI 写作工具就像小学生。

Apple 智能下载完成后，桌面会新增一个「图乐园」App。

它支持根据文字描述生成图片，提供素描、插画、动画三种风格。你可以输入描述，也可以直接用照片库中的人脸作为素材，生成带有本人特征的艺术风格图像。

生成速度很快，大约三到五秒就能出图，这得益于端侧扩散模型的优化，但手机会明显发热。

苹果显然没有把图乐园定位成一个专业创作工具，它更像是一个系统级的趣味配件，如果你真要玩 AI 修图，请出门左转选择豆包。

AI 消除是本次更新中最实用的功能。

在照片 App 中打开一张图片，选择消除工具，用手指涂抹需要去除的主体，系统会自动识别并完成消除和背景填充。 好消息是速度快到令人惊讶。

选中、涂抹、消除，整个过程不超过三秒，完全在本地完成。日常清理照片中的路人、电线杆、垃圾桶之类的干扰物，效率极高。

坏消息是，精度不够。

在我们的实测中，AI 消除能够快速识别并去除主体，但细节层面存在明显瑕疵。

放大图片后可以看到阴影残留、边缘模糊、填充纹理不连续等问题。

如果是消除一个背景简单的小物体，效果尚可；但面对复杂背景或者大面积消除，画面破绽一目了然。

跟 Gemini 或者豆包的消除功能相比，Apple 智能的 AI 消除有明显差距。但苹果选择把所有处理放在本地，换来的是隐私和速度，代价就是质量上的折让。

比较私人的照片资料，也许端侧模型用起来会更让人放心一些。

系统级翻译功能现在也被纳入 Apple 智能的体系。

支持实时对话翻译和文本翻译，在信息、Safari 等场景中可以直接调用。响应速度很快，可以提前下载好语言包，实测在 iPhone 或者 AirPods Pro 3 上都能激活。

但在翻译质量上，它跟 DeepL 或者 Google 翻译的差距仍然存在，特别是在长句、专业术语和语境判断上。翻译功能对于苹果来说更像是一个系统级的实用补充，而非要在翻译赛道上跟专业选手竞争。

整体来看，Apple 智能国行版的整体体验可以用两个词概括：快，安全。 快，是因为绝大多数功能运行的都是端侧模型。

文本润色、信息总结、AI 抠图、消除，所有操作的响应速度都非常流畅，没有云端调用常见的等待感。这种「想到即得到」的交互节奏确实是苹果的强项。

安全，则体现在数据处理全部在本地完成，不会上传至云端。

对于隐私敏感度日益提高的国内用户来说，这是一个不可忽视的加分项。你的照片、文字、对话记录不会离开你的设备，这一点苹果做到了。

但「快」和「安全」的另一面，是端侧处理的质量上限。

跟调用线上大模型的竞品相比，Apple 智能在消除精度、文本理解深度、图像生成质量等维度都存在可感知的差距。

苹果在隐私与性能之间做了一个明确的选择，而这个选择的代价，用户在每一次使用中都能体会到。

为什么苹果 AI 迟迟不来？

Apple Intelligence 首次亮相于 2024 年 6 月 10 日的 WWDC24。

那场发布会上，苹果做了一件前所未有的事情：把「AI」这两个字母放进了自己的核心叙事。

在此之前，苹果一直刻意回避这个缩写，更愿意用「机器学习」之类的说法来描述自己的技术能力。但 OpenAI 掀起的生成式 AI 浪潮改变了一切，苹果也不得不正面迎战。

Apple Intelligence 被描述为一个「个人智能系统」，核心架构是端侧约 30 亿参数的小模型加上云端通过 Private Cloud Compute 调用的大模型，底层跑在 Apple Silicon 上。

在那场发布会上，苹果跟 OpenAI 达成了 ChatGPT 集成协议，Siri 在遇到超出本地能力的问题时可以调用 GPT。

2024 年 10 月，Apple Intelligence 随 iOS 18.1 在美国率先上线，随后逐步扩展到英国、澳大利亚、加拿大等英语市场。12 月，更多英语地区获得支持。

2025 年 3 月 31 日，iOS 18.4 更新让 Apple Intelligence 支持了简体中文、日语、韩语等多种语言。

但国行迟迟不来。

苹果最初的计划是在 2025 年中将 Apple Intelligence 带到中国市场，可惜这个时间表几乎从一开始就注定要被推翻。

由于合规要求，无论是苹果自己的云端模型还是 OpenAI 的 ChatGPT 都无法直接在国内使用，这意味着苹果必须找到本地合作伙伴。 苹果先是接触了百度，尝试接入文心一言，但据报道在技术对接和模型表现上遇到了障碍。

随后，苹果转向阿里巴巴。2025 年 2 月，阿里巴巴集团董事局主席蔡崇信公开确认了双方的合作关系。

根据方案，阿里的通义千问将作为 Apple Intelligence 在国行设备上的模型底座，同时负责内容合规审查。阿里还会在苹果的端侧模型之上部署一个审查层，确保 AI 输出符合国内法规要求。

但随着 2025 年上半年，世界局势的急剧变化，以及 AI 行业的迅猛发展，苹果的国行 AI 也从「行货」变成了「期货」。 此后，国行版 Apple Intelligence 的上线日期经历了多次推迟。

最初锚定 2025 年中，推迟到 iOS 18.6（2025 年夏），再推迟到 iOS 26.1、iOS 26.2、iOS 26.4。

2025 年 11 月，彭博社记者马克·古尔曼在 Power On 专栏中直言，国行版落地「遥遥无期」。

他指出，除了监管问题之外，Apple Intelligence 本身的工程进展也不顺利，模型性能未达预期。

最新的消息是，苹果计划在 iOS 27 中开发 Siri 的第三方 AI 接口，同时与 Google Gemini 深度合作，双管齐下来提升苹果 AI 的使用体验——但这种把半条命交给合作伙伴的做法，也意味着苹果在这轮 AI 大模型的军备竞赛中已经输了。

苹果能做的，就是牢牢把住 AI 硬件的入口——数十亿级的苹果生态设备。

这也是为什么，国行 Apple 智能必须尽快推出的原因，苹果要赶在 WWDC26 之前，完成全球范围的布局，为 AI 时代的 App Store 扫清障碍。

2026 年 3 月 31 日。距离苹果成立 50 周年的 4 月 1 日恰好只剩最后一天。苹果在 3 月下旬刚刚宣布了创业 50 周年纪念活动，Tim Cook 发布公开信回顾公司 50 年的历程，全球多地 Apple Store 举办了特别活动，爱范儿也受邀参加了苹果在成都和上海的特别演出。

就在这个时间窗口里，Apple 智能悄悄降临国行设备。 苹果没有解释为什么选择这个时间点，也没有给出关于合作模型、审批进展的任何官方说明。但时间节点本身已经足够说明问题：

在迈入下一个 50 年的门槛上，苹果大概不希望自己最大的海外市场之一仍然被排斥在 AI 时代的门外。

从商业角度看，这也合理。中国市场的 iPhone 销量在过去两年持续承压，Tim Cook 本人多次在财报电话会上承认，Apple Intelligence 的缺席是国行 iPhone 竞争力下滑的原因之一。

与此同时，华为、小米、OPPO 等国产厂商早已在 AI 功能上全面铺开，部分品牌还陆续接入了 DeepSeek 和龙虾，体验差距越拉越大。

苹果需要这个功能落地，而且需要在 50 周年这个全球瞩目的节点上落地。

把 Apple 智能放回它该有的坐标系里来看：它不是一个要跟 ChatGPT 或 Gemini 争夺「最强 AI」头衔的产品，它是苹果把 AI 能力融进系统层的第一步。 端侧模型带来的速度和隐私优势是实实在在的。

对于普通用户来说，能在本地完成文本润色、照片消除、信息摘要这些日常操作，不需要把数据交给任何云端服务，这件事本身有价值。

但如果你已经习惯了豆包、Kimi、DeepSeek 这些国产 AI 产品的能力水准，Apple 智能目前的表现大概率会让你觉得「就这？」。

端侧模型的参数量级和推理精度决定了它的上限，苹果在隐私和性能之间做出了清晰的取舍，而你需要判断这个取舍，是否符合你自己的需求。

等了快两年，Apple 智能终于来了。它迟到得太久，以至于我们对它的期待已经从「改变游戏规则」降到了「先能用再说」，但它确实来了。

在苹果 50 岁生日的前一天。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

过去十年，苹果在 iPhone 影像上的投入有目共睹。

从「Shot on iPhone」全球广告企划，到发布会上越来越长的相机环节，再到每年的 Pro 机型都在传感器尺寸、计算摄影和视频规格上不断加码。

▲ 图｜WIRED

十九年来，苹果始终都在传递着这样的信息：对绝大多数人来说，他们只需要 iPhone 这一台相机。

但作为「绝大多数人的相机」，就必须能兼顾各种类型的需求才行。而 iPhone 始终有一个缺憾：iOS 的默认相机 app 一直偏向「傻瓜模式」——

对于早期 iPhone 来说，这种「傻瓜模式」可以很好地降低普通用户的心理门槛和使用难度，即使完全不懂摄影，拿着手机也能拍到不错的照片。

▲ iPhone 5 相机广告：Photos Every Day

但是随着 iPhone Pro 系列影像规格的逐年攀升，这种「傻瓜相机」的路径就显得格格不入了：

对于想要手动调整白平衡、对焦，或者需要参考斑马纹和直方图的用户来说，iOS 自带的相机应用无法提供足够的自由度，等于是白白浪费了 Pro 系列的硬件。

iOS 老牌第三方相机 app「Halide」填补的正是这个空缺。

这款由 Lux Optics 开发的相机应用，提供了 RAW 拍摄、手动对焦、直方图、色彩波形、焦峰提示等一整套专业控制，同时保持了极其克制、直觉化的交互设计。

▲ 图｜Apple Developer

根据应用分析机构 Appfigures 的数据，Halide Mark II 更是目前 App Store 中最受欢迎的付费相机应用。

况且 Halide Mark II 的定价为 59.99 美元买断，或 19.99 美元/年订阅——在免费应用占绝对主流的 App Store 中，这个价格本身就是品质的证明。

而 Halide 背后的母公司 Lux Optics Incorporated，同样有着一段不寻常的经历。

Lux 的故事始于 2016 年，起点是一条 Twitter 私信。

前 Twitter 工程师 Ben Sandofsky 与前苹果工程师 Sebastiaan de With 因为在社交媒体上聊摄影器材而结识，两个发烧友一拍即合，决定合伙做一款相机应用。

▲ Ben Sandofsky（左）和 Sebastiaan de With（右）｜Apple

Sandofsky 此前是 Twitter iOS 客户端的技术负责人，还担任过 HBO《硅谷》剧集的技术顾问。

de With 则参与过苹果 MobileMe、iCloud 和 Find My 的设计工作，也为 Sony、T-Mobile 和 Mozilla 做过设计。

用 de With 自己的话说，他们做的「不是单纯的 app」，而是「一整台相机」——他们希望把传统相机上拨动光圈环和快门拨盘的那种触觉快感，带到 iPhone 的玻璃屏幕上。

这种「有审美、有技术、有想法」的组合，最终让 Halide 成为了 App Store 生态中最具代表性的独立应用之一。

▲ 图｜iPhone in Canada

相应的，Apple 对 Lux 的支持力度也远超一般开发者。

Halid 数次获得「年度最佳 iPhone 应用」、App Store 设计大奖，也会常驻应用商城的编辑精选。苹果开发者网站上专门为 Halide 做过两篇深度开发者专访，将该产品作为 App Store 优质开发者的样板展示。

在苹果提供给全球监管机构的报告中，Lux 的应用成为了开发者在 App Store 获得蓬勃发展的代表案例。

▲ 图｜Apple Newsroom

相对应的，Lux 也始终忠于苹果生态，从未计划过任何 Android 应用。

正是由于这种「你侬我侬」的状态，当苹果去年找到 Lux 谈收购时，大多数业内人士的第一反应是：这太合理了。

iOS 26虽然对 iPhone 原生相机交互做了较大的调整，但仍然不够。人们期待着 iPhone 相机能够得到一次彻底的升级。而 Halide 团队在近十年里积累的手动控制交互经验、RAW 处理流水线，以及对 iPhone 相机硬件的深度理解，都是现成的财富。

▲ 图｜CNET

据外媒报道，年末的 iPhone 18 Pro 系列在部分高级功能上将接近专业相机的水平，苹果正在为此重新设计内置相机应用。

而收购 Lux Optics，再融合 Halide 到系统相机，就是计划的一部分。

但收购没有谈成。

从收购失败到创始人决裂

上周，3 月 20 日，Sandofsky 将一纸诉状提交至加州高等法院——被告，是他的联合创始人。

根据诉讼文件，苹果与 Lux 的收购谈判在去年 9 月终止。没谈成是因为公司正在开发的新产品推高了价格，让苹果无法忍受。

然而根据诉状，实际情况并非如此：苹果发现，根本不用花大价钱买走 Lux，只需要把 de With 招回苹果就够了。

▲ 图｜Medienstürmer

收购谈判结束后不久，Sandofsky 在调查 de With 的财务行为时发现：苹果已经开始尝试招募自己的联合创始人，而面试对接人刚好是之前苹果参与收购谈判的人员。

除了指控 de With「自愿被挖墙脚」之外，Sandofsky 还提出了严肃的财务指控：诉讼状闲时，de With 从 2022 年底开始，使用公司信用卡支付个人消费，累计超过 15 万美元。

其中包括用公司账户购买了一张近 7560 美元的机票（法兰克福-巴黎-圣保罗），de With 声称是为之后的商务旅行准备，但无法提供确认邮件。

▲ 图｜Peter Peerdeman

de With 还涉嫌用公司资金购买了自己和女友前往法属波利尼西亚的「产前假」机票，以及其他涉及住宿、服装和酒水等与 Lux 公司业务无关的消费。

自从和苹果的收购谈崩之后，Sandofsky 就开始感觉不对劲了，于是去年 10 月雇佣了调查人员进行财务审查。

11 月，他将 de With 带薪停职——然而就是在停职调查期间，de With 开始与苹果沟通入职事宜。

12 月，Sandofsky 主持的内部调查结束，Lux 解雇了 de With，并要求他立即归还所有公司财产，包括存有敏感数据的电脑，并提醒他有义务不得泄露内部信息。

而 Sebastiaan de With 似乎并没有接受这个结果。

今年 1 月 28 日，Sebastiaan de With 在 X 上官宣加入苹果设计团队。

然而诉状中提到，de With 加入苹果时带走了 Lux 的源代码和机密材料，包括前面提到的「未来产品开发」相关的信息。

Lux 于 2022 年获得的 Apple Design Award 奖杯，也被这位苹果老员工带走了。

▲ 图｜iMore

面对诉状，被告方律师在声明中全面否认了上述指控。

关于财务问题，备稿律师称这些费用「已记录在册、清晰可见，且在当时从未被质疑」，是对「在一家共同管理、缺少正式管控的小公司里的正常、已披露的业务活动的事后重新定性」。

更关键的是，律师称这场诉讼是 Sandofsky 对 de With 要求查阅公司财务记录的报复——

de With 曾就公司的「财务违规行为」向 Sandofsky 提出质疑并正式要求查账，但相关要求一直未被满足。

▲ 图｜Getty Images

关于 Halide 等等一系列 app 的知识产权，律师否认 de With「使用、转移或披露了任何 Lux 知识产权」，并称 de With 已将公司材料归还给 Lux。

一位律师直接表示：

（Sandofsky）试图将苹果（收购 Lux 这件事）拉入这场纠纷，目的是制造杠杆和吸引关注，而不是解决任何实际的不当行为。

被告律师在声明中强调：「此案不是一起欺诈案件，而是长期合作关系破裂，所导致的联合创始人纠纷」。

至少在纸面上，Sandofsky 的诉讼的确没有将苹果列为被告，也从未指控苹果在其中有任何不当行为。

开发者社区的复杂情绪

Sebastiaan de With 加入苹果的消息公布时，开发者社区的反应就已经相当复杂，而 Lux 内部诉讼的曝光让这些讨论多了一层新的含义。

de With 去年 6 月发表过一篇设计文章——「Physicality: The New Age of UI」，探讨 Apple 可能的设计语言走向。

当时的语境中，这是一位独立设计师对 iOS 与 Liquid Glass 平台未来的畅想；现在回头看，这篇文章多了一层耐人寻味的含义。

▲ 图｜Wallpaper 网站专访苹果设计团队时收到的 visionOS 设计稿细节

有人对 de With 的加入表示祝贺，认为他的设计才华可以给苹果注入新血液——尤其在人机界面主管 Alan Dye 去年底离职前往 Meta 之后。

但也有人感觉事情不对劲。比如，开发者 CM Harrington 就表示，他对 de With 加入苹果的忧虑在于，他只是一个人，而「公司其余的人也得在乎设计，才能让有品味和能力的人真正发挥作用」。

另一位评论者更直接：

我会因为一个人在（苹果）目前这种领导层状态依然选择去苹果工作而判断他。（de With）加入这个系统，是因为认同它，而不是因为感觉自己能改变它。

▲ 图｜AppleInsider

而在 Reddit 上，Sandofsky 也在 1 月 25 号当天出面，反复强调 Halide 不会受影响，说自己从 2019 年就全职投入 Lux。

当然，1 月 Sebastiaan de With 表示加入苹果时，还没有人知道两位联合创始人已经撕破脸了。当时大家都以为，一个创始人离开、另一个创始人坚守，直到诉状揭开了故事的背面，是一个长久以来存在，且在苹果生态里经常被提起的问题：

作为一个苹果开发者，如果某一天你的产品/功能，被苹果公司直接做成系统产品/功能，你又该何去何从？

2002 年，苹果在 Mac 内置工具 Sherlock 3（聚焦搜索的前身）中复制了第三方付费应用 Watson 的几乎所有核心功能，Watson 的市场空间被迅速蚕食，最终无奈离场。

这个产品名 Sherlock，也因此直接演化成了这种行为的代名词。

▲ WWDC 2002 乔布斯介绍 Sherlock 3｜YouTube @AppleVideoArchive

「被苹果 sherlock」的焦虑，一直在加深。最近的例子，是苹果在 macOS 26 中将剪贴板历史集成到聚焦搜索里，对 Raycast、Alfred、Paste 等第三方应用带来了不小的冲击。

▲ WWDC 2025｜Apple

更不用说 iPhone 上的通话录音、夜览、密码 app、Sidecar 等等……一个又一个曾经属于第三方应用的核心功能，陆陆续续被苹果吸纳进了系统，变成了免费功能。

但这一次 Lux 的遭遇，激进程度完全上了一个台阶：不折腾，直接把人招走。

无独有偶，苹果与医疗设备公司 Masimo 之间也曾有过一段类似的摩擦。

2015 年初代 Apple Watch 发布前夕，苹果曾与 Masimo 讨论在血氧传感技术领域进行合作。谈判破裂后，苹果大规模挖走了 Masimo 的员工，这些人随后参与了苹果健康监测技术的开发。

▲ 图｜AppleInsider

Masimo 就此提起了两项诉讼。2025 年 11 月，陪审团在其中一项专利侵权案中判决苹果需要赔偿 Masimo 6.34 亿美元，苹果正在就此事提起上诉。

NPR 在报道苹果的「Sherlock 行为」时，援引了 App Store 前高管 Philip Shoemaker 的说法：许多开发者不敢公开批评苹果，因为害怕被从 App Store 里下架。

没有现成的答案

尽管诸事不顺，Lux 并没有放弃自己的产品。正相反，公司还在继续优化 Halide 等产品——甚至其中部分设定，颇有对苹果的挑衅意味。

今年 1 月，Lux 发布了 Halide 第三代公开预览版，Sandofsky 表示他将继续全职运营 Lux，并与知名设计工作室 The Iconfactory 和调色师 Cullen Kelly 合作开发新版本。

▲ 图｜Lux

今年 2 月，在接受《Inc.》杂志采访时，Sandofsky 还阐述了一个颇具哲学意味的观点：

现在的 iPhone 照片过于「完美」，以至于变得平庸。

而新版 Halide 将会自带一个「Process Zero」功能，旨在绕过所有 iPhone 预设的相机算法（比如令人深恶痛绝的 Deep Fusion），让用户拍出「不那么完美但更有个性」的照片。

从今往后，Halide 这个产品，不想再给苹果的应用生态唱「样板戏」了。

正相反，它要举起反抗苹果的大旗了。

▲ 图｜Halide.cam

而在苹果那边，Sebastiaan de With 和苹果设计部门都在经历一轮深刻变革。人机交互设计副总裁 Alan Dye 离职，资深设计师 Stephen Lemay 接任。

同一时间，苹果还在继续推进从 Liquid Glass 到整个 UI 系统的视觉翻新。de With 的理念能在多大程度上影响这个进程，仍然是未知数。

▲ 图｜Wccftech

我们无法预判这场 Lux 创始人之间的纠纷，最终会以何种方式收场。毕竟双方各执一词，诉讼尚未进入审理阶段。但无论结果如何，它都触及到了 App Store 生态中最敏感的神经。

过去二十多年，苹果开发者社区会反复追问自己：「当苹果做了你的功能时，你该怎么办？」

现在，这个问题变成了：「当苹果直接来挖你的好友兼联合创始人时，你又该怎么办？」

没人有现成的答案。

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

✍️ 引言

在开发面向全球或特定复杂网络环境的 App（如 XXX、跨境电商、海外加速等）时，最大的痛点往往不是业务逻辑，而是服务端的生存能力。为了对抗域名污染 (DNS Poisoning) 、SNI 阻断 以及 证书审查，我们通常需要一套极其灵活的「备用链路」与「动态发现」机制。

本文将结合在 iOS/Swift 项目中的实际落地经验，深度剖析一套基于 DNS TXT 记录 派发动态入口域名、双向 mTLS 证书（p12）基码 以及 原生 TCP 直连 IP 的高可用架构，并详解其间的技术难点与避坑指南。

---

🛠 一、 核心架构设计

我们的目标是：哪怕主 Base 域名完全死锁，客户端只要能向公用 DNS 发一个查询，就能满血复活。

1. 数据如何藏在 DNS TXT 里？

由于一台域名的 A记录 只能存 IP，且极其容易被封锁，我们选择将配置加密后塞入 DNS 的 TXT 记录。 我们使用了多级子域名来承载不同的模块（由于 TXT 字符长度限制，需要分片）：

子域名 (Subdomain)	承载内容特征	安全措施
root.yourbase.com	加密后的后备 HTTPS 业务 API 域名列表	AES-128-ECB 加密 + Base64
1.yourbase.com	mTLS 客户端证书 P12 文件的 Base64 前半段	纯文本分片拼装
2.yourbase.com	mTLS 客户端证书 P12 文件的 Base64 后半段	纯文本分片拼装
ip.yourbase.com	绕过 SNI 审查的裸 TCP 直连 IP 点对点通道	纯文本

---

🧠 二、 技术难点与避坑指南

难点 1：iOS 系统 API 无法直接发起原生 UDP DNS 查询

🚨 问题背景：  iOS 的 getaddrinfo 或者 NWHostResolver 是高层级 API，它们往往只返回处理好的 IP 地址（A/AAAA 记录），极难直接读取到 TXT、SRV 记录。如果调用系统的 res_nquery（属于 C 层的 libresolv），在弱网下容易造成线程死锁，且容易触发 iOS 严格的后台审计。

💡 解决方案：使用 Network 框架手工构建 UDP 53 端口查询 我们在 Swift 中封装了一个 DNSResolver，通过 NWConnection(to: 53, using: .udp) 手工下发标准 DNS 报文（RFC 1035） 。

1. 构造 DNS 查询帧：

   swift
   var data = Data()
   let id = UInt16.random(in: 1...65535)
   data.append(contentsOf: id.bigEndianBytes)
   data.append(contentsOf: UInt16(0x0100).bigEndianBytes) // Flags: 标准查询
   data.append(contentsOf: UInt16(1).bigEndianBytes)      // Question 数量 1
   // ... 拼接子域名 QNAME、QTYPE 为 16 (TXT)
   

2. 并发查询优化： 由于国内 DNS 偶尔会有运营商后门或缓存污染，我们使用 withTaskGroup 并发地向四个公共 DNS 服务器发送请求 (223.5.5.5, 114.114.114.114, 8.8.8.8, 1.1.1.1)，谁最快返回合法的 TXT 内容，就直接 cancelAll() 结束任务。

---

难点 2：UDP 的截断陷阱 (Truncated) 与 TCP 回退

🚨 问题背景：  由于拼装了庞大的客户端 p12 证书 Base64 字符串，TXT 记录往往会合在一起超过 512 字节。 在标准的 DNS UDP 查询中，如果响应超过 512 字节，包头部的 TC (Truncated) 标志位会被置为 1，代表数据被截断。

💡 解决方案：标志位侦测与 TCP Fallback 我们在 UDP 接收处做了一层守卫：

swift
if (data[2] & 0x02) != 0 {  // TC Flag is set!
    // UDP 遭遇截断，降级使用 TCP 53 端口进行可靠全量查询
    return await queryTCP(domain: domain, server: server)
}

进入 queryTCP 时，会在帧最前面补上 2 字节的大端序长度头，直接利用 NWConnection.tcp 握手拿到绝对完整的几千字节 TXT 加密串，完美解决大文件丢失问题。

---

难点 3：防劫持的 “端到端解密” 校验

🚨 问题背景：  如果中间人（Mitm）故意把你的 TXT 记录篡改成钓鱼网站或错误信息，即便配置下发了，APP 也会崩溃或中招。

💡 解决方案：AES + TCP 握手活性测试

1. 对称加密：对 root 的分流域名进行 AES-128-ECB 加密。中间人即使拿到了，没有客户端的硬编码 Key 也无法篡改。

2. TCP 通信握手探测活性： 在真正切换配置前，Manager 会多跑一遍 tcpTest。由于有些域名可能已经“挂了”，客户端会在后台静默并发跑：

   swift
   let connection = NWConnection(to: host, using: .tcp)
   connection.stateUpdateHandler = { state in
       if state == .ready { finish(true) } // 代表服务器可通达，不是死域名
   }
   

---

难点 4：动态 mTLS 证书灌入 (Security Manager)

经过 AES 解密和两片 TXT (1.txt + 2.txt) 拼装后，我们得到了完整的证书 Base64 编码。 我们要实实现本地无感知实例化，不需要把证书文件落地写死到沙盒里（防止反编译静态检查）：

1. 直接在内存中将组合好的 Base64 数据转为 Data。
2. 使用 SecPKCS12Import 函数，并将空密码（或者约定的暗号）传入，从内存里动态吐出 SecIdentity 和关联的 SecCertificate。
3. 把 Identity 灌入全局 SessionDelegate。当走 HTTPS 握手时，若触发 .clientCertificate 的 URLAuthenticationChallenge，直接从 cache 提取该 Identity 给系统使用。

---

难点 5：SNI 阻断应急方案 —— 18字节头部纯裸 TCP 定制通道

对于国内在极限阻断（如 SNI 嗅探）下的特殊业务，HTTPS 甚至会被阻断。我们追加了 ip.yourbase.com 提取裸 IP：

• 业务无感降级：当 HTTPS 全灭，NetworkChannelManager 自动引导流量降级到我们自己用原生 NWConnection 敲出来的裸 TCP 直连。
• 自定义封包协议：由于对端没有 TLS 证书做阻断，我们在应用层通过自研非对称二进制报头（[18字节头部][Path][Hdr][Body] 及 响应 14字节头部）在服务端和客户端穿梭自如，极大增强了业务的可达率骨干。

---

📈 三、 业务安全成效

通过这套机制的上线，我们成功做到了：

1. 云端无感知脱壳切换：后台可随意增减高防域名、甚至随时全量更替 TLS 的客户端校验私钥，对老版本客户端保持完美兼容。
2. 零阻断时长：冷启动到成功跑通业务 HTTPS 的时间通过 TaskGroup 的竞赛机制下降到了 平均 0.3 秒以内。

💡 总结

服务高防链路的最佳伴侣不是冗余服务器，而是灵活、弹性的 发现机制。 利用 DNS 53 这个处于网络信任基座的协议，将 分片、加密数据 优雅地回传至 iOS 客户端并发解码，不仅安全可靠，更筑起了一道无法轻易折断的强硬长廊。

---

提示：  在使用 114 / 223 等大陆 DNS 查询时，注意频率控制以心跳避免被运营商拉入恶意解析黑名单。对于更深层的防污染，甚至可搭配 DNS over HTTPS (DoH) 来取代 53 端口查询。

升级到 NativeScript 8.7 后出现 APPLE is not defined 错误

出现了__APPLE__ is not defined 错误，是在你将 @nativescript/core, @nativescript/ios, @nativescript/android 升级到 ^8.7.0 版本后可能遇到的一个烦人错误。

官方推荐所有人都升级到 NativeScript 8.7，因为它包含了许多错误修复和改进，例如 devtool 以及恢复了从 8.4 版本开始中断的网络检查功能。然而有些人可能会遇到像下面这样的奇怪错误：

System.err: ReferenceError: __APPLE__ is not defined
System.err:
System.err: StackTrace:
System.err: ./node_modules/@nativescript/core/accessibility/font-scale-common.js(file: src/webpack:/FarmOps/node_modules/@nativescript/core/accessibility/font-scale-common.js:1:7)

原因

__APPLE__ is not defined 错误是由于 NativeScript 在他们的构建代码中引入了一些新的占位符。这些占位符依赖 Webpack 在构建时进行替换。而这个逻辑是在 @nativescript/webpack 5.0.19 中引入的。所以关键是确保你使用的 @nativescript/webpack 至少是 5.0.19 版本，才能成功使用 NativeScript 8.7 构建你的项目。

解决方案

所以基本上，解决 __APPLE__ is not defined 错误的方法是确保两件事：

1. 首先，确保 @nativescript/webpack 的版本在你的 package.json 中没有被限制，像这样是最好的：^5.0.0
2. 其次，确保你的 npm 已经知晓了 @nativescript/webpack 的最新可用版本，并且没有任何缓存。对我而言，我会执行 rm -rf node_modules，rm package-lock.json 然后再重新运行 npm i 来确保。或者更简单地，执行 ns clean 然后重新运行。

你总是可以尝试查看 package-lock.json找到 @nativescript/webpack 部分。如果它看起来像这样：

这表明实际安装的版本是 5.0.18，这是不行的。需要用我上面提到的任一种方法来解决。

在确保 @nativescript/webpack 版本没问题后，你现在可以再次运行 ns run 来继续你的 NativeScript 开发工作。

附言：如果你正在经历常见的 NativeScript 问题，并且需要一些快速修复或解决方法，请务必查看我们的“快速修复”部分。在这一部分，你会发现我在 NativeScript 之旅中收集的技巧和窍门，以及解决常见问题的解决方法。希望能帮助到许多像我一样的人。

NativeScript iOS: 无法启动模拟器

作为一名 iOS 开发者，最令人沮丧的事情莫过于 iOS 模拟器突然停止工作。这个工具对于在受控环境中测试和调试你的应用程序至关重要。当它失效时，你的工作流就会戛然而止，打乱工作效率并造成不必要的压力。

问题：无法启动模拟器

模拟器就是不工作，拒绝启动。并且一直说“无法启动模拟器”。

解决方案：

这个修复方法非常简单。

对于 Mac Ventura 13.0 及更高版本的操作系统 -> 点击 Mac 左上角的苹果图标 > 系统设置 > 搜索存储空间 > 等待加载，然后点击开发者 (Developer)。

在下一个屏幕中，选择删除 Xcode 缓存 (deleting Xcode Caches)。

删除完成后。尝试重新启动你的模拟器，现在它应该又能正常工作了。

如何正确修复：Info.plist 键 'BGTaskSchedulerPermittedIdentifiers' 必须包含一个标识符列表

对于一个 NativeScript 应用，这个错误通常出现在 iOS 应用开发的上下文中，具体来说，当你或你安装的某些插件试图使用后台任务时，就会出现这个问题。

解决方法

1. 打开你的应用的 App_Resources/iOS/Info.plist 文件。
2. 如果尚不存在，添加键 BGTaskSchedulerPermittedIdentifiers。
3. 将其类型设置为 Array（数组）。
4. 对于每个后台任务，在此数组中添加一项。每一项都应该是一个字符串，代表一个后台任务的唯一标识符。

使用示例：

<key>BGTaskSchedulerPermittedIdentifiers</key>
<array>
<string>$(PRODUCT_BUNDLE_IDENTIFIER)</string>
</array>

如果你有任何自定义的后台任务，你也需要将其 ID 列入上面的数组中。除此之外，你可以直接使用上面这段代码。

$(PRODUCT_BUNDLE_IDENTIFIER) 将被解析为你在 nativescript.config.ts 中定义的应用 Bundle ID，例如：com.newbiescripter.myawesomeapp

请记住，在 iOS 中使用后台任务有一些限制和准则，因为苹果旨在优化电池续航和性能。请确保你使用后台任务的方式符合这些准则。

• newbiescripter.com/nativescrip…
• newbiescripter.com/how-to-prop…
• newbiescripter.com/__apple__-i…

今天，苹果为中国大陆的 Apple Watch 带来了一个全新功能：移动脉率房颤迹象记录软件功能。

想要打开「房颤迹象」功能的用户，不需要更新到最新的 iOS 或 watchOS 系统，功能后续会逐步开放。

开启路径如下：打开 iPhone 上面的健康 App，点击底栏「搜索」的放大镜图标（iOS 26）或「浏览」图标（iOS 18 及之前版本），然后在「健康类别」中选择「心脏」一栏，往底下拉就能看到「房颤历史」。

看到这里，你是不是已经准备按照步骤操作开启了？且慢！这个功能没那么简单，屏幕前的你，大概率用不上。

所以，房颤迹象记录究竟是什么？又为谁而来？借着新功能上线之际，爱范儿和苹果健康团队的科学家 Asha Chesnutt 聊了聊。

Asha Chesnutt 博士是一名美国内科医学委员会资格认证的医师，曾经在俄勒冈诊所工作，现任苹果的临床专科医生。

隐形杀手：房颤

在聊新功能之前，先要弄清一个问题：什么是房颤，为什么需要记录它？

我们每个人的心脏中都有一个天然「起搏器」，名为「窦房结」，它会定期发出电信号告知心脏跳动。

当心房出现异常电信号，导致心房与心室的节律失去同步，产生高频但无效的收缩，这就是「心房颤动」，属于最常见的一种心律失常。

正常人的心率一般在每分钟 60–100 次，而房颤患者的静息心率通常会升高到 100–120 次，极端情况下甚至可能达到 300 次。

Nature 的一篇文献显示，亚太地区 2023 年共有 8000 万房颤患者，中国是患病率最高的国家之一，有 3275 万患者，并且这个数字还会不断上升。为了提高房颤预防和认知，每年的 6 月 6 日，都是中国的「房颤日」。

虽然房颤通常被视作是一个「老龄病」，但匹兹堡心血管研究中心调查发现，65 岁以下房颤患者的案例数量占总数四分之一以上，在吸烟、肥胖、高血压、睡眠障碍、精神压力大这些因素影响下，房颤已经开始盯上了年轻人。

更棘手的是，房颤往往具有隐匿性。40% 的患者几乎没有明显症状，仍然可以正常生活；但在部分情况下，也可能出现心悸、疲劳、气短或心跳过快等表现。

真正的风险在于并发症。长期未被发现或治疗的房颤，可能增加血栓、心力衰竭等风险，其中中风的概率会提高约 4～5 倍。因此，及时发现并记录房颤迹象，对预防严重后果尤为关键。

有研究发现，即使为 65 岁以上人群进行常规心电图检查，也没有明显提升房颤的检出率。想要更准确地筛查房颤，往往仍需要依赖更专业的设备，甚至是植入式监测装置。

这也意味着，不少房颤患者在没有明显不适的情况下，难以主动就医，而常规体检也难以及时发现问题。房颤如果长期未被识别和干预，就可能在不知不觉中增加更严重并发症的风险。

首都医科大学附属北京安贞医院心律失常中心主任龙德勇教授认为，许多患者对房颤危害认识不足，除了加强普及和早期筛查，也应推广智能手表这样的可穿戴便携式心电监测设备。

移动心电图房颤提示，以及移动脉率房颤提示，这两个 Apple Watch 功能主要的功能就是「预警」，能够帮助用户识别房颤的心率不齐迹象，相关功能已经在 2021 年随着 watchOS 8.3 和 iOS 15.2 上线国行，在 iPhone 上「手表」App 的「心脏」页面中可以打开。

几乎全天被佩戴在身上的 Apple Watch，即使无法准确检测心脏病问题，也能及时检测到身体细微的病变，提醒用户去进行专业筛查，是对房颤「隐蔽性」的一种辅助解决方案。

但预警仅仅是针对未确诊的大众用户，经过专业医学检查后确诊房颤的患者，他们是一个同样需要帮助的群体。

记录房颤，很重要

这次上线的新功能，全称为「房颤迹象记录」，它不是一个「预警」，而是一个「记录」的功能。

Chesnutt 博士表示，「心率不齐通知」功能与这次更新的「房颤迹象」功能，两者是互斥的，两个只能打开一个。因此对于非患者用户来说，只需要打开房颤提示功能，帮助检测潜在的风险。

开启「房颤迹象记录」后，用户需要一周内至少佩戴 Apple Watch 5 天，每天佩戴时长不低于 12 小时，手表会综合多种参数，估算患者在一周的时间内，有多少比例的时间心脏是处于房颤的状态中，也就是所谓的「房颤负荷」，是针对「房颤」这一疾病的辅助工具。

当收集了足够的数据，Apple Watch 会在每周一显示每周的提示信息，提醒用户前一周出现房颤的时间百分比估算，将这个「隐形杀手」变为「有形记录」。

Chestnutt 博士告诉爱范儿，这个功能的诞生，也建立在苹果长时间以来对数字健康的洞察：

以往，佩戴 Apple Watch 的用户，当它们收到 IRN 的心率不齐的提示，经过专业诊断确诊后，Apple Watch 好像就失去了作用。而「房颤迹象记录」，就是着眼于确诊后继续跟踪和检测相关病情。

针对房颤这个慢性病，长期观测更是治疗的关键。

研究发现，房颤负荷与未来中风风险之间可能存在线性关系，两者之间存在剂量效应，房颤发病时长的累积会带来更高的卒中风险。

因此，医生需要结合患者的房颤负担情况，判断是否需要使用口服抗凝药来预防卒中。

由于房颤发作的症状比较隐蔽，单纯依赖「房颤是否复发」难以全面评估治疗效果，而量化的房颤负荷监测，能够作为心房颤动消融术和其他治疗方案的有效性参考依据。

但房颤是一个「阵发型」的疾病，可能一周只会发作一次，每次只有几分钟，症状也许会相当隐蔽，但患者不可能 24 小时都在医院接受专业的检测治疗，他们需要一个能随身长时间佩戴的检测仪器。

贴片式检测器虽然专业，但体型较大，使用起来也不方便；Apple Watch 不能当作诊断依据，好处在于可以长时间佩戴，并且不会让患者自我感觉像一个病人。

Apple Watch 记录的房颤负荷数据，可以以专业的 PDF 图表数据导出、分享。方便专业的医生参考，根据房颤的发作频率，设计治疗方案。

在专访过程中，Chestnutt 博士多次强调了 Apple Watch 在房颤迹象记录上的准确性。苹果的临床试验中，会将 Apple Watch 和美国食药监局推荐的检测仪器验证对比，两者数据相差不到 1%，这些试验报告都能被公开检索。

据爱范儿了解，在一些大型三甲医院中，包括 Apple Watch 在内的智能手表，已经成为了心血管医生推荐患者佩戴的工具，用来帮助患者进行预警和初筛。

至于 Apple Watch 的房颤迹象检测功能，Chesnutt 博士也认为它能在专业治疗中起到作用：

苹果的所有健康功能，核心作用都是为患者提供更充分的健康信息，让他们在就医时能和医生进行更有依据的沟通，而非替代诊断或医患互动。对于一些患者来说，他们每次就诊的时间很有限，因此为主治医师提供尽可能多的信息很重要。

在传统医疗体系中，房颤管理往往由医生主导，但这种疾病与患者的日常生活习惯密切相关，因此同样需要患者在日常生活中参与。

以往，医生只能建议患者写日志记录，复诊时描述症状，不仅受主观影响，而且也不够准确。要想进行症状的记录，就必须佩戴侵入式的检测仪。

这正是 Apple Watch 能发挥价值的地方。Chesnutt 博士指出，房颤发作和生活方式密切相关，而房颤迹象记录功能，除了收集心脏数据，还会结合用户的运动时长、睡眠、体重、酒精摄入量以及正念时长等信息，方便用户回溯，交叉对比房颤发作和哪些生活因素有关。

从异常心率检测，到房颤负荷，苹果围绕「房颤」这个隐形的杀手，打造了一个闭环的、可感的、量化的健康管理方案：Apple Watch 替用户发现风险，用户去医院体检，如果确诊了，还能继续记录数据，用于临床治疗参考。

从患者成为健康主理人

Apple Watch 房颤迹象的记录，不能代替完全的医疗诊断，更重要的意义在于，它「赋能」了患者，让他们进一步参与疾病管理。

国家药监局官网的公示中，Apple Watch 房颤迹象记录功能被注册为「第二类」医疗器械，与体温计、口罩这些公共卫生产品并列。

这类产品不能直接作为治疗处方和诊断依据，更大的意义，在于将普通人的「生病焦虑」，转化成了「确切的答案」。

除了症状带来的影响，心理上对病况的未知，同样会为患者带来焦虑。体温计的诞生，让普罗大众即时就能判断自己的身体状况，是否恶化好转，需不需要进一步治疗和就医，不用再去「猜」，确切的体温数字会帮你决策。

Apple Watch 扮演的就是这种角色，将症状更为隐蔽的房颤，以一种相对简单的方式，被进一步检测，并被量化成一个具体的数值，还能和其他身体数据进行交叉对比。

患者在这个过程中，也从相对被动的角色，转变为自身健康的管理者，而这种「掌控感」本身，就能为他们带来实实在在的心理助力。

不少人买 Apple Watch，是为了多一份「心安」：在风险来临之前被提醒，在异常出现之初被看见。那些从体征波动中捕捉到的细微信号，或许不能直接替代诊断，也能让人更早迈出回到健康的那一步。

但当我们把期待从「预警」推向「管理」，门槛也随之陡然升高，需要更高的准确性、更长期的数据积累，以及更贴近医疗体系的能力，这些都让智能穿戴一度止步于边缘。而真正需要这些能力的人，恰恰是那些无法被频繁、持续监测覆盖的患者。

变化正在发生，依托长期积累的海量健康数据，以及与医疗研究体系的协作，苹果正一点点把可穿戴设备推向更深的水域，「房颤迹象记录」就是其中一个成果。

Apple Watch 从来不为取代医生而来，它更聚焦于「患者」，或者说用户：你不再只是那个等待被诊断的人，可以更早一步，理解和掌控自己的身体健康。

文献参考：

Yang SY, Huang M, Wang AL, Ge G, Ma M, Zhi H, Wang LN. Atrial fibrillation burden and the risk of stroke: A systematic review and dose-response meta-analysis. World J Clin Cases. 2022 Jan 21;10(3):939-953. doi: 10.12998/wjcc.v10.i3.939. PMID: 35127908; PMCID: PMC8790433.

Wong, C.X., Tse, H.F., Choi, EK. et al. The burden of atrial fibrillation in the Asia–Pacific region. Nat Rev Cardiol 21, 841–843 (2024). https://doi.org/10.1038/s41569-024-01091-1

Uittenbogaart SB, Verbiest-van Gurp N, Lucassen WAM, Winkens B, Nielen M, Erkens PMG, Knottnerus JA, van Weert HCPM, Stoffers HEJH. Opportunistic screening versus usual care for detection of atrial fibrillation in primary care: cluster randomised controlled trial. BMJ. 2020 Sep 16;370:m3208. doi: 10.1136/bmj.m3208. PMID: 32938633; PMCID: PMC7492823.

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

一、苹果中国区抽成“紧急”下调

2026年3月12日，苹果突然宣布中国区AppStore官方抽成从 30% 改为 25%，小型开发者抽成从15% 改为 12%。2026年3月15日生效。来源

想必，今天大家都被这个截图刷屏了吧。

为什么说“紧急”呢？
1、“根据与中国监管部门的沟通”，写得很清楚，是中国监管部门推动的；
2、“自3月15日起”，约等于立刻生效，对比谷歌的三个月后生效，凸显一个“急”；
3、“调整无需开发者在此之前签署新条款”，手续流程都免了，直接生效！
2、“更新版协议的简体中文版将于一个月内在 Apple开发者网站上线”，流程后面再补，先上线！

不知道苹果发生了什么，但是感觉很爽。有种苹果被工信部发了违规整改通知的感觉（DDDD），让苹果也尝尝工信部的厉害，马上整改，立刻上线！哈哈哈。

中国开发者什么都不用做，代码都不用改，就额外增（bai）加（piao） 3%~5% 的收益。

感谢那些为此做出贡献的人！

补充：有律师说出了苹果紧急“降税”的真相 ，有兴趣的可以点开看看。

二、谷歌将陆续降低全球抽成并开放三方支付

苹果紧急降低抽成除了迫于监管压力，估计也迫于竞争对手的压力。

早在3月4日，谷歌在安卓开发者网站发布了一篇博客《选择和开放的新时代》，宣布将陆续在全球降低抽成，开放第三方支付，并且后续除了《小型开发者计划》外，还会新推出《应用体验计划》和《游戏升级计划》来让利开发者。

《应用体验计划》《游戏升级计划》的本质：质量换费率。通过经济激励（降低费率）来引导开发者提升应用和游戏的整体品质。开发者必须达到相应的技术集成和体验标准，来满足计划条件，才能获得费率减免。举例说明，比如，游戏类必须集成 Play Games Services 功能（如成就系统、现代玩家个人资料认证）。Play Console 中的“Android Vitals”指标，确保应用在崩溃率、ANR（无响应）率等方面符合谷歌的健康度标准。

计划的具体内容，谷歌尚未公布。

谷歌将现有的抽成拆成了两部分：
Google商店服务费：标准20%、参加上述新计划15%、小型开发者10%、订阅10%（取最小值）
Google支付服务费：约5%（每个地区可能不一样）

在美国、英国和欧洲经济区 (EEA)，支付服务费为 5%。其他地区的支付服务费详情谷歌后续公布。

商店服务费，只要你在谷歌商店上架就要交，不管你用谷歌支付还是三方支付；
支付服务费，用谷歌支付就要交，用三方支付不交。

谷歌最终抽成比例：
官方支付抽成：15%~25%
三方支付抽成：10%~20%

谷歌新政策全球上线后，官方支付和三方支付只差5%，三方支付还得加上3%左右的通道费，和官方支付相比，三方支付毫无竞争力，这也是为什么谷歌敢在全球开放三方支付的原因。

需要注意的是，这次费率变化并非即刻生效，而是将分时间、逐步在全球不同地区推广：

各区域的推出日期	地区	《应用体验计划》《游戏升级计划》上线地区
2026年6月30日	欧洲经济区、英国、美国
2026年9月30日	澳大利亚	澳大利亚、欧洲经济区、英国、美国
2026年12月31日	日本、韩国	日本、韩国
2027年9月30日	世界其他地区	世界其他地区

三、苹果、谷歌全球抽成比例汇总

目前，谷歌和苹果，在全球都面临着反垄断、三方支付、三方商店的压力，革命一旦发起，就像星星之火一样会传递到全世界，一会这个国家闹，一会那个国家闹。面对这样的情况，谷歌和苹果却走出了不一样的应对路数。

1、谷歌全球统一标准

谷歌，将在2026年到2027年陆续在全球执行统一的新标准，开放三方支付、开放三方商店。

Google商店服务费：标准20%、参加上述新计划15%、小型开发者10%、订阅10%（取最小值）
Google支付服务费：约5%（每个地区可能不一样）

官方支付抽成：15%~25%
三方支付抽成：10%~20%

全球实行时间线：

各区域的推出日期	地区	《应用体验计划》《游戏升级计划》上线地区
2026年6月30日	欧洲经济区、英国、美国
2026年9月30日	澳大利亚	澳大利亚、欧洲经济区、英国、美国
2026年12月31日	日本、韩国	日本、韩国
2027年9月30日	世界其他地区	世界其他地区

2、苹果按闹施政

从目前来看，苹果是按闹施政，谁闹我就便宜点，不闹就维持原样。但感觉不是长久之计，说不定苹果后续也会像谷歌那样统一标准。目前情况来看，谷歌还是眼光更长远一些，走在了前面，胸襟更大。

以下是苹果当前（2026.3.13）全球费率情况

地区	官方内购参考佣金	三方支付苹果抽成	备注
欧盟	13% - 20%，官方文档	15%~20%	欧盟计费很复杂，还会按安装量抽成
日本	15% - 26%，官方文档	10%~15%，外部链接购买 10%~21%，应第三方购买
韩国	15% ~ 30%	11% ~ 26%
美国	15% - 30%	0%，外部链接购买	海外公司可以申请；必须同时提供内购作为备选；仍然向苹果上报收入用于审计
中国	12% ~ 25%，官方文档	不允许三方支付
其它	15% ~ 30%	不允许三方支付

和谷歌一样，苹果也把抽成拆了商店服务费+支付服务费，从上表可以看到三方支付和官方支付比也没有优势。

美国外链支付比较特殊，可以做到0%费率，但同样要满足三方支付的苛刻条件：必须接入官方内购作为备选、有苹果警告弹窗、仍然需要上报三方收入给苹果审计。

如果你对三方支付感兴趣可以看看我往期文档《三方支付真的香吗？日本iOS、Google三方支付调研报告 》，这篇虽然讲得是日本，但三方支付的接入流程和要求，全球都是一样的。

前阵子，我无意中发现我们的应用在 App Store 上悄然出现了几条差评，但团队里似乎没人注意到。这让我意识到一个严重的问题：如果我们不能及时听到用户的声音，怎么能及时发现应用的不足，留住用户呢？ 更令人担忧的是，潜在用户在下载前往往会浏览评论区，一条未被回应的负面评价，可能就足以让他们转身离开，影响新增转化。

如果能在用户留下评论（尤其是差评）的第一时间收到通知，我们就能快速响应、修复问题、安抚情绪，甚至将一次不满转化为一次忠诚度的提升。更重要的是，积极、真诚地回复用户评论，不仅能展现团队的专业与负责，还能向所有观望者传递一个信号：我们在乎每一位用户。

本篇文章将从实操角度出发，为不熟悉苹果和谷歌开发者后台的开发或运营同学，讲解如何监控苹果谷歌商店的评分评论，以及如何回复用户评论，为大家提供一些帮助。

一、苹果

苹果开发者后台 appstoreconnect.apple.com/，需要 客户支持 权限。

1、如何监控评分和评论

苹果后台目前不支持收到新的评分评论后邮件通知开发者。只支持“开发者回复”（当顾客编辑你已回复的评论时，你将收到电子邮件），如需开启“开发者回复”邮件通知，按下面步骤操作：

登录 App Store Connect。
点击右上角的用户头像，进入 “用户和访问”。
选择你的账户，在左侧菜单点击 “通知”。

Tips：“收到评分评论后邮件通知开发者”，这个功能在旧版 iTunes Connect 中曾经存在，但在新版 App Store Connect 中已被移除。猜测苹果可能不想开发者过度关注单条评分评论。

如果目前想要监控苹果商店的评分评论，有几个方案可参考：
1、使用官方的 App Store Connect App，每天刷一刷，自己主动去看。App内可以设置“接收用户评分”通知，但不确定现在还是否有效。
2、苹果官方提供了App Store Connect API，可以自己开发程序拉取用户评分，再进一步做监控。
3、滴答清单定个周期性提醒，每天上班打开商店详情瞅一眼，现在苹果上线了Web版AppStore了，瞅一眼也很方便。
4、借助第三方平台。

2、查看和回复用户评论

（1）通过网页端查看

登录苹果开发者后台，appstoreconnect.apple.com/

评分评论入口：分发 - 评分和评论

点击“回复”可以回复用户评论

（2）通过官方App "App Store Connect" 查看

iOS端下载地址：apps.apple.com/cn/app/app-…
（如果你搜不到可能是你手机系统版本太低了。没有安卓端。）

App Store Connect App核心功能：
-- 销售与趋势监控（查看 App 的下载量、销售额）
-- 版本状态管理（跟踪审核状态，回复审核）
-- 用户评论处理（查看和回复评论）

App Store Connect内查看评分及评论入口：

3、重置总评分

发布新版本到 App Store 时（必须更包），你可以重置 App 总评分。重置后，你的 App Store 产品页面将显示说明，提示顾客 App 的总评分最近已重置。此说明将一直显示，直到有足够多的顾客对新版本进行了评分且页面出现新的总评分。

请注意，重置总评分并不会重置顾客评论，App Store 仍将继续显示历史的顾客评论。

二、Google

Google开发者后台 play.google.com/console/dev…，需要 用户反馈 权限。

1、如何监控评分和评论

Google官方支持收到新的评论后邮件提醒开发者，并支持按应用、评分星级设置不同的提醒开关。注意：邮件提醒默认是关闭的，需要手动开启。请按下列步骤操作。

Google开发者后台 - 设置 - 个人邮件通知（这个只会改你个人的通知设置，不会改整个团队的）

按需将邮件提醒开关打开，修改后记得保存。

如果你的账号拥有开发者账号下多个App的权限，默认是所有应用都给你发邮件，点击下图位置，可以选择哪些应用接收邮件。

收到新的评论后，Google会给你推邮件，模板样式如下，包含了应用名称、评分星级、评论内容，不用打开Google后台就能看到评论内容，很方便。
注意：如果你接收了多个应用的邮件，请留意邮件标题里App的名字。

2、查看和回复用户评论

（1）网页端

Google后台 - 应用 - 监控与改进 - 评分与评价。

Google后台的评论，Google会默认帮你翻译成你的语言，很贴心。如果你想看原始评论，点击“显示原评论”查看。你也可以在这里回复用户的评论。

（2）官方 Google Play Console App

Google也像苹果一样，提供了官方的供开发者维护自己App的应用，Google Play Console App。你可以通过它在移动端方便的看评分和回复评论。

iOS端：apps.apple.com/cn/app/goog…
安卓端：play.google.com/store/apps/…

Google Play Console App 核心功能：

• 查看数据指标：监控安装量、卸载量、更新量以及应用的崩溃率（ANR/Crash）。
• 回复用户评论：及时查看并回复用户的评价，这对于维护 App 评分至关重要。
• 订单管理：查看应用内购买和订阅的订单详情，甚至可以进行简单的退款操作。
• 发布状态监控：跟踪应用版本的审核进度和发布状态。

3、Google不支持重置评分评论

Google不像苹果那样可以主动重置评分。虽然你不能手动重置，但 Google Play 的评分系统是动态权重的，更加偏重于近期（Recent）的用户评分权重会更高。

这意味着：
（1）如果你的应用过去因为有 Bug 而评分很低，只要你在新版本中修复了问题，随着新用户和老用户在近期的好评增多，你的平均分会逐渐回升。
（2）时间是最好的解药：只要新版本的体验确实提升了，评分曲线会自动向好的方向修正。

三、结束语

其实维护应用商店的评论，并不需要多么复杂的流程或高深的技巧，但你做了和没做，用户感受是不一样的，每个人都希望被尊重，用真诚打动你的用户吧！

希望这篇文章能给你一点帮助。如果你有更好的监控方法，欢迎留言交流。

参考文档
【苹果官方文档】查看评分和评论

2026年2月24日，出海社交领域迎来标志性的“黑色星期二”，百余款社交类App在无任何预警、无邮件通知、无申诉通道的情况下，被App Store集体下架。即便部分应用近期刚完成版本更新、运营状态平稳，也未能幸免。此次事件引发行业震动，苹果的清理行动究竟是偶然误伤还是定向整治？下架风暴的背后暗藏哪些监管逻辑？出海社交开发者如何突破困境、实现可持续发展？本文将深入拆解事件本质，梳理监管趋势，提供合规生存路径。

定向整治而非偶然误伤，四大市场同步发力

此次App Store下架行动并非随机操作，而是覆盖美国、澳大利亚、巴西、新加坡四大核心市场的定向清理，各市场虽审查重点略有差异，但整治核心高度统一，均聚焦于高风险社交场景。

美国作为全球最核心的应用市场，下架应用表面涵盖AI音乐、职场社交、旅游、育儿等多个品类，但核心筛选标准清晰——凡是包含“Live Chat”“Video Chat”“Meet New Friends”等关键词、以陌生人实时互动为核心功能的社交应用，均成为清理重点。

新加坡与澳大利亚的清理逻辑高度一致，对匿名社交类应用实施“零容忍”政策，大量主打“匿名聊天”“视频聊天”的产品被集中移除，其中不乏Aloha Live - Anonymous Chat、Xonder: Anonymous Chat & Vent等直接以“匿名”为核心卖点的应用，凸显两地对不可追溯社交模式的严格监管态度。

巴西市场的清理范围进一步扩大，除纯社交应用外，春辉乐玩、玩伴Vibe等具备旅游属性的轻度社交产品也被纳入下架名单。这一举措背后，是巴西市场将用户数据安全与未成年人保护纳入核心审查维度，审查标准提升至历史新高。

中国开发者高频踩雷：四类高危产品触发监管红线

梳理此次被下架的中国开发者相关产品，可发现其普遍存在明确的“高危特征”，均精准触碰了全球监管红线，具体可分为四大类：

1. 匿名树洞类产品

以默言、nimi-i人专属匿名聊天为代表，这类产品精准定位职场人、社恐群体的表达需求，主打“匿名对话”“无社交压力”等核心卖点，部分产品甚至取消点赞、推荐、动态广场等功能，极致强化匿名属性。但在监管层面，匿名意味着用户行为不可追溯，此类模式被明确界定为“高风险交互模式”，极易成为不良信息传播的载体，从而触发监管处罚。

2. 速配交友类产品

连连婚恋、LivMe-Meet new friend等产品均以“陌生人速配”为核心模式，前者面向职场人群提供免费婚恋交友服务，后者主打全球范围内的随机匹配聊天。此类产品的核心痛点的在于，多数中小开发团队难以承担7×24小时实时内容审核的成本，缺乏完善的审核机制，导致诈骗、色情等违法违规信息极易滋生，成为监管重点整治对象。

3. AI情感伴侣类产品

Joiy、ItsMee等产品将AI技术与情感社交深度结合，推出AI聊天、情绪匹配、专属AI聊天机器人等功能，看似是产品创新，实则触碰监管敏感点。AI技术本身并非违规核心，但当AI被用于模拟人类进行情感交流，且存在触达未成年人的可能时，监管容忍度降至零。此次下架也明确释放信号：情感类AI社交已成为全球监管的下一重点领域。

4. 马甲工具/社区类产品

部分产品以工具、垂直社区为外壳，暗藏社交属性，例如摄影社区CNU-顶尖视觉精选，虽以摄影内容分享为核心，但包含UGC内容发布、用户私信互动等社交功能，最终也被纳入清理范围。这一现象表明，只要涉及用户互动与内容传播，无论产品外在形态如何，均需遵守社交应用监管规范，不存在“法外之地”。

双重监管合围：苹果新规与全球法律形成监管合力

此次下架风暴的爆发，并非苹果单独行动，而是苹果平台规则升级与全球各国监管政策收紧形成的合力，推动出海社交行业正式进入“强合规时代”。

苹果平台规则升级：匿名社交被明确禁止

2026年2月6日，苹果悄然更新《App Store审核指南》，在1.2章节“用户生成内容”中，明确将“随机或匿名聊天”与色情内容、人身威胁、欺凌等列为App Store禁入类型，并保留“未经通知即可移除应用”的权利。

此前广泛应用于陌生人社交的Chatroulette式随机匹配模式，曾是行业核心创新点，如今已被定义为高风险功能。苹果的监管逻辑清晰：匿名+随机社交模式需要极致的内容审核能力，而多数中小开发团队难以承担相应成本，为规避平台风险，采取“一刀切”的清理策略。

全球各国监管收紧：未成年人保护成核心红线

如果说苹果新规是“平台层面的管控”，全球各国的法律政策则是“市场层面的约束”，且均以未成年人保护为核心，进一步压缩不合规产品的生存空间：

——巴西、澳大利亚、新加坡：自2月24日起，下载18+应用需通过苹果年龄验证；巴西额外规定，包含“开箱抽奖”等类赌博机制的应用，直接评级为18+，直接切断此类社交+游戏类产品的未成年人用户市场。

——美国：犹他州《应用商店责任法案》已于2025年5月生效，要求应用商店强制验证用户年龄，未成年人账号需关联家长账号，开发者违规将面临家长最高1000美元/次的索赔，苹果为规避“连坐”风险，进一步提高应用审核标准。

——欧洲：欧盟近期认定TikTok的“成瘾性设计”（如无限滚动、自动播放）违反《数字服务法案》，拟处以全球年收入6%的罚款；西班牙更推进“禁止16岁以下未成年人使用社交媒体”的政策，进一步强化对未成年人的保护。

综上，此次下架风暴是全球监管层对社交产品的一次“全面清算”，过去“先野蛮生长、后合规整改”的出海模式已彻底失效。

2026年出海社交合规生存指南：三大路径实现突围

面对全球监管收紧的大环境，出海社交开发者若想实现可持续发展，核心在于放弃侥幸心理、坚守合规底线，以下三条路径可作为破局关键：

路径一：放弃匿名模式，搭建实名/强认证体系

若产品商业模式依赖“用户匿名、无需对言行负责”的核心逻辑，需尽快完成转型。未来社交产品的核心底线是“可追溯”，即便采用昵称体系，也需搭建完善的持久账户体系，通过手机号验证、身份信息核验等强认证方式，确保用户行为可追溯、可管控，从源头降低不良信息传播风险。

路径二：将合规融入产品功能，适配全球监管要求

苹果推出的“申报年龄范围API”不应被视为运营负担，而应作为核心功能进行适配。开发者可针对不同年龄段用户设计差异化内容与功能：对未成年人开启严格的内容过滤、使用时间管理机制；对成年人提供合规范围内的社交服务。这种“分龄管理”模式，不仅能满足全球监管要求，更能提升产品公信力，成为打入欧美主流市场的核心优势。

路径三：严控AI功能风险，建立完善的内容过滤机制

随着AI技术在社交领域的广泛应用，AI陪聊、AI生成头像、AI匹配等功能成为产品创新方向，但需严格把控风险。开发者在引入AI功能前，需明确三大核心问题：AI训练数据是否合法合规？是否存在生成涉黄、涉政等敏感内容的可能？是否会诱导未成年人做出危险行为？无论采用何种大模型，均需建立严格的输出过滤机制，即便牺牲部分产品趣味性，也要确保内容绝对安全——海外市场中，单一违规内容（如AI生成的疑似儿童违规图片），即可导致应用永久下架，开发者甚至需承担刑事责任。

结语：合规是出海社交的唯一生路

2026年2月24日的下架风暴，只是全球社交领域监管收紧的一个开端。随着全球数字治理体系的不断完善，过去依赖技术红利、模式创新就能快速出海的时代已一去不复返，合规能力将成为出海社交开发者的核心竞争力。

对于在此次风暴中下架的产品，行业深感遗憾；而对于仍在坚守的开发者，需重新审视产品逻辑，主动拥抱监管、搭建完善的合规体系。唯有坚守合规底线，才能在全球出海赛道中长久立足——2026年，合规才是出海社交的唯一生存通行证。

遵守规则，方得长治久安，最后祝大家大吉大利，今晚过审！

相关推荐

# 苹果开发者续费大坑及成功续费方案！亲测有效

# AppStore敏感词排查手册，多维度分析Guideline 2.3.1隐藏功能，轻松过审。

# 如何主动提防苹果3.2f的进攻，自查防御手册（代码篇）

# 如何主动提防苹果3.2f的进攻，自查防御手册（ASO篇）

# 苹果加急审核是“绿色通道”还是“死亡陷阱”？

# 苹果开发者邮箱，突然收到11.2通知严重么？

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题？

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

背景

今天是农历正月初八，春节后的第一个工作日。后台有粉丝留言，迎来的开年的第一记重磅打击。3.2f待终止通知。

踩线原因也是老生常谈了，严查分类之隐藏功能问题。

老iOSer对于这种情况已经是见怪不怪了，很多时候并非开发者想做某些Sao操作，实属无奈的多。毕竟，有业务苹果不能正面允许，不得已就采用这种上有政策下有对策的打法！

原因分析

通过进一步沟通，层层抽丝剥茧。终于定位到踩到隐藏功能的导火索，在AI加持的情况下使用了非公开的API获取业务层面需要的功能权限。从业务的角度来看功能确实实现了，从苹果监管的角度来看调用了越权的API属性。通过键值对的方式Hook数据结果。

实话讲AI背大锅，对于很多跨行的开发者来说，为了满足公司的开发需求保住饭碗使用AI的方式本身没有问题。关键的问题在于，无法Review AI所编写的代码是否合规。

所以，AI本质是一把双刃剑，在提高开发效率的同时，也需要额外考虑风控问题。

隐藏功能

隐藏功能的前身是苹果开发者指南中的-2.3.1条款。

主要意在通过一些动态下发的方式，直接或间接干预苹果审核所看到的内容。将符合苹果审核的内容作为A面，顺利通过审核，提高审核通过率。【俗称的AB面，也叫马甲包】

随着AppStore审核规则的加强，对于隐藏功能的判定不仅仅只是单纯的功能切换，而是上升到更为全面的元数据以及概念层面。

简单来说：

少做不做挂羊头卖狗肉的事情，苹果的算法比开发者想象中更加强大。

遵守规则，方得长治久安，最后祝大家大吉大利，今晚过审！

相关推荐

# 苹果开发者续费大坑及成功续费方案！亲测有效

# AppStore敏感词排查手册，多维度分析Guideline 2.3.1隐藏功能，轻松过审。

# 如何主动提防苹果3.2f的进攻，自查防御手册（代码篇）

# 如何主动提防苹果3.2f的进攻，自查防御手册（ASO篇）

# 苹果加急审核是“绿色通道”还是“死亡陷阱”？

# 苹果开发者邮箱，突然收到11.2通知严重么？

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题？

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

背景

春节将至，回乡的路依然开始堵车。对应AppStore来讲也是全民消费与线上活动进入高峰期。 昨天依然有海量 iOS 开发者集中提交新 App 与版本更新，直接导致App Store 审核队列拥堵、等待时长大幅拉长。

最常用的海外账号Buff都受到严重的影响：

一、当前审核现状

• 常规时段：约90% 应用在 24 小时内完成审核
• 春节高峰：审核周期普遍拉长至3–7 个工作日，复杂应用、游戏、含内购 / 支付功能的应用更久
• 核心原因：集中提审量暴增、审核人力有限、假期排班调整

二、为什么春节会 “堵审核”

1. 节日效应：开发者扎堆上线春节活动、红包、促销版本，提交量短期翻倍
2. 全球时差：苹果审核团队按欧美假期排班，春节期间人力收紧
3. 审核更严：节日流量大，苹果对合规、安全、支付、诱导分享审查更严格
4. 排队机制：先提交先处理，晚提交只能持续排队

三、开发者应对建议（实用可落地）

1. 错峰提交：尽量在节后1–2 周完成提审，避开春节拥堵高峰

2. 精简更新：非紧急功能延后上线，只发必更版本

3. 提前自检：先过一遍隐私政策、权限说明、内购协议、元数据，减少被拒重提

4. 用好加急通道

   • 适用：线上严重崩溃、重大安全漏洞、时效性极强的官方活动
   • 入口：App Store Connect → 联系我们 → 申请加急审核
   • 注意：次数有限，非真紧急慎用

5. 预留缓冲：春节上线计划按最长 7 天审核倒排工期

四、提醒

春节期间，需安排好值班人员，常规巡检App运行情况。同时，更需要关注开发者苹果邮箱，遭遇AppStore竞品的“敌袭”，错过最佳抢救时间。

遵守规则，方得长治久安，最后祝大家大吉大利，今晚过审！

相关推荐

# 苹果开发者续费大坑及成功续费方案！亲测有效

# AppStore敏感词排查手册，多维度分析Guideline 2.3.1隐藏功能，轻松过审。

# 如何主动提防苹果3.2f的进攻，自查防御手册（代码篇）

# 如何主动提防苹果3.2f的进攻，自查防御手册（ASO篇）

# 苹果加急审核是“绿色通道”还是“死亡陷阱”？

# 苹果开发者邮箱，突然收到11.2通知严重么？

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题？

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

你以为的“三方支付”的样子，和苹果谷歌落地“三方支付”的样子，堪比网友见面、梦境与现实。

• 抽成方面：即使你使用三方支付，苹果谷歌依然要抽成，只是换了个名字叫“商店服务费”，抽成并没有便宜多少。
• 财务对账：苹果谷歌为了审计你的三方支付的抽成，你需要每月和苹果谷歌对账、打款。
• 必须接入官方内购系统：即使使用三方支付，依然必须接入官方内购系统作为可选项，与三方支付并列显示。
• 劝退弹窗：用户使用三方支付时，会被苹果谷歌弹窗警告，“你即将离开安全环境”、“苹果将不再负责该交易的安全、退款及支持”等。

下面是详细介绍。

一、抽成费率

苹果和谷歌又将“三方支付”分为“应用内三方支付”、“网页外链支付”。顾名思义，“应用内三方支付”就是在应用内使用三方支付（例如接入PayPal SDK），“网页外链支付”就是跳出应用，打开外链支付。二者抽成比例是不一样的。

苹果

在日本，苹果将原来的“佣金”拆分成了 “商店服务费” 和 固定5%的“支付处理费”。如果使用三方支付，则不用出 5%“支付处理费”，但“商店服务费”还是得出。苹果：我聪明吧。

方案	苹果收取的商店服务费	苹果收的支付服务费	苹果抽成合计
官方内购	21% (小型开发者或订阅 10%)	5%	15% ~ 26%
App内三方支付	21% (小型开发者或订阅 10%)	0	10% ~ 21%
网页外链支付	15% (小型开发者或订阅 10%)	0	10% ~ 15%

信源：Changes to iOS in Japan

谷歌

场景	Google 收取的费率	谷歌抽成合计
官方内购	30% (小型开发者或订阅 15%)	15% ~ 30%
App内三方支付	26% (小型开发者或订阅 11%)	11% ~ 26%
网页外链支付	20% (小型开发者或订阅 10%)	10% ~ 20%

App内三方支付，4%优惠，信源：自选结算系统优惠4%、Understanding user choice billing on Google Play（文档里列出了JP）

网页外链支付，10%优惠，信源：Enrolling in the external offers program

费率小结：
三方支付，支付通道（PayPal、Stripe等）收取的通道费一般在3%左右，所以三方支付的综合成本，应该在上面再加上3%。加完后，应用内三方支付和官方内购差别极小，毫无优势。只有“网页外链支付”在抽成方面占优势，但“网页外链支付”体验很差，用户可能更倾向选官方内购，导致“网页外链支付”实际使用率低，达不到降低抽成的效果。

二、申请开通

使用三方支付（App内三方支付、网页外链支付）均需向苹果和谷歌提交申请，并签署新的协议条款。

向苹果提交申请

1、签署最新商业条款

账号持有者（Account Holder）登录 Apple Developer 官网。 在协议（Agreements）页面，找到并签署针对日本地区的最新补充协议（如 Alternative Terms Addendum for Apps in Japan）。这代表你接受苹果的新版佣金结构及月度申报制度。

2、提交在线申请表单

（1）申请入口： 访问苹果官方的权限申请表单（需登录）

（2）选择授权类型：

• 外链支付：勾选 StoreKit External Purchase Link Entitlement (Japan)。
• 第三方支付：勾选 Alternative Payment Processor Entitlement (Japan)。

（3）填写 App 详细信息：

• Bundle ID：必须是已经上架或准备在日本商店分发的 App ID。
• 支付网站域名：如果是申请外链支付，必须提供你计划链接到的顶级域名（URL 必须是 HTTPS 且归属于开发者）。
• PSP 信息：如果是第三方内购，需要填写你合作的支付服务商名称（如 Stripe, PayPay 等）。

向谷歌提交申请

申请“第三方应用内支付”（Google Play External Payments Declaration Form）

1、主体要求： 必须是以“企业/组织”名义注册的账号（个人开发者目前很难申请通过）
2、目标市场： App 必须在日本市场分发，且该功能仅对日本用户生效。
3、技术准备： App 必须集成 Play Billing Library 8.2 或更高版本。即使申请通过，不调用新版本API没办法实现。
4、谷歌官方的帮助文档页面，找到“declaration form”入口进行意向申请 (提交后，谷歌会审核开发者身份，然后后台开放配置入口)
5、如果意向申请通过，Google Play Console -> 在左侧菜单中找到 设置 (Settings) -> 外部支付计划，这个页面可以提交计划使用的外部支付网址URL，然后供谷歌审核
6、提供详细信息：

开发者账号ID：Google Play Console后台可查看的开发者账号ID
企业官方名称：必须与你申请开发者账号时提交的企业名称一致
企业注册地址：请使用注册公司所在国家/地区的官方语言输入地址
应用包名：填写要申请应用的包名，可以一次申请多个应用，但每个应用都需要符合日本分发要求。
账单寄送地址：谷歌在电子发票上显示的地址。用于财务对账和开票。
账单接收邮箱地址：谷歌会根据上报的金额按月向这个邮箱发送服务费账单
联系人邮箱：政策审核、技术问题、合规通知的接收邮箱
用户申诉的地址：一般可以是客服链接或者处理交易纠纷的邮箱地址

三、每月对账：上报三方支付流水

因为苹果和谷歌需要对三方支付抽成，所以需要按照平台要求，每月和苹果谷歌对账，提交三方支付流水。如果被发现瞒报、漏报，苹果和谷歌会采取极严厉的惩罚，包括：追缴欠款及利息；终止该权益的使用权限； 封禁开发者账号。

向苹果提交交易报告

采用 API 实时上报 + 每月财务对账” 的模式。 注意，即使做了API实时上报，也必须做每月App Store Connect的对账进行二次确认。

1、技术侧实时上报

整体流程：客户端生成 Token (StoreKit 侧) => 业务服务端 => 苹果服务器

（1）App 调用 ExternalPurchase.present() (针对外链) 或 ExternalPurchase.purchase() (针对三方支付)

（2）如果用户在系统弹窗中点击了“继续”，StoreKit 会生成一个加密的 ExternalPurchaseToken（字符串格式）。这个 Token 包含了当前用户、当前 App 以及这次点击行为的唯一标识，它是苹果后续对账的唯一凭证，每月财务对账的csv文件里也需要包含该字段。

（3）客户端将token发送给业务服务端。业务服务器需要将这个 Token 与该用户的订单/会话进行关联。如果是外链支付，可能需要暂存这个 Token，等待用户在网页端完成支付

（4）服务器收到三方支付回调（确认钱已到账）后，必须立即（或在 24 小时内）通过 External Purchase Server API 调用 Send External Purchase Report 接口。

上报内容：你需要把从客户端拿到的 Token，连同实际的交易金额（Amount）、货币类型（Currency）以及交易时间戳一起发给苹果服务器。

退款上报：如果用户后来在三方支付端发起了退款，你的服务器也需要通过 API 向苹果上报这笔退款，否则苹果依然会扣你这笔订单的佣金。

2、每月财务对账与支付

（1）在每个日历月结束后的 15天内，你需要通过 App Store Connect 提交一份详细的交易报告。申报通常是上传一个 .csv 格式的模板文件

申报填写字段： 
App Apple ID,纯数字,您 App 的唯一 ID 
Transaction Date,日期格式,交易发生的具体日期 
PSP Name,手动输入文本,您使用的支付服务商全称 
Purchase Token,字符串,技术端生成的唯一追踪标识符
Sales Amount,数字,用户实际支付的金额（需扣除交易税） 

（2）即使无交易也需汇报：如果该月没有产生任何三方支付流水，您依然需要提交一份“零交易汇报（Zero Transaction Report）”

（3）提交入口：App Store Connect - “Payments and Financial Reports” (付款和财务报告) 模块 - “External Purchases” (外部购买) 选项卡

（4）上传或确认数据：系统通常会根据您通过 API 上报的数据自动预填部分信息。您需要核对并上传最终的 CSV 格式报告，确保其与您的财务记录一致。

（5）苹果会根据你申报的销售额扣除佣金，然后向你发送电子发票。你需要按照发票金额，在规定时间内通过银行转账等方式向苹果支付这笔费用。

（6）注意：为了防止偷税漏税，苹果在协议中保留了强力审计权：苹果有权雇佣第三方审计机构检查你的财务账簿。如果被发现瞒报、漏报，苹果会采取极严厉的惩罚，包括：追缴欠款及利息；终止该权益的使用权限；封禁开发者账号。

向谷歌提交交易报告

采用 "API 实时上报 + 开发者后台汇总确认" 的模式。谷歌不用每月手动上报，采用全自动上报模式，但需要核对漏报进行补报。

1、技术侧实时上报
与苹果相比，谷歌的流程更强调实时性 （24小时内） 和交易类型的精细化。

整体流程：客户端生成 Token (externalTransactionToken) => 业务服务端 => 谷歌服务器

（1）当用户在 App 内选择三方支付或点击外链，并在 Google Play 弹出的系统底页（Disclosure Sheet）点击“确认”后，Billing Library 会向你的 App 返回一个 externalTransactionToken。App 必须将此 Token 连同订单信息传给你的业务后端。它是这笔交易唯一的身份凭证。

（2）每当三方支付成功后，你必须在 24 小时内 通过服务端调用 externaltransactions API。内容：上报 Token、交易金额、货币、时间戳、税收地址（日本区对税收合规要求严格）以及交易类型。

你的服务器需要使用一个拥有 Reply to reviews 或 Manage orders 权限的 Google Cloud 服务账号 (Service Account)。

业务服务端调用上报接口
接口地址： POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/externalTransactions?externalTransactionId={ID}
URL参数：externalTransactionId：由你定义的唯一订单号（建议使用你数据库里的自增 ID 或 UUID）。

请求body参数：
{
 "externalTransactionToken": "从客户端传来的Token",
 "transactionTime": "2025-12-30T10:00:00Z",
 "oneTimeTransaction": {
  "fullPrice": {
   "amountMicros": "1000000", // 代表 1.00 货币单位（百万分之一单位）
   "currency": "JPY"
  }
 },
 // 或者如果是订阅
 // "recurringTransaction": { ... },
 "userTaxAddress": {
  "regionCode": "JP" // 对日本区对账极其重要
 }
}

（3）异常处理：如果在 API 上报过程中出现了由于网络等原因导致的漏报，你需要在次月 5 个工作日内 通过 API 补报（补报之前的漏单）

（4）下载报告核对：你可以从 Google Play Console 的 创收 > 备选的结算系统 中导出谷歌生成的报告，将其与你自己的数据库进行核对。如果金额对不上，通常是因为你漏报了某些 API 请求。

  参考资料：
创建/上报交易 (Create Transaction) developers.google.com/android-pub…
注：在该页面左侧菜单可以看到 get 和 refund（退款）接口

备选结算系统（Alternative Billing）集成指南
developer.android.com/google/play…
此页面包含了“报告外部交易”的技术步骤说明。

2、 账单确认与支付
生成账单：谷歌会根据你 API 上报的数据，在次月生成汇总账单。
支付方式：不像苹果通常需要你主动汇款，谷歌通常会从你账户绑定的结算方式（信用卡或付款资料） 中直接扣除这部分佣金，或者发送正式账单让你在规定时间内支付。

四、严苛的“劝退式”交互

为了保护自己的生态，两大巨头在用户体验上设置了重重障碍：

内购强制接入： 苹果和谷歌均要求，开发者不能仅提供第三方支付，必须同时接入官方内购作为选项，且官方支付按钮的醒目程度必须不低于第三方支付。

劝退的风险弹窗： 用户在点击第三方支付链接时，系统会弹出充满“警告色”的通知（如：“你即将离开安全环境”、“苹果将不再负责该交易的安全、退款及支持”等），这极大地增加了用户的跳失率。

五、总结

1、并没有消失的“平台税”

先看抽成方面。

通过应用内三方支付SDK方式接入，体验较好，但抽成比例和官方支付差别很小，可以省约 1%~2% ；只有通过外链跳出App支付这种方式接入，省的比较多，可以省7%左右，但这种方式体验较差，再加上平台强制“风险警告弹窗”，即使接入了这种支付方式，最终又有多少比例的用户会选择这种支付方式呢？所以，这个7%可能需要打个大折扣。

总结起来就是，接入三方支付并不一定会“省钱”。

2、从运营成本方面看

一旦采用第三方支付，开发者需要承担原本由平台处理的大量行政工作：

每月结算申报： 开发者必须每月手动向苹果/谷歌申报通过第三方渠道产生的流水，并根据申报单向平台转账支付佣金。

自理客服与退款： 所有的退款申请、订阅管理和支付争议，平台一概不管，开发者必须建立自己的客服团队来处理这些琐事。

接受审计风险： 平台保留对开发者财务记录进行审计的权利。如果瞒报、（人员或技术疏忽导致的）漏报三方支付流水，可能面临权利被限制、下架或封号等风险。

3、过审可能变得困难

接入三方支付，会增加包体提审被拒的风险。

作为开发者，提审时需要额外在审核备注里说明接入了三方支付，并提供支付流程截图或视频。

作为审核人员，也会额外“关照”接入了三方支付的应用，检查是否符合相关审核要求。

包体层面，接入三方支付，势必会在包体里加入支付判断、支付切换，或者嵌入三方支付SDK 等高风险行为。机器审核有可能误判为切支付、隐藏功能，增加过审难度。

4、可能失去官方推荐资格

虽然苹果和谷歌官方层面没有明确表明，接入三方支付的应用不会被推荐。但从平台的角度出发，加入三方支付，很大程度上会影响被平台推荐的可能性。

苹果
官方口径： 只要符合 Guideline 3.1.1(a) 且已获得 Entitlement 授权，应用在法律上具备推荐资格。

实际：苹果的推荐位是由其编辑团队（App Store Editors）人工筛选的。他们的考核标准中，“用户体验的一致性”权重极高。三方支付必须弹出一个“离开 App”的系统警告框。对于编辑来说，这种“打断感”被视为用户体验的瑕疵。编辑团队通常倾向于推荐那些能给平台带来完整生态价值（包括 IAP 闭环）的应用。

谷歌
官方口径： 参与 User Choice Billing (UCB) 计划的应用，其推荐资格不受限制。

实际： 算法决定了你是否能进入备选池，人工决定了你是否被推荐。谷歌的自动化推荐算法（如“猜你喜欢”）基于转化率和评分。如果三方支付导致支付流程变长、跳出率增加，你的算法推荐位会自然下降。针对三方支付的退款请求，务必在 App 内提供显著的客服入口，避免用户在商店留下“无法退款，骗钱”的差评，这是算法降权的头号原因。

结语

看完上面的内容，你还会觉得“三方支付真香”吗？

而且，后续如果其它国家或地区吵着要开三方支付，大概率也会遵循上面日本的范式。

放弃幻想吧，宝子们！

背景

继 1 月做空机构 CapitalWatch 指控 AppLovin 深度涉入洗钱网络、关联东南亚 “杀猪盘” 后，这场资本风波的余震仍在持续。最新市场数据显示，截至 2026 年 2 月 5 日，AppLovin（股票代码：APP）股价已从 2025 年 11 月 10 日的 651.32 美元跌至 375.23 美元，三个月累计跌幅达 42.39% ；仅 2 月前 5 个交易日，股价就从 483 美元跌至 375.23 美元，单周跌幅超 22%，换手率最高达 6.65%，市场恐慌情绪可见一斑。

争议再发酵：从股东合规到 SDK 技术风险

此前 CapitalWatch 的报告已指出，AppLovin 主要股东 Hao Tang、Ling Tang（被指为 Hao Tang 亲属）及关联方合计持股超 28%，涉嫌通过广告业务协助转移团贷网非法集资款、东南亚诈骗资金。尽管 AppLovin 全盘否认指控，称 “无法控制个人股票买卖”，但市场对其股东层面的合规失职质疑未消 —— 作为上市公司，对主要股东的背景审查、反洗钱流程是否到位，至今仍是未解之谜。

更关键的是，这场争议已直接波及普通开发者。有行业分析指出，AppLovin 的 SDK 存在两大核心风险：一是技术合规问题，其 SDK 被曝包含指纹追踪、静默安装功能，前者可能违反用户隐私保护法规（如 GDPR、CCPA），后者则可能绕过用户授权强制安装应用，存在被应用商店下架的隐患；二是连带风险，若后续监管部门（如美国司法部、SEC）对 AppLovin 启动调查，或要求平台自查涉事 SDK，开发者可能面临 “猝不及防的下架压力”，影响应用正常运营。

股价暴跌背后：多重利空下的市场信心崩塌

从股价走势看，AppLovin 的颓势并非偶然。除了洗钱、SDK 合规争议，其商业模式本身也存在隐忧。此前已有做空机构指出，AppLovin 约 35% 的广告收入来自超休闲游戏，而这类业务的虚假点击占比或达 20% ；同时，公司 60% 的流量依赖 Meta 和 Google，若上游平台调整政策，收入可能面临断崖式下跌。

叠加最新的合规风险，机构对其估值的分歧持续扩大。截至 2 月，尽管仍有 9 家机构给出 “强力推荐” 评级，但最低目标价仅 80 美元，较当前股价隐含 75.8% 的跌幅。空头仓位也在激增，1 月 3 日单日做空量占比达 21.36%，累计空头仓位超流通股 15%，逼近熔断阈值，市场对其信心已降至冰点。

开发者应对指南：规避风险刻不容缓

面对 AppLovin 的多重危机，开发者需优先考虑业务稳定性，避免踩入合规 “雷区”：

• 评估替换方案：若当前应用集成了 AppLovin SDK，建议尽快调研广告聚合平台，通过接入多渠道广告源，降低对单一 SDK 的依赖，避免因 SDK 下架导致收入断层；
• 自查合规细节：重点检查 AppLovin SDK 的指纹追踪、静默安装功能是否关闭，确保用户数据收集、应用安装流程符合当地隐私法规（如 GDPR 的用户同意要求）；
• 跟踪监管动态：密切关注美国司法部、SEC 及应用商店（如苹果 App Store、Google Play）的最新政策，若出现针对 AppLovin 的调查或下架通知，需第一时间启动应急方案。

AppLovin 的案例也为整个行业敲响警钟：在选择第三方 SDK 时，除了关注流量、收益，更需穿透式审查合规情况。

毕竟，一次合规危机带来的损失，可能远超过去的收益。

遵守规则，方得长治久安，最后祝大家大吉大利，今晚过审！

相关推荐

# 苹果开发者续费大坑及成功续费方案！亲测有效

# AppStore敏感词排查手册，多维度分析Guideline 2.3.1隐藏功能，轻松过审。

# 如何主动提防苹果3.2f的进攻，自查防御手册（代码篇）

# 如何主动提防苹果3.2f的进攻，自查防御手册（ASO篇）

# 苹果加急审核是“绿色通道”还是“死亡陷阱”？

# 苹果开发者邮箱，突然收到11.2通知严重么？

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题？

# 有幸和Appstore审核人员进行了一场视频会议特此记录。