App Clip离落地有多远？

一：前言

之前也陆陆续续看过一些介绍App Clip的技术文章，发现这些文章几乎千篇一律，差不多都是「苹果技术文档」和「WWDC视频截图」的拼装，以及「WWDC视频讲解」和「网上同类文章」的复述，却很少谈及App Clip真正落地的业务场景和涉及的技术问题。

App Clip发布后，我开始负责App Clip的技术调研工作，也是沾团队的光，约到了一个App Clip lab，感受了一把白天看WWDC，晚上和WWDC讲解人一对一交流的体验，虽然我们团队最后决定先暂停App Clip的开发，但是在调研App Clip的过程中，也确实发现了很多值得思考之处。

先说一个结论：不要因为看了WWDC和一些技术文章，就对App Clip有过分美好的幻想，至少从目前来看，App Clip的坑还很多。

二：业务原因

2.1 业务场景少

线下支付

看过WWDC视频的小伙伴们可能已经察觉到了，视频中介绍的场景90%以上都是线下支付的场景，不知道苹果的本意是不是希望通过App Clip去抢占o2o市场，虽然说的是「不用安装商家App」即可通过App Clip享受便捷服务，快速完成下单。可在中国，用户绝大部分的时候本来就不需要下载商家App，难道小程序不香嘛？况且就算真的有这种需求，目前能够满足的也仅仅是iOS 14系统以上的iOS用户。所以这种线下支付的场景，至少在目前看来，App Clip甚至称不上现有方案的一个有效替代方案。

线上拉新

既然线下支付推进困难重重，那肯定很多人会把目光重新看向线上场景。因为App Clip具备「及时可用」的特点，让用户不用下载完整的App即可享受到App的部分功能，那不妨就把App Clip做为一个拉新的入口，把Clip当做「试用装」吸引用户，等用户习惯了，再引导用户下载App。理想虽然很美好，可现实中怎么把「试用装」交到用户手中呢？我们知道，App Clip的调用场景目前主要就5种，二维码、Safari Smart Banner、NFC、Map和Message。

其中NFC需要物理介质，Map需要实体店，它们对于纯线上的App来说很难找到应用的场景。

Message更不用说了，首先国人对Message聊天的需求本来就不大，也总不能群发带Clip的短信给用户吧？

对二维码，我们是抱有美好的期待的，希望用户通过第三方SDK将二维码分享给好友，然后好友通过二维码调起App Clip，逻辑满分。但尴尬的是，App Clip的二维码，只能通过「系统相机」才能调起。我相信绝大部分的人看到二维码，第一反应都是拿微信去扫一扫，想要培养用户使用「系统相机」扫码的习惯恐怕很难。

那最后剩下的就是Safari这种方式了，这就需要我们想方设法的让用户在Safari里打开这个链接，注意，必须是Safari里打开，在第三方App里的WebView是没有办法显示Smart Banner的，自然也就没办法调起App Clip。

2.2 操作路径长

即便Safari貌似是纯线上App最适用的场景了，但是这种方式还存在一个问题，那就是用户的操作路径过长。以第三方分享为例，用户在第三方App接受到好友分享的链接后，打开Clip最短的操作路径可能如下：

• 打开好友分享的链接，进入到内容页；
• 点击更多按钮，选择在Safari中打开；
• 点击Safari中Smart Banner上的Open按钮，调起Clip Card；
• 点击Clip Card上的Open按钮，调起App Clip；
• 在引导用户通过Safari打开这步估计就足够劝退大部分的用户了…

三：技术原因

即便我们不考虑业务场景，单纯从技术角度看，实现一个App Clip本身恐怕也不会是一个轻松的过程。

代码拆分

苹果希望App Clip和App提供一致的体验，刚看完WWDC的视频，一开始真的会给人一种实现一个App Clip 「So Easy」的感觉，只要复用原有的工程，随便勾勾选选，把文件加到Clip的Target下，一个精美小巧的App Clip就呈现在眼前了。

可事实上呢？通常我们需要尽可能复用现有的业务来开发Clip，可除非你所在的项目业务足够简单，或者组件化做的足够彻底，否则你会发现摘Clip的代码是一件几乎无法实现的事情，很可能需要先做大量的技术重构。当然你也可以将原有代码复制出来，重写一份，可是这样下来，为了保持与完整App的功能一致性，就需要付出维护两套代码的时间成本。

包大小限制

10M是App Clip包大小的上限，对于现在动辄一二百M的应用来说，如何用10M来完成目标功能，也是一个不小的挑战。一方面还是上面提到的代码拆分的问题，如果组件化时，基础层划分的颗粒度不够细致，很可能导致上层业务依赖的基础组件过多，从而影响包大小。另一方面，如果App Clip的功能一直是增量的，那必然会导致未来的某一天会超过10M的限制，为避免这一问题，还需要根据新增功能对包大小的影响，配合产品完成现有业务功能的调整。

后台活动

App Clip不支持后台处理活动，这里的后台活动不单指beginBackgroundTaskWithExpirationHandler:这种后台任务，经过实际测试，甚至连「正常的网络请求」以及「NSData转 NSString」等操作，在后台执行都是不是完全可靠的，再结合视频里说的：

In addition, app Clip can’t perform background activity, such as doing background networking with URLSession or maintaining Bluetooth connections when the app clip isn’t in use.

对于不能执行的background activity目前包括什么，咱无从得知，但从安全的角度看，尽量不在后台搞事情，肯定是第一原则，只是不知道把后台的监听都去掉，你的项目是否还能work~

唯一标识

如果想把App Clip当做拉新的手段，那可能就会涉及到一个问题：如果识别出当前App用户曾是App Clip用户？

我们知道如果用户手机上存在App Clip的情况下，又下载了对应的App，是可以进行数据迁移的。那如果用户的Clip因为一段时间未使用被系统自动删除了，此后用户又下载了App，该怎么设置用户的唯一标识呢？

要知道Clip在被系统删除时，也会清空其存储在Keychain中的数据，至于IDFA，Shared Keychain那就更别想了，Clip压根不开放这个能力。当然肯定还是有一些其他方式能够对用户进行唯一标识，比如有些防作弊的SDK，就可以标识唯一的设备ID，这就看大家各显神通了。当然，如果不关心这种case的话就另说了。

第三方App调起

App Clip可以通过Url Scheme或者Universal Link调起第三方App，但是第三方App却不能通过Url Scheme和Universal Link调起App Clip，说白了就是能调出去但是回不来。第三方登录、第三方分享、第三方支付可能都会受到影响。

不支持企业包

企业证书是没法配置App Clip的，如果项目是使用同一个工程，通过不同的configuration切换企业版和正式版，可能还需要注意一个额外的问题，App Clip是通过Build Phases中的Embed App Clip集成到主Target中的，而Build Phases又没办法区分configuration，如果想区分版本去添加Embed App Clip，就只能打企业包时，单独去修改Project文件了。

Pods

可能目前CocoaPods对App Clip的支持还不够完善，写Demo时发现如果App Clip需要依赖Pods的话，pod install后，在Build Phases中是不会自动生成Embed Pods Frameworks的，这就会导致编译时报image not found的错误，目前解决的办法就是手动添加一下Embed Pods Frameworks。

四：结语

当然，对于App Clip的最终落地来说，技术原因终归是次要的，最关键还要看如何找到适合自己产品的业务场景。在苹果线上培训的时候，认识了一个团队的开发，说他们想用App Clip做AR，当时我就觉得这个想法还挺好的。可能对于很多产品来说没有这么新颖的玩法，其实倒也不必太在意，对于苹果来说他们也很清楚目前的现状，据他们自己说也在和美国总部沟通，当然结果如何，咱不得而知，但毕竟留个念想嘛，万一未来App Clip的入口放开了呢~