时隔三月,如隔三秋。越过层层文档,穿过条条代码,小萝莉终于又和大家见面了!用户朋友们,我想死你们了!当然萝莉来此,并不是来和大家聊春晚的,我们的主题依旧是iOS。
Apple秋季产品发布会刚刚结束,iOS 9 GM版本也正式发布了。新的iPhone设备即将开售,iOS 9系统升级也将会在下周开始陆续进行推送。
在这之前,我们还可以为自己的App兼容适配做点什么,或者说,我们的App真的已经兼容适配好iOS 9系统了吗?
从7月份开始到现在,Apple已发布5个iOS 9的Beta版本,相信开发者在这段时间也已经把iOS 9系统的特性基本了解清楚,也为自己的App进行了一系列兼容适配处理。
但在这里,笔者还是要再次跟大家聊聊iOS 9中两个比较特别的特性及其兼容问题,即:App Transport Security和App Thinning。
App Transport Security
App Transport Security is a feature that improves the security of connections between an app and web services. The feature consists of default connection requirements that conform to best practices for secure connections.
App Transport Security(ATS)是Apple为提高系统及应用安全性而在iOS 9和OS X EI Capitan中引入的新特性,必然,出于安全性的考虑,在新发布的watchOS 2系统中也会适用。
一旦开启ATS后,应用所有的网络请求将会自动转换为HTPPS传输,且采用一系列配置要求来保证数据传输的安全性,包括:
- Transport Layer Security协议版本要求TLS1.2以上
- 服务的Ciphers配置要求支持Forward Secrecy等
- 证书签名算法符合ATS要求等
这些配置项在升级服务器支持HTTPS过程中都需要严格遵守的,否则就会导致你的HTTPS服务在iOS 9系统中连接仍是失效的。
如果你的App的服务也在升级以适配ATS要求,可以使用如下的方式进行校验:
在OS X EI Capitan系统的终端中通过nscurl
命令来诊断检查你的HTTPS服务配置是否满足Apple的ATS要求:
$ nscurl --verbose --ats-diagnostics
https://<your_server_domain>
当然,你也可以参考Apple提供官方指南App Transport Security Technote进行服务的升级配置以满足ATS的要求。
Apple虽然希望开发者可以积极的参与并为系统及应用安全共同努力,但官方仍提供了一些参考配置去禁用ATS功能或降低ATS的安全性要求。
开发者可以在App的Info.plist中添加NSAppTransportSecurity的相关配置,用以禁用ATS或者添加白名单,可用的配置参数如下:
- NSAllowsArbitraryLoads - 设置true即支持所有HTTP请求
- NSExceptionDomains - 添加白名单
- NSExceptionMinimumTLSVersion - 白名单指定域名支持的TLS版本
- NSExceptionRequiresForwardSecrecy - 白名单指定域名是否支持Forward Secrecy
- NSExceptionAllowsInsecureHTTPLoads - 白名单指定域名禁用ATS
- NSThirdPartyExceptionMinimumTLSVersion - 白名单指定第三方服务域名最低支持的TLS版本
- NSThirdPartyExceptionRequiresForwardSecrecy - 白名单指定第三方服务域名是否支持Forward Secrecy
- NSThirdPartyExceptionAllowsInsecureHTTPLoads - 白名单指定第三方域名禁用ATS
举个例子:
- 禁用所有连接使用ATS
在Info.plist中配置禁用ATS:
- 指定域名禁用ATS
在Info.plist中配置App的服务域名mine.test.com支持HTTP:
- 指定域名修改ATS安全要求
在Info.plist中配置第三方服务third.test.com的TLS1.1及禁用Forward Secrecy:
App Thinning
The App Store and operating system optimize the installation of iOS and watchOS apps by tailoring app delivery to the capabilities of the user’s particular device, with minimal footprint. This optimization, called app thinning, lets you create apps that use the most device features, occupy minimum disk space, and accommodate future updates that can be applied by Apple. Faster downloads and more space for other apps and content provides a better user experience.
开发者都知道,当前iOS App的编译打包方式是把适配兼容多个设备的执行文件及资源文件合并一个文件,上传和下载的文件则包含了所有的这些文件,导致占用较多的存储空间。
App Thinning是一个关于节省iOS设备存储空间的功能,它可以让iOS设备在安装、更新及运行App等场景中仅下载所需的资源,减少App的占用空间,从而节省设备的存储空间。
根据Apple官方文档的介绍,App Thinning主要有三个机制:
- Slicing 开发者把App安装包上传到AppStore后,Apple服务会自动对安装包切割为不同的应用变体(App variant),当用户下载安装包时,系统会根据设备型号下载安装对应的单个应用变体。
- On-Demand Resources ORD(随需资源)是指开发者对资源添加标签上传后,系统会根据App运行的情况,动态下载并加载所需资源,而在存储空间不足时,自动删除这类资源。
- Bitcode 开启Bitcode编译后,可以使得开发者上传App时只需上传Intermediate Representation(中间件),而非最终的可执行二进制文件。 在用户下载App之前,AppStore会自动编译中间件,产生设备所需的执行文件供用户下载安装。
其中,Bitcode的机制可以支持动态的进行App Slicing,而对于Apple未来进行硬件升级的措施,此机制可以保证在开发者不重新发布版本的情况下而兼容新的设备。
如果你的应用也准备启用Bitcode编译机制,就需要注意以下几点:
- Xcode 7默认开启Bitcode,如果应用开启Bitcode,那么其集成的其他第三方库也需要是Bitcode编译的包才能真正进行Bitcode编译
- 开启Bitcode编译后,编译产生的.app体积会变大(中间代码,不是用户下载的包),且.dSYM文件不能用来崩溃日志的符号化(用户下载的包是Apple服务重新编译产生的,有产生新的符号文件)
- 通过Archive方式上传AppStore的包,可以在Xcode的Organizer工具中下载对应安装包的新的符号文件
萝莉有话说:
iOS 9的ATS特性和App Thinning特性给开发者带来安全提升和体验上的优化,也是开发者在后续App的兼容适配方便会考虑的事项。
Bugly作为第三方的崩溃捕获服务,在兼容适配的问题上一定不会拖开发者后腿。
支持ATS及Bitcode特性的SDK即将发布。