App Clips是什么？
官方对其的定义是——
App clips are a great way for users to quickly access and experience
what your app has to offer. An app clip is a small part of your app
that’s discoverable at the moment it’s needed. App clips are fast and
lightweight so a user can open them quickly.应用片段让用户可以快速体验应用。一个应用片段是应用的一小部分，可以在需要的时候被发现。应用片段快速而轻巧，因此用户可以快速打开它们。
个人理解：「一个无需下载应用，就能使用 app 的功能。」和微信小程序有点相似，也被一部分人称为「苹果小程序」。
App Clips从哪里来？
App Clips 的起源，要从 2016 年 6 月说起。
2016 年 6 月，WWDC2016 发布了 iOS10，重磅介绍了升级后的 iMessage，其中，最值得一提的就是 iMessage 内的应用。通过这个特性，用户可以在 iMessage 聊天窗口里玩游戏，效果和后来的微信群聊里的小游戏卡片一样（只是要下载）。
iMessage 的这个新功能时间上比小游戏早了近一年。
iMessage app 通过社交关系解决了服务发现的问题，这也是 App Clips 的核心使命。
从技术发展角度来看，App Clips 就是 iMessage app 的升级版本。它在聊天窗口发送能力的基础之上，增加了 NFC 近场打开、扫码打开、网页关联打开、地图 POI 打开等服务发现路径，基本上涵盖了实际生活中所有需要服务的场景。
产品定位：
1. 用完即走
苹果对 Clip 的使用场景非常明确：在一个特定的情境里，用户可以快速的使用 app 的核心服务。
坦率的说，很难说 Clip 的理念是苹果原创的，在产品的定位上和微信小程序如出一辙。尤其是微信小程序在国内已经完全普及了，微信小程序初始发布的时候也被苹果加了多条限制。其中一条就是小程序不能有虚拟商品支付功能。现在回头看苹果自己的 Clip 可以完美支持 apple pay，很难说苹果没有私心。
2. 触手可及
Clip 使用一段 URL 标识自己，格式遵从 universal link。因为苹果对 Clip 的使用场景非常明确，所以在 Clip 的调起方式做了严格限制。Clip 的调用只能是用户主动要发起才能访问，所以不存在用户在某个 app 里不小心点了一个按钮，就跳转下载了 Clip。
Clip 的发起入口有以下几种：
- NFC
- 二维码
- Safari 中关联了 Clip 的网页
- 苹果消息应用
- Siri 附近建议和苹果地图
NFC 和二维码的入口很容易理解，必须用户主动拿出手机靠近 NFC、打开相机扫描。苹果专属的 Clip 码生成工具在年底才会开放。
Safari 中发起和之前的 universal link 类似，在网站配置了关联的 Clip 信息后，会有一个 banner 提示打开应用。
因为 Clip 提交 app store 审核的信息里也会配置好相关的 url，因此如果在 message 里发了 clip 的链接，操作系统也会在应用里生成一个 Clip 的卡片，用户如果需要可以主动点击。
Siri 附近建议和苹果地图（在 connect 中可以配置 clip 的地理位置）。场景和前面的二维码类似，如果我在地图上看到一个商家，商家有提供服务的 Clip，我可以在地图或者 Siri 建议里直接打开 Clip。
再次总结一下 Clip 的入口限制：只能是用户主动发起才能访问。虽然 Clip 的入口是一段 universal link，在代码里的处理方式也和 universal link 一致，但是为了 Clip 不被滥用，Clip 的调起只能是操作系统调起。App 没有能力主动调起一个 Clip 程序。
3. 无需安装、卸载
因为 Clip 的大小被限制在了 10MB 以下，在当下的网络状态下，可以实现快速的打开。为了给用户使用非常轻松的感觉，在 UI 上不会体现“安装”这样的字眼，而是直接“打开”。预期的场景下用户打开 Clip 和打开一个网页类似。因此在用户的视角里就不存在软件的安装、卸载。
Clip 的生命周期由操作系统全权接管。如果 Clip 用户一段时间后没有使用，操作系统就会自动清除掉 Clip，Clip 里存储的数据也会被一并清除。因此虽然 Clip 提供了存储的能力，但是程序不应该依赖存储的数据，只能把存储当做 cache 来使用，操作系统可能自动清除缓存的数据。
横向比较：PWA、Instant Apps、微信小程序
Instant Apps「谷歌小程序」
18 年正式发布的 Android Instant apps 和 Clip 在技术上是最接近的。Instant apps 中文被翻成“免安装应用”，在体验上也是希望用户能够最低成本的使用上 app，让用户感受不到安装这个步骤。Instant apps 也可以通过 url 标识（deep link），如果在 chrome 里搜索到应用的网站，chrome 如果识别到域名下有关联应用，可以直接“打开”。消息中的链接也可以被识别。只是 Instant apps 发布的早，国外用户也没有使用二维码的习惯，所以入口上不支持二维码、NFC。
两者的根本区别还是在定位上，Instant apps 提出的场景是提供一个 app 的试用版。因此场景是你已经到了 app 的下载页面，这个时候如果一个 app 几百兆你可能就放弃下载了，但是有一个极简的试用版，就会提高你使用 app 的可能。这个场景在游戏 app 里尤其明显，一方面高质量的游戏 app 体积比较大。另一方面，如果是一个付费下载的应用，有一个免费的试用版，也可以增加用户的下载可能。在苹果生态里很多应用会提供一个受限的免费 lite 版本也是一样的需求。
但是 Instant apps 在国内没有产生任何影响。因为政策的原因，Google Play 不支持在国内市场使用。国内的安卓应用市场也是鱼龙混杂，对于 Instant apps 也估计也没有统一支持。另外国内的安卓生态也和欧美地区区别比较大，早期安卓市场上收费的应用很少，对于用户而言需要试用免费 app 的场景很少。另外大厂也可能会推出专门的急速版应用，安装后利用动态化技术下发代码，应用体积也可以控制在 10 MB 以内。
Clip 则是非常明确的面向线下提供服务的场景，在应用能力上可以接入 sign in with apple，apple pay。这样一个全新的用户，可以很快速的使用线下服务并且进行注册、支付。用户体验会好的多。安卓因为国内生态的原因，各个安卓厂商没有统一的新用户可以快速注册的接口，也没有统一的支付接口，很难提供相匹敌的体验。如果开发者针对各个厂商单独开发，那成本上就不是“小程序”了。
Progressive Web App(PWA)
Progressive Web App 是基于 web 的技术。在移动互联网兴起之后，大家的流量都转移到了移动设备上。然而在移动上的 web 体验并不好。于是 W3C 和谷歌就基于浏览器的能力，制定了一套协议，让 web app 可以拥有更多的 native 能力。
PWA 不是特指某一项技术，而是应用了多项技术的 Web App。其核心技术包括 App Manifest、Service
Worker、Web Push。
PWA 相当于把小程序里的代码直接下载到了本地，有了独立的 app 入口。运行的时候基于浏览器的能力。但是对于用户感受和原生 app 一样。
我个人对 PWA 技术很有好感，它的初衷有着初代互联网般的美好。希望底层有一套协议后，用户体验还是没有边界的互联网。然而时代已经变了。PWA 在中国基本上是凉了。
PWA 从出生就带了硬伤，虽然谷歌希望有一套 web 标准可以运行在移动设备上，但是对于苹果的商业策略而言，这并不重要。因此 PWA 的一个协议，从制定出来，再到移动设备（iOS）上支持这个特性，几年就过去了。而且对于移动用户而言，可以拥有一个美好的 web app 并不是他们的痛点。
总结起来 PWA 看着美好，但在落实中遇到了很多现实的问题，技术支持的不好，开发者就更没有动力在这个技术上做软件生态了。
微信小程序
前面提过在产品理念上小程序和 Clip 很相似，甚至说不定 Clip 是受了小程序的启发。在市场上，小程序是 Clip 的真正对手。
小程序基于微信的 app，Clip 基于操作系统，因此在能力上 Clip 有优势。小程序的入口需要先打开微信，而 Clip 可以通过 NFC 靠近直接激活应用。对于开发者而言，Clip 可以直接获得很多原生的能力（比如 push），如果用户喜欢可以关联下载自己的原生应用。在小程序中，微信出于商业原因开发者不能直接跳转到自有 app，小程序的能力也依赖于微信提供的接口。
对于从 Clip 关联主 app 苹果还挺重视的，提供了几个入口展示关联 app。
首先在 Clip 的展示页就会显示：
每次使用 Clip 时也会有一个短暂的浮层展示：
开发者也可以自己通过 SKOverlay 来展示：
不过如果开发者没有自己的独立 app，那么也就只能选择小程序了。小程序发展到现在，场景也比最早提出的线下服务更加多了，反而类似 Instant apps，更像一个轻量级的 app。
考虑到国内很多小程序的厂商都没有自己的独立 app，因此 Clip 对于这部分群体也并没有什么吸引力。不过对于线下服务类，尤其有支付场景的，Clip 在用户体验上会比小程序好一些。
总结，Clip 的业务场景和小程序有一小部分是重叠的，小程序覆盖的场景还是更多一些。两者在大部分时候并不是互斥式的竞争关系，即便在一些场景下 Clip 有技术优势，商家也不会放弃小程序，因为还有很多安卓用户。还是看商家在某些场景里，是否愿意为用户多提供一种更好的交互方式。
实现方式：native 代码、native 框架、native app 一样的分发
在实现上，Clip 和原生的 app 使用一样的方式。在 UI 框架上同时支持 UIKit 和 SwiftUI。Clip 的定位和 watch app、app extension 类似，和 app 在同一个 project 里，是一个单独的 target。只是 Clip 并没有自己的专属 framework（其实有一个，但是主要包含的是一些特色 api），使用的框架和 app 一致，可以认为是一个精简版的原生 App。
Clip 不能单独发布，必须关联一个 app。因此发布的流程和 app 和一样的，在 apple connect 上创建一个版本，和 app 一起提交审核。和 app 在技术上的最大区别只是大小限制在 10MB 以内，因为 Clip 的基础就是希望用户可以最迅速的被用户使用，如果体积大了就失去了产品的根本。
对比原生 app 的技术限制
虽然 Clip 可以直接使用 iOS framework，但是因为 Clip 的使用场景是新用户的初次、简短、当下（in-the-moment experience）的使用，相比原生 app 苹果还是进行了一些限制。
App 不能访问用户的隐私信息：
- 运动和健身数据
- Apple Music 和多媒体文件
- 通讯录、信息、照片、文件等数据
不过为了能够提供给用户更加轻便的体验，通过专门为 Clip 设计了免申请的通知、定位权限。不过也有限制：免申请的通知只在 8 个小时内有效。位置只能获取一次。如果 app 需要重度使用这两类权限就还是和原来一样，可以弹窗申请。
某些高级应用能力也会受限，需要在完整的应用中才能使用：
- 不能请求追踪授权
- 不能进行后台请求任务
- 没在激活状态蓝牙连接会断开
总体而言虽然有一些限制，但是这些限制的出发点是希望开发者关注 Clip 的正确使用场景。对于 Clip 所提倡的使用场景里，苹果提供的能力是完全够用的。
App Clips 开发实战
开发环境要求
Xcode 12
新建一个Target
编写代码直接运行
一些技术细节
- 服务器上：更新apple-app-site-association文件（增加app clip的apps key）
{
"appclips": {
"apps": ["appskey.test.Clip"]
}
}- app clip 的 target 添加 Associated Domain
- 在开发时，可以通过设置 _XCAppClipURL 这个环境变量，并运行 app clip target 来“模拟”通过特定 URL 点击后的情况。
- 可以建立一个共享 targets 的 Asset catalog 来共用图片资源。
- 使用主工程里面的代码，Target MemberShip需要钩上 Clips这个Target。
- 在主工程中做AppClips的特化逻辑
接着使用一下方式就可以区分代码是否是在AppClips生效
#if APPCLIP
// do somethings
#endif- 在 Clip 中申请的授权，在下载完整应用后会被同步到应用中。 通过 App Group Container 来共享 clip 和 app 的数据。
- App Clip card
Apple store connect中需要配置的有：
主图片（png/jpg）、标题、副标题、定位相关、行为（open、view、play） - Clip 的 url 可以配置参数，在 App Store connect 中，可以针对指定的参数配置不一样的标题和图片。比如一家连锁咖啡店，可能不同的店你希望弹出的标题图片是不一样的，可以进行单独的配置。
总结
苹果给定义的 Clip 的关键词是：lightweight、native、fast、focused、in-the-moment experience。
Clip 在特定的线下场景里有着相当好的用户体验。对于已经拥有独立 app 的公司来说，开发一个 clip 应用的成本并不高。对于小程序，Clips 的场景窄的多，两者并不是直接竞争关系。我更愿意看做是特定场景下，对于小程序原生能力不足的一种补充
