Google 可以说是 5 月最出尽风头的科技公司，趁着 Goog I/O 大会的节点，一口气发布了大量新产品——

有颠覆手机系统的智能系统和 Gemini Intelligence，有颠覆电脑使用范式的 Googlebook，还有这个要颠覆智能手表的无屏手环 Fitbit Air——内嵌 Gemini，主打 AI 健康功能。

为此，Google 不仅重新捡起了快被扫进垃圾堆的 Fitbit，还请来 NBA 当家球星库里做代言。野心很明显，就是要在智能穿戴拿下一块市场。

不过，Fitbit Air 瞄准的并不是苹果 Apple Watch，而是对标这两年大火的「WHOOP」——这是一家创立 12 年，却在近两年异军突起的科技新贵，无屏手环是他们最主要的产品。

WHOOP 从产品定义到营销策略，都相当特立独行。他们不卖手环，直接送！只是如果想正常使用，要收一笔不菲的订阅费，来开启 AI 健康功能。

今年 3 月，WHOOP 完成 6 亿美元融资，估值超过 100 亿美元。

在这个充电头都会加一块屏幕的时代，一个没有屏幕的智能手环却卖爆了，凭什么？

无感设计，极致简洁

WHOOP 并不是一家初创公司，实际上成立于 2012 年，早于初代 Apple Watch，和 FitBit、Pebble 等名字并列为智能手表的探索者。

在那个技术还没那么发达的年代，手腕上没法集成太多东西，所以像主打健身健康的 Fitbit 和 WHOOP，初代产品基本上都是一个没屏幕的手环，反馈和交互靠手机 App 完成，本质上和在手腕上绑了一堆传感器无异。

随着技术发展，以及 Apple Watch 对用户心智的教育，类似的智能手环产品很快也都配备了一个小屏幕——在当时，手腕上的触控屏是大势所趋，要不然为什么要无缘无故给身上带个不便宜的手环？

WHOOP 不这么认为，时至今日他们的手环产品依旧没有屏幕，仿佛这十几年的智能穿戴变革浪潮，将他们给遗忘了。

一开始做无屏是妥协，现在还在做无屏，那就是「坚持」了。

实际上，「无屏」这件事，让 WHOOP 变成了一个异常简单的产品，没有太多复杂性和限制，带来了使用上的自由。

创始人 Will Ahmed 认为，一旦为 WHOOP 配备屏幕，那么就会不断加入时间、健康提醒、消息提醒这些功能，成了一块智能手表。这个赛道，很难和苹果三星等品牌竞争。

Reddit 上不少用户也表示，选择 WHOOP 的原因，就是因为它没有一块让人分心的屏幕，够纯粹。

WHOOP 的本质就是一个健康传感器，你可以将它佩戴在在身上的不同地方，官方也推出了可以和 WHOOP 配套使用的贴身衣物配件，这种灵活性是智能手表和智能指环都难以媲美的。

Apple Watch 的逻辑，是把更多信息带到手腕上；WHOOP 的逻辑，则是设备彻底退居幕后。

追根溯源，最终让 Apple Watch 得以成立并走进千家万户的原因，也是因为苹果为其找到了「运动健康」这个主要定位。

这就带来了一个很有意思的反转：Apple Watch 本来应该杀死智能手环的比赛，但随着智能手表越来越普及，也越来越多人能理解「在身上绑传感器」的价值，反而让 WHOOP 极致简洁的价值得以凸显。

时至今日，依然有不少人更偏爱具备美学价值的传统机械表，又向往 Apple Watch 的健康监测功能，只是手上同时戴两块表难免显得有些别扭。爱范儿也采访了身边的真实用户 @flypig，他告诉我们：

因为我有不少机械腕表，我认为是一些蛮好看的饰品，根据心情换着戴。但我又有记录身体状态的需求。我不希望左手一块机械腕表，右手一块 Apple Watch。我试过，感觉戴两块表看起来还是太怪了。

单论产品形态，WHOOP 比 Apple Watch 有不少优势：没了屏幕，换来了两三周的续航，还有极致的轻便，顶配版也不到 30 克，佩戴在身上几乎无感；硬件本身成本极低，会员提供终身保修，非常适合极限运动爱好者，丢了换新也只需要 50-80 美元不等的补办费。

由于 WHOOP 手环本身没有任何交互，只需要「佩戴」，这意味着对于儿童，特别是更需要健康监测的老人群体来说，没有任何使用的门槛。

让人愿意戴，并且愿意长时间戴，这就是智能穿戴产品最重要的优势，这样看来，极致简洁的 WHOOP 已经是一个相当有价值的产品。

普惠，从运动员到每个人

10 年的时间，智能穿戴领域瞬息万变，最早的行业竞争者 Fitbit 和 Pebble 在苹果等大厂入局后，都走向了沉寂。

WHOOP 不仅顽强存活了 12 年，还在这两年大火。这个看似「逆袭」的故事，或许从一开始，就已经埋下了伏笔。

在成军之初，WHOOP 就没有瞄准大众用户，功能不止于步数、心率这些常规体征数值，直接聚焦「睡眠」「恢复」和「负荷」三大指标，用量化的分数告诉用户每一天醒来恢复程度如何，今天是否适合训练。

这种功能源自于创始人 Will Ahmed 自己大学时期作为壁球队员的经历：他发现自己很难达到训练量和恢复之间的平衡，于是开发了专注于追踪恢复、运动负荷和睡眠指标的 WHOOP。

由运动员打造的产品，自然最懂运动员，因此 WHOOP 在最初就瞄准了运动员这个非常独特的用户群体。

虽然这让他们在大众消费者之间的知名度更低，却避开了和 Fitbit 和 Apple Watch 竞争，拿下了包括美国职业棒球联盟在内很多职业运动队的独家订单。

并且，WHOOP 的专业属性很快也获得了 NBA 明星勒布朗 · 詹姆斯，和「C 罗」克里斯蒂亚诺·罗纳尔多这样的重量级用户作为「自来水」，不愁曝光和知名度。

这也是 WHOOP 的聪明之处。 不管是什么消费品，由大众产品冲击高端很难，但反过来要轻松得多了。

对于中产阶层来说，WHOOP 自带了一个「精英运动员同款」的光环，建立起「专业」的品牌形象，只差购买的契机。

2018 年开始，WHOOP 将产品从原本的 500 美元售价，转变成 6 个月起订，每个月 30 美元的订阅方式，大幅降低了准入门槛，正式向大众消费市场进军。

这个转变也彻底改写了 WHOOP 的商业模式：从一家「硬件」品牌，转变为了售卖软件的服务商。

手环是 WHOOP 商业模式的起点，却并非核心。这个手环几乎是「白送」给用户，WHOOP 在官网售卖的直接就是「订阅」，买的是一年的会员，成本直接包含在订阅费之中，免费试用一个月甚至直接送你一个手环。

当然，WHOOP 不同档位的会员，能拿到的表带配置有所不同，只是 WHOOP 不需要你为硬件付费，套餐可以随时换。

购买 Apple Watch 之后，只要硬件本身没有故障，理论上你获得了这个产品的终身使用权；至于 WHOOP，只要停止续费，那么你手上的表带就没有任何价值。

硬件形态只能吸引体验，软件体验才能真正留住人心，对于 WHOOP 来说更是如此。

WHOOP 的手机应用，把身体数据做成了一种几乎不需要学习成本的「身体仪表盘」，各种可视化图表，自己今天睡得怎么样、锻炼强度如何，身体年龄多少，一目了然。

普通人或许很难理解自己的「恢复」分数究竟算高还是低，但通过颜色区分，身体状态会变得非常直观—— 绿色意味着恢复状态良好，今天可以正常训练；红色则像是一张警告牌，提醒你身体还没缓过来，最好暂停运动。

全球疫情之后，越来越多人开始关注自己的「身体状态」，而不只是单纯记录运动数据。这个趋势，恰好撞上了 WHOOP 从「运动装备」向「生活方式品牌」的转型期。

与此同时，随着房颤、血压趋势等健康监测功能不断加入，再加上 WHOOP 4.0 在续航、体积和佩戴体验上的全面升级，以及免费试用机制降低门槛，越来越多原本并不热衷运动的普通用户，也开始接触并接受这个品牌。

从运动员的明星光环带动，到低门槛高价值的使用方式，WHOOP 也从从一款运动员工具，变成了一种新的中产社交符号，就像 Lululemon、冷水浴、燕麦奶。

你未必真的运动，但只要把 WHOOP 戴在手上，就仿佛已经进入了那个高度自律、关注健康、持续优化自己的生活方式体系——至少外人看来如此。

买 AI 硬件，就是为 AI 付费

WHOOP 这种订阅制的商业模式，对于智能手表来说很超前，但和当下热门的「AI 硬件」，又惊人地相似。

用 Plaud 举例，只要你是真正的录音笔目标用户，基本绕不开会员订阅，才能获取足够的录音转写时长，而它体验的核心，就是那个负责整理、理解和调用录音内容的 App。

以前做产品和硬件，我们会推崇「All in One」，在有限的机身中尽可能配备更多的功能。

而现在，我们看到许多真正跑通的「AI 硬件」，反而都回到了更简单的形态：功能单一、交互克制，却能够深入某个具体场景，持续收集数据，再交由后端 AI 去整理、理解，并最终生成真正有价值的结果。

WHOOP 也是如此，它的形态，真的就是将传感器绑在身上，贴近身体的同时又保证尽可能无感。

智能穿戴近年的方向，也已经不止于单纯收集数据，还要呈现简单易懂的结果。Apple Watch 的「生命体征」功能，本质上就是把体温、血氧、心率、睡眠等趋势，浓缩成「身体是否异常」的直观指标。

2022 年底，ChatGPT 掀起了生成式 AI 的浪潮，每个行业都在借助 AI 改造自己的产品和商业模式。2023 年 9 月，WHOOP 接入了 GPT-4，推出「WHOOP 教练」功能，利用大模型对用户的数据进行解读，提供更个性化的建议，属于第一批尝试将 AI 和健康相结合的厂商。

由于布局时间早，WHOOP 算得上是当今智能穿戴产品中 AI 健康功能的第一梯队。CNET 的编辑尝试过很多类似的产品，唯独觉得 WHOOP 是「好用」的：

她忘记了自己即将要来月经，而 WHOOP 教练提前两天通知她激素发生变化，因此锻炼会更吃力，建议降低强度，并在月经期间根据她的恢复情况，智能轮换调整了她的训练计划，很好帮她纠正了「练得多=更好」的心态。

@flypig 则表示：

我认为它的 AI 能力——特别是那个 LLM 问答框的体验——实属一般般。但它 AI 之外的智能建议和规划能力，我认为，很不错，够用了。我愿意每年给他们交钱。

从 WHOOP 可以看出，健康监测和 AI 属于一种「双向奔赴」。

智能穿戴设备能持续对身体的指标进行长时间监控，但累积了海量数据之后，对用户的价值却没那么大。

而想要从 AI 那里获得很好的结果，就必须要提供充足且高质量的上下文，智能穿戴设备获得的数据，刚好可以让 AI 进行和解读。

智能穿戴接下来要实现的跃迁， 不仅要替你解读数据，还要根据数据直接给你实在的建议。

这也是为什么，沉寂了好几年的 Fitbit 忽然被复活。

本来 Google 已经有了 Pixel Watch 的可穿戴产品线，不带屏幕的 Fitbit 的重点放在了 AI 健康模式上，为自家的 Gemini 找到了另一个落地的场景，不只是 Google 生态，甚至在打苹果阵营的主意。

我依旧不会将 WHOOP 或者 Fitbit 称作一个「AI 硬件」， 它们更像是借助 AI 完成了一次新的叙事包装，核心依旧是健康监测那套已经被验证了十多年的逻辑，这也是它们能重新进入大众视野的原因。

当传感器本身逐渐触及技术瓶颈，智能穿戴真正重要的问题，也从「还能测到什么」，逐渐过渡到「如何理解这些数据」，WHOOP 在讲的，就是这样一个故事。

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

距离苹果全球开发者大会 WWDC 还有一个月不到的时间，彭博社又送上关于苹果新系统的全新爆料：

苹果准备对 macOS 27 的界面进行一轮小幅调整，进一步完善「液态玻璃」设计语言的视觉表现。

但问题在于，对于如今的 Mac 来说，除了需要继续打磨的 UI，最迫切的更新显然远不止于此。

液态玻璃，缝缝补补又一年

对比 iPhone 以及 iPad，Mac 的性能和续航都更有盈余，实际上 macOS 26 的界面，视觉效果要更接近去年 WWDC 上面演示的「满血版」液态玻璃。

不过，液态玻璃立项之初，就是专门为 OLED 屏幕设计的，而目前所有 Mac 产品都在使用 LCD 屏幕，在呈现半透明、阴影和玻璃质感的方面，效果不如 OLED。

于是 macOS 26 的一些高透明效果和阴影，会导致列表和文字可读性下降——这也是「液态玻璃」被一直诟病的问题。

和 iOS 27 一样，macOS 27 也将仔细打磨液态玻璃，让它更接近苹果一开始设想的效果：兼顾透明度和可读性，同时进一步优化能耗表现。

不过，macOS 26 在 UI 上的问题根本不止于液态玻璃本身，不对齐的圆角、大量分散注意力的小图标，以及重新设计后辨识度大打折扣的应用图标，对可读性和美观层面都造成了一定的影响。

苹果评论员 John Gruber 对于 macOS 液态玻璃的点评相当一针见血：作为一种「内容优先」的设计语言，液态玻璃让系统 UI 隐身于媒体之后，在 iPhone 上或许能行，但作为强调生产力而非内容消费的桌面平台，Mac 包含大量的窗口、组间，因此复杂性更高，仍然需要应用界面保证清晰的结构、分明的功能区域，和强辨识度的界面。

在 Stephen Lemay 接任设计总监一职后，这位在苹果服务近 30 年的老将表现让人期待——Lemay 以公司内部的高口碑和稳定发挥著称，或许也称得上是苹果内部目前最懂苹果系统界面的人。

在他的把控下，macOS 27，以及 iOS 27 如何扭转液态玻璃褒贬不一的口碑，回到实用性和美感并举的方向，确实值得期待。

但对于 macOS 来说，界面上的「拨乱反正」固然必要，却已经不是最重要的更新了。

对苹果而言，未来系统的更新有两条主线：一方面，优化系统稳定性，另一方面，则是为 Apple 智能预备好。

最好的 AI 载体，需要一个 AIOS

根据彭博社爆料，苹果打算为「Apple 智能」打造一个「Extensions」功能，允许用户更换第三方 AI 模型，例如 Google Gemini、Claude 等等。

Siri 除了会集成到邮件、短信、相册等应用，自己也会化身聊天机器人，成为一个单独的应用。更多 AI 功能还会覆盖文本、图像等生成与编辑任务。

但这些更新，说实话更多还是做 AI 的单点功能，并非系统级别的编排能力，并未能进一步发挥 Mac 硬件上的优势。

今年年初的龙虾热，让 Mac mini 这个前年才火过的产品，又再一次出圈，这次火到苹果自己也没库存了，「入门版」在官网彻底售罄。

Mac 和 Windows 在不少层面上互有胜负，但在 AI 的问题上，Mac 作为「最佳 AI 容器」的论断几乎毫无争议。

关于这个问题，爱范儿已经出过一篇文章详细讨论。简单来说，就是因为 Mac 不管是 UNIX 系统底层还是集成运存的硬件架构，都非常契合 AI Agent 和大模型的运行方式，并且由于 ARM 架构的特性，运行功耗低还静音，非常适合 AI 常驻。

这更像是「无心插柳柳成荫」，苹果其实一开始并没有围绕 AI 去打造自己的 Mac，却无意间完成了所有 AI 的技术储备，严格意义上说是一种「适配度优势」。

从这个角度看，macOS 即使什么都不做，本身 Mac 也已经是一个很好的 AI 平台。苹果完全可以走 App Store 的逻辑，让用户自己部署想要的第三方 AI 智能体，自己继续扮演「收过路费」的角色。

这确实也是苹果长期以来的做法：在移动互联网兴起之时，苹果没必要自己做搜索引擎和网购平台。而 AI 时代，大众的需求变化万千，有人需要一个能剪辑的 Agent，也有人需要一个搞科研的 AI，必须要靠第三方满足。

在今年 5 月的财报会议上，苹果特别提到了 AI 公司 Perplexity 的智能体产品 Personal Computer，认为这种产品很好利用了 Mac 平台的能力。

既然觉得人家做得不错，何不自己上手做一个「iClaw」？

第三方 AI 百花齐放固然很好，这和苹果自己做一个却并不冲突，并且很多事情，只有第一方能做得好，能做得让人放心。

第三方应用再强，也很难自然获得系统级的上下文，苹果不可能将最底层的权限开放，只有系统底层自己能对文件位置、窗口状态、本地个人数据知道一清二楚，而 AI 应用的体验，往往就卡在了这些权限边界之上。

其实苹果并不是没有这种想法，那个迟迟没能推出的 AI Siri，其实就有着类似的构想，可以读取用户的文本和应用窗口，可以跨应用进行检索和处理。

对比 iPhone 和智能手机，AI 应用的主流使用场景其实还是在于桌面端，这也是为什么 Mac 能成为今年最热门的 AI 硬件，但苹果却没有继续在 macOS 的系统层面，赋予 Mac 足够分量的原生 AI 能力。

隔壁的 Windows 阵营在这方面要激进不少，系统层面有「Recall」和 「Copilot」这样的 AI 功能入口，联想和荣耀这样的 OEM 厂商，甚至为产品准备了开箱即用的龙虾应用，砍掉了门槛，并因为和本地深度集成，能节省不少 Token。

微软自己也已经坐不住了，据悉正在将原本只能你问我答的 Copilot，改造成一个 24/7 在线的数字分身，实现类龙虾能力。

对比 OpenAI、Anthropic 或者 Google，说实话我更愿意将这些敏感的数据，交给在隐私保护方面更上心的苹果。

更深一步，macOS 最缺少的不是 AI 应用，而是 AI 时代的「基建」。Mac 已经准备好了 AI 大有可为的土壤，但 macOS 还没能成为一个真正意义上的「AI 系统」。

苹果不仅可以做自己的 AI 智能体能力，也需要把模型、权限、上下文、自动化和跨应用任务重新梳理，让系统成为 AI 工作流的原生中介，成为一个掌控所有 AI 的「任务集散中心」。

就像是智能体运行所需要的「个人知识库」，现在我们用文件夹也可以搭建，但它还不够好用。

苹果完全可以自己承接这个环节，用户靠 Mac 自带的工具搭建、生成一个「知识库」文件，它可以和 Apple ID 绑定，利用 iCloud 流转，这样不管用哪一家的智能体服务，都能快速调用自己的知识库，不用从头开始配置，同时还能保证自己的内容被苹果的隐私政策保护。

并且，这些配置的模块都能整合进入 Apple 的订阅系统之中，iClaw 和 Token 也能成为苹果在 AI 时代提供的增值服务。

实际上，苹果已经开始了这样的进程。在 macOS 26.1 中，苹果集成了「模型上下文协议」，一个面向不同 AI 的通用开放标准，Agent 可以通过这个协议，访问用户的个人数据；苹果的基础模型框架，让 macOS 开发者可以调用系统内置的基础模型，零网络延迟，零 API 费用，数据不离开设备。

作为计算机图形系统的祖师爷，macOS 在过去的数十年间都是围绕「应用」构建的桌面系统。

在接下来十年，应用和图形界面还会是人机交互的主流，因此 macOS 27 要将界面风格修缮得更好，当然非常重要。

但未来五十年甚至更远，AI 都会成为无可避免的主旋律，macOS 不可避免会被进一步改造，成为一个围绕「任务」运转的 AIOS。

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

今年的 iOS 27，将会 AI 味浓浓。

彭博社报道，苹果准备在今年的 WWDC 开发者大会上推出一套全新的 AI 修图工具，将会集成在 iPhone、iPad 和 Mac 的照片应用中。

沉寂了一年的 Apple 智能，将随着 iOS 27 的推出，再次回到聚光灯下。

两年前，苹果还公开表示不做 AI 修图功能，在竞争对手的步步紧逼之下，终于还是忍不住跟进了。

iOS 27：AI 无处不在

在 iOS 18 推出的 Apple Intelligence 工具集，苹果就已经允许用户利用 AI 简单消除照片中的物体，属于当下智能手机的标配功能。

苹果的对手已经走得更远。像是把「AI 修图」作为标志性功能的 Google，已经实现给人物更换完美表情、把人物加入合照，甚至重构整个画面背景的能力，整个 Android 阵营都在发力类似的功能。

在 iOS/iPadOS/macOS 27 中，苹果将在「照片」App 的编辑界面中，增加一个全新的「Apple Intelligence Tools」（Apple 智能工具集）模块，包含以下三个功能：

• Extend（扩展），就是 AI 扩图的功能，允许用户在原始画面之外额外生成图像内容，比如拍摄一张旅游景点的地标图，然后用这个工具来填充周围的景色，用户可以自行控制扩图的范围和位置。
• Enhance（增强），利用 AI 自动修图，有点像不能自定义的「豆包修图」。
• Reframe（重构），主要运用于苹果的空间照片，允许用户在拍摄后改变视角，比如一张汽车照片可以从正面视角调整为侧面视角。这个功能将充分利用空间照片来自多个摄像头的结构数据。

不过，根据内部测试的员工透露，这些功能的开发并不算顺利，效果更复杂的「重构」和「扩展」不稳定，苹果很可能会推迟或砍掉这些功能的发布。

包括这个新的 AI 修图功能在内，iOS 27 系统的更新将会沿着「优化」和「AI」两个主旋律进行。

此前爱范儿已经多次报道，由于 iOS 26 引入了「液态玻璃」的全新设计语言，系统稳定性有明显下降，因此 iOS 27 将会聚焦在系统稳定性优化上，不仅要修复目前 iOS 26 的大量 Bug，还会提升设备的续航和性能表现，并持续修改液态玻璃的视觉效果。

其余的功能更新，则会集中在「AI」上。首先，苹果正在努力将 2 年前画饼的 AI Siri 正式实装 iOS 27，这也是 Apple 智能体验和未来苹果 AI 硬件战略的核心体验部分。

虽然已经「潜心打磨」两年，今年年初有内部人员向彭博社透露，AI Siri 的一些杀手级功能，例如语音控制 Siri 操作应用，测试结果并不理想。

这意味着，即使我们能在 iOS 27 见到 AI Siri 庐山真面目，它也大概率会是一个「技术预览版」，并且需要等待后续更新补充完整功能。

旧饼还没兑现，iOS 27 选择继续加码 AI 新功能。

苹果打算进一步将 Siri 改造为类似 ChatGPT 和 Google Gemini 那样的聊天机器人，届时 Siri 会有一个独立应用，用来对话和存储聊天记录。

苹果还计划在邮件、日历和 Safari 浏览器等第一方应用中，引入新的 Siri 引擎，实现更强的搜索和数据管理能力。

除此之外，苹果正在酝酿一个 AI 搜索引擎， 允许用户从网络搜索信息，生成综合的报告和信息列表，以及网页链接，作为 Safari 和 Spotlight 网络搜索。

在健康领域，苹果将结合 AI 推出「Health+」的订阅服务，利用 AI 智能体，对用户的身体数据进行个性化分析，并针对性推送真人医生录制的建议。

比起两年前那场 WWDC，iOS 27 这一大批 AI 功能，比目前的 Apple 智能还要更丰富不少。

FOBO 的风，还是吹到了库比提诺

2025 年 1 月， 苹果的软件主管 Craig Federighi 和营销高级副总裁 Greg Joswiak 接受了《华尔街日报》的专访，谈到了对 AI 的看法。

其中 Federighi 特别提到了「AI 修图」，解释为什么苹果只推出「消除」，而不是如同三星和 Google 一样做大量的功能：

对我们来说，重要的是帮助人们传播准确的信息，而不是虚构的「幻想」。

苹果公司内部曾经针对「AI 修图」的尺度进行了长时间讨论，考虑到用户的高需求，苹果公司愿意迈出「小小的一步」，于是在 iOS 18 之中推出了「AI 消除」的功能。

而像是「图乐园」这种 AI 生图功能，苹果也做出了严格的限制，只能用于创作卡通图案，避免生成逼真的图像造成误导。

某种程度上，苹果的坚持已经开始松动，iOS 27 这个全新的「AI 扩图」功能，让 Apple 智能进一步介入照片的真实性。

回望两年前的那场 WWDC，Apple 智能以一个非常温和的形象问世，没有想象中的 Apple-GPT，苹果的很多尝试都显得谨小慎微，不具备改天换地的野心。

但 AI 产品的代际变化速度极快。别说两年前，两个月前都没人觉得 ChatGPT 是一个好用的文生图机器人，现在打开社交媒体 GPT Image 2 的作品已经铺天盖地。

两年没动弹过的 Apple 智能，自然「遥遥落后」。

作为终端厂商的苹果，原本拥有一个得天独厚的优势，能够一夜让自己的 AI 产品面向全球十亿用户推出。

只是，对于用户来说，Apple 智能不仅不算好用，更致命的是，它提供的价值，和用户的需求，有很大程度的错位，导致用户并不想用。

FOBO（Fear Of Becoming Obsolete，害怕被淘汰）的阴影，终究还是笼罩了苹果。

过去， 苹果可以决定什么功能值得出现；如今，它也必须回应用户已经习惯拥有什么，行业在发力什么。iOS 27 上这些曾被苹果否决的 AI 功能，本质上都是一次迟到的补课。

Siri 版 GPT 要做，AI 搜索引擎要做，系统应用也全部 AI 化，现在苹果也盯上了 AI 照片编辑，一个其他手机品牌很喜欢演示的功能。

苹果能不能把这些功能做好，又是另一个问题。

即使已经发布 2 年，Apple 智能的照片「消除」效果依旧不如人意，横向对比 Android 阵营显得更显落后，经常会出现消除不彻底、扭曲图像的问题。

全新「扩展」和「重构」功能则更复杂，内部已经反馈稳定性不佳——其实，我相信对于更多用户来说，会更希望苹果能把更实用的「消除」功能进一步完善好。

并且，AI 修图一直以来都争议缠身，特别是前两年的 Google Pixel，可以在一张真实照片上加入任何元素，实现以假乱真的效果，就引发了国外媒体对于「真实」和「伪造」的大讨论。

苹果会尽量规避这种风险，目前看来，这些新功能的自由度相当有限，用户不能自定义修改的方向和指令。

面对行业趋势和用户需求，苹果也不得不松动和更改曾经的价值取向，现在的他们，其实还不知道自己要做什么样的 AI。

但这不仅是苹果的困惑，其实也是笼罩整个行业的迷思，最富含 AI 的 Google Pixel，也并非是我们期待的那台 AI 手机。

既然暂时难以重新扮演行业的引领者，那么在 AI 这场竞赛中持续调整步伐的苹果，至少还能先通过跟随，确保自己依然留在牌桌之上。

但我仍然期待，今年的六月，苹果能为我们带来惊喜。

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

凌晨三点，楼里只剩空调低鸣。林屿坐在工位前，盯着 SwiftUI 里的 List，像盯着一个多年的老朋友。这个老朋友不坏，甚至称得上可靠。可今天，他忽然觉得不对劲了。页面能跑，交互也顺，但那层说不清的“高级感”，总像隔着一层雾，伸手能碰到，握住却没有。问题出在哪？他顺着代码往下摸，摸到最后，才发现真正的悬念从来不在样式，而在工具选错了场子。

🧭 在 SwiftUI 中构建 List 的替代方案

每当你打算在 SwiftUI 里做一个可滚动页面时，第一反应往往是用 List。这很正常。List 名声在外，又是系统组件，出手就带着几分正统气息。

但话说回来，它并不总是最合适的选择。

List 最擅长的，是展示那种整齐划一的统一数据。比如邮箱列表、待办事项、联系人，这类内容结构规整，节奏统一，List 处理起来得心应手。

可如果不是这种场景，画风就变了。
对于其他更灵活、更讲究布局和视觉层次的页面，ScrollView 搭配 lazy stack，几乎总是更好的方案。

这篇文章要讲的，就是如何在 SwiftUI 中构建一个自定义的可滚动容器，让我们对 look and feel 拥有真正精细、可控的掌握力。

---

⚙️ 先把底牌摊开：ScrollView 这几年，已经不是昨日黄花

先说一句实在话。

过去几年里，SwiftUI 对 ScrollView + lazy stacks 的性能做了相当大的改进。它早已不是那个“能用，但心里发毛”的角色。今天的它，已经足够稳，足够快，也足够灵活。

所以，如果你展示的不是那种几十万条统一数据，比如邮箱、待办清单这种超大规模列表，那么：

ScrollView is a way to go.

这句话轻描淡写，实际上意味深长。

它的意思不是 “List 不行”，而是：
如果你的页面不依赖大规模统一数据的复用机制，那你就没必要把自己绑死在 List 上。

工具有长处，也有边界。看不见边界，迟早吃亏。

---

🫀 CardioBot 的现状：已经不错，但还不够狠

这是林屿自己独立开发的 CardioBot app。

上面有 4 张截图：前两张是当前版本，后两张是林屿想达到的效果。

现在这款 app 使用的是标准 List。而且说句公道话，它现在的界面观感并不差，作者自己也很喜欢它目前的 look and feel。

但人一旦开始较真，就回不了头。

林屿决定重新审视自己的 UI。目标并不激进，不是要把界面改得面目全非，而是要做到两件事：

• 保留 iPhone 用户熟悉、直观、可识别的感觉
• 让 UI 再精致一些，再讲究一些，再“骚”一点，但绝不轻浮

这类优化最难。它不是“重做”，而是“进一寸”。可往往，真正拉开差距的，就是这一寸。

---

🧱 为什么这里的 List 已经不再对味了

CardioBot 展示的是不同类型的健康指标。问题在于，这些内容不是统一数据集，而是一组风格不同、职责不同的内容块。

林屿用了多种 card 类型，比如：

• HeroCard
• TintedCard
• RegularCard

看到这里，症结就露出来了。

如果数据并不统一，那么使用 List 去做 cell recycling，其实就没多大意义。List 的一身本事，主要是为海量、统一、标准化的数据而生。可这里是一桌散席，不是整齐列队。

林屿当然也试过继续依赖 List。
他可以通过一些 list-specific view modifiers 做出接近目标的样子，比如：

• listRowBackground
• listItemTint
• listRowInsets

它们在 List 内部确实很好使，像一把趁手的短刀。

可惜，刀再锋利，也有出鞘范围。
这些 list-specific view modifiers 一旦离开 List view，立刻失灵。也就是说，这些能力是 List 私有的，不可外借。

结果就是：
你想在 List 之外维持相同风格，就必须额外补样式。补来补去，补成了拆东墙补西墙，最后不是代码发虚，就是视觉跑偏。

这就不是“能不能做”的问题了，而是“做得值不值”。

---

🪄 真正的转机：Container View APIs

幸运的是，SwiftUI 后来引入了 Container View APIs。

这套 API 看起来安安静静，实际上杀伤力很大。它允许我们把 SwiftUI 视图先拆解，改点东西，再重新组合回来。

这意味着什么？

意味着你不再只是“使用容器”，而是可以“制造容器”。
你可以借助 Container View APIs 构建可复用的容器视图，像 List、Form，甚至任何高度自定义的东西。

说穿了，这是一种权限的变化。
以前你在用系统给的积木。
现在你很Happy的开始自己烧砖。

---

📦 第一块积木：ScrollingSurface

由于林屿的 app 中每个页面都采用 ScrollView 加 lazy stack，所以他提炼出了一个统一类型：ScrollingSurface。

public struct ScrollingSurface<Content: View>: View {
    public enum Direction {
        case vertical(HorizontalAlignment)
        case horizontal(VerticalAlignment)
    }

    let direction: Direction
    let spacing: CGFloat?
    let content: Content

    public init(
        _ direction: Direction = .vertical(.leading),
        spacing: CGFloat? = nil,
        @ViewBuilder content: () -> Content
    ) {
        self.spacing = spacing
        self.direction = direction
        self.content = content()
    }

    public var body: some View {
        switch direction {
        case .horizontal(let alignment):
            ScrollView(.horizontal) {
                LazyHStack(alignment: alignment, spacing: spacing) {
                    content
                }
                .scrollTargetLayout() // 告诉滚动系统：这里是目标布局区域
                .padding()
            }
        case .vertical(let alignment):
            ScrollView(.vertical) {
                LazyVStack(alignment: alignment, spacing: spacing) {
                    content
                }
                .scrollTargetLayout() // 垂直方向同理
                .padding()
            }
        }
    }
}

他的意思很直接：
ScrollingSurface 本质上就是对 ScrollView 和 LazyVStack / LazyHStack 的一个简单包装。根据方向不同，切换成垂直或水平滚动容器。

但别小看这个“简单”。

为什么它值得单独抽出来？

因为它做了三件很重要的事：

• 统一了页面根结构
• 统一了滚动方向的表达方式
• 统一了 spacing 和 padding 的布局语义

林屿会把 ScrollingSurface 作为 app 每个页面的 root view。
这不是偷懒，这是定规矩。

规矩一旦立住，后面的样式和结构才能不乱套。

---

🃏 第二块核心积木：DividedCard

接下来，UI 里的关键原语出现了：DividedCard。

它最重要的地方，在于使用了 Group(subviews:)，这是 SwiftUI Container View API 的一部分。

public struct DividedCard<Content: View>: View {
    let content: Content

    public init(@ViewBuilder content: () -> Content) {
        self.content = content()
    }

    public var body: some View {
        Group(subviews: content) { subviews in
            if !subviews.isEmpty {
                VStack(alignment: .leading) {
                    ForEach(subviews) { subview in
                        subview

                        if subviews.last?.id != subview.id {
                            Divider()
                                .padding(.vertical, 8) // 在每个子视图之间插入分隔线
                        }
                    }
                }
                .padding()
                .frame(maxWidth: .infinity, alignment: .topLeading)
                .background(
                    .regularMaterial,
                    in: RoundedRectangle(cornerRadius: 32) // 给整体包上圆角卡片背景
                )
            }
        }
    }
}

Group(subviews:) 到底妙在哪？

这招很关键。
它允许我们把通过 @ViewBuilder 传进来的视图拆成一个个子视图。

换句话说，你不再只能把一整坨内容当黑盒来用，而是能看到里面每个子项，并逐个处理它们。

林屿在 DividedCard 里干的事情很漂亮：

1. 先把内容拆开
2. 遍历所有 subviews
3. 在每个子视图后面加上 Divider，但最后一个不加
4. 最后把整个结构包进一个带圆角的材质背景里

结果就是：
一组原本只是“连续排列的内容”，立刻拥有了卡片感、分组感和边界感。

这一手为什么重要？

因为很多产品界面都存在这样的结构：

• 一张卡片里放多个入口
• 每个入口既独立，又需要视觉连续
• 中间要有分隔，但不能显得生硬

以前你可能要在每个地方重复写 Divider、padding、background、cornerRadius`，写多了就腻，改起来更烦。

现在不同了。
DividedCard 把这套规则提炼成了一个可复用 primitive。

这就是架构的味道：
不是“这页看着对”，而是“以后都能对”。

---

🧩 第三块积木：SectionedSurface

另一个很有意思的 UI primitive，是 SectionedSurface。

public struct SectionedSurface<Content: View>: View {
    let content: Content

    public init(@ViewBuilder content: () -> Content) {
        self.content = content()
    }

    public var body: some View {
        ForEach(sections: content) { section in
            if !section.content.isEmpty {
                section.header.padding(.top) // 给 section 的 header 增加顶部间距
                section.content
                section.footer
            }
        }
    }
}

它使用了 ForEach(sections:)，这个能力可以从传入的视图中提取所有的 Section，然后做统一处理。

林屿这里做了两件事：

• 过滤掉没有内容的 section
• 给 section header 增加一些顶部间距

这看着朴素，实际上很实用。

因为在真实业务里，section 常常是动态的。
某块有数据，就该显示；没数据，就该消失。
如果每个页面都自己处理一遍这些逻辑，迟早会写成一锅粥。

而 SectionedSurface 把这类规则直接吸收到了容器层。
页面只负责描述内容，容器负责决定组织方式。

这就叫分寸。
代码里有分寸，界面就不会失态。

---

➡️ 离开 List 后，NavigationLink 的箭头去哪了？

很多人一旦不用 List，很快就会发现少了点什么。
没错，就是 NavigationLink 右侧那个熟悉的小箭头，也就是 chevron。

在 List 中，它会自动出现在 trailing edge，系统帮你安排得明明白白。可一旦离开 List，这个默认样式就没了。

林屿的办法很干脆：写一个自定义 ButtonStyle。

public struct NavigationButtonStyle: ButtonStyle {
    public func makeBody(configuration: Configuration) -> some View {
        HStack {
            configuration.label
                .opacity(configuration.isPressed ? 0.7 : 1) // 按下时微微变淡，增加反馈感
            Spacer()
            Image(systemName: "chevron.right")
                .foregroundStyle(.tertiary) // 补回 List 风格的右侧箭头
        }
        .contentShape(.rect) // 扩大点击区域，让整行都可点
    }
}

extension ButtonStyle where Self == NavigationButtonStyle {
    public static var navigation: Self { .init() }
}

这一招的好处在于，它不是临时补救，而是顺势把“导航型按钮”的风格单独抽了出来。

以后只要写：

.buttonStyle(.navigation)

整页涉及导航的按钮，就能统一表现。

这才像回事。
高手不是把洞补上，高手是顺手把墙也砌直。

---

🏗️ 实战拼装：SummaryView

下面这段代码，展示了前面这些新原语在 app 中的实际用法。

public struct SummaryView: View {
    let summary: SummaryStore
    
    public var body: some View {
        ScrollingSurface {
            SectionedSurface {
                coachSection
                activitySection
                recoverySection
                vitalsSection
                heartRateSection
                alcoholicBeveragesSection
            }
        }
        .buttonStyle(.navigation) // 统一套用导航按钮样式
    }
    
    @ViewBuilder private var activitySection: some View {
        Section {
            if !summary.metrics.workouts.isEmpty {
                DividedCard {
                    ForEach(summary.metrics.workouts, id: \.workout.uuid) { snapshot in
                        NavigationLink {
                            WorkoutDetailsView(snapshot: snapshot)
                        } label: {
                            WorkoutView(snapshot: snapshot)
                        }
                    }
                }
            }
        } header: {
            SectionHeader(
                .horizontal,
                title: Text("activitySection"),
                systemImage: "figure.run"
            )
            .tint(.orange)
        }
    }
}

这一段真正漂亮的地方在哪？

表面上看，它的使用方式和 List API 非常像：

• 有 Section
• 有 NavigationLink
• 有 header
• 有内容分组

但底层已经换了天地。

林屿通过：

• ScrollingSurface
• DividedCard
• SectionedSurface
• NavigationButtonStyle

重新拼出了类似 List 的使用体验，同时拿回了对 look and feel 的精准控制。

更妙的是，如果某个页面压根不需要 sections，只要把 SectionedSurface 去掉即可，其余 primitive 仍然能继续复用。

这就说明它们不是页面特供，而是真正的可复用 building blocks。

到了这一步，已经不是“替代 List”那么简单了。
这是在搭自己的界面语言。

---

真相大白：弃用 List 非叛逆，懂了取舍是清醒

最后，林屿把话说得很准。

在 SwiftUI 里替换 List，并不是要放弃一个强大的组件。它真正要表达的是：

不是背叛 List，而是为场景选择正确的工具。

如果你面对的是大型、统一的数据集，List 依旧是极好的选择，毫无问题。

但当你的 UI 需要更细致的结构、更独特的样式、更符合产品自身 design language 的表达时，现代 SwiftUI 已经给了我们足够的自由。

借助 ScrollView、lazy stacks 和 Container View APIs，我们不只是可以重建 List 的能力，某些时候甚至能够超越它。

像 ScrollingSurface、DividedCard、SectionedSurface 这样的自定义 primitive，证明了一件事：

真正成熟的 SwiftUI 代码，不只是把视图摆出来，而是把可复用的规则提炼出来。

性能、清晰度、设计语言，三者并行不悖。
这才是正路。

---

🌒 尾声：他最终没有推翻 List，只是看透了它

天快亮的时候，林屿合上电脑，办公室的灯光仍旧冷，心里却亮了。

他没有把 List 当成敌人。
也没有为了“自定义”而自定义。

他只是终于明白：
组件从来不是信仰，它只是工具。

该用 List 的时候，别拧巴；
该用 ScrollView 和自定义容器的时候，也别手软。

很多人写 UI，写到最后，写成了对系统组件的依赖。
可真正厉害的人，写到最后，会慢慢长出自己的容器、自己的规则、自己的语言。

那一刻，所谓 List replacement，其实已经不重要了。
重要的是，他终于从“会用组件”，走到了“会造秩序”。

而这，才是这篇文章最狠的一刀。

这里是后厂村阴影中最神秘的“全栈侦探事务所”。当你的 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月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审核人员进行了一场视频会议特此记录。

背景

继 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审核人员进行了一场视频会议特此记录。