关于iOS多App共享数据的一些思考

在实际的开发过程中，开发者很多时候会遇到两个或者多个App共享一些数据的需求。比如某公司同时上线了A和B两个App，如果用户手机上已经安装了A并且登录，那么当用户使用B的时候，若可以直接从A获取到登录态（例如一些Token），则会免去登录的步骤。

想要实现上述的功能有很多方式，最直观的莫过于类似接入了微信SDK的App使用微信登录的效果，即使用URL Scheme进行App间的跳转，达到传递数据的目的。这种方式简单直接，但同时有一些缺点：1，用户有感知，不能静默处理；2，当手机上有多个App注册了同样的URL Scheme时，目前的iOS系统是不能确定会跳到哪个App去的，苹果官方对此也没有一个明确的解决方案。因此有可能会出现类似于钓鱼应用的安全性问题。当然，使用URL Scheme来进行App间跳转是目前提供了OAuth登录功能的App，比如微信微博QQ支付宝等等，所采用的首选的方式，因为这些App要为第三方应用服务，而受限制与iOS的机制，同设备上不同开发者名下的App是很难做到除此之外的数据互通的。不过，谷歌系的App使用了另外一种不同的方式，此处先不表，后面会详细介绍。

如果希望在用户无感知的情况下共享数据，那么使用Keychain Sharing是一个好的选择。苹果官方提供了Keychain Sharing的机制，同一个开发者名下的App，如果使用了相同的App ID Prefix（一般是Team ID，由于历史原因也会有别的情况），那么是可以做到Keychain Sharing的。使用Keychain另外会获得安全性的保证，因为保存在Keychain中的数据是加密过的，不再需要开发者手动进行加密处理。与之类似的是NSUserDefaults，满足上述条件的App，在开启了App Groups后同样可以做到数据共享，但保存在NSUserDefaults中的数据实际上是被持久化到plist文件中的，plist文件也就是普通的xml文件而已，苹果并没有对其有安全性方面的处理，所以相对适合保存一些不太敏感的数据，例如用户的一些偏好性设置等等。如果需要共享用户的登录信息，用户名密码或者一些Token的话，使用Keychain会是一个更好的选择。

需要注意的是，NSUserDefaults和Keychain都只适用于小数据量的存储，如果有很大的数据文件需要共享，那么需要使用NSFileManager进行处理。NSFileManager可以根据某个App Group返回对应的目录路径，路径下的文件是可以共享的。如果App想使用文件，或者CoreData，SQLite等共享数据，那么都需要使用这种方式。

面临数据共享问题的还有App和Widget之间。App和Widget在开发过程中是可以共用代码的，但在运行过程中基本相当于两个独立的App，如果需要共享数据的话也要按两个App来进行处理。

在iOS11后，苹果提供了SFAuthenticationSession来处理SSO或者OAuth登陆的场景，通过SFAuthenticationSession可以做到在App和Safari之间共享某个特定域名下的Cookie，从而达到单点登录的效果。这也是一种数据共享的方式，但使用场景比较特殊，一般会用于登录流程中。谷歌系的App已经使用该方式进行登录，读者有兴趣的话可以进一步体验和学习，后续的文章也会详细讲解SFAuthenticationSession的使用和注意事项。