iOS从开发到上架实践-2019

账号申请

要开发iOS App，首先要有账号，账号分三种：

个人版
App Store 版
企业版

上面三种是通俗的叫法。我们选择2. App Store 版。以前3. 企业版，还可以用来内部测试，内部试用，不过现在已经不合适。

申请账号需要用到邓白氏编码，简单理解，就相当于企业的身份证，是在国外的。这个其实是免费的，不过网上有很多提供类似服务的收费公司。
这个过程一般需要20多天，甚至更长。并且如果过程出现问题，苹果是通过邮件沟通的，效率很低，等待浪费的时间很多。

应用申请

首先要确定应用的名字和Bundle Id。这里要注意的是这两个都必须要有唯一性，不能和现有重复。比如，“支付宝”这个名字已经被用掉了，应用的名字就不能取这个。
Bundle Id一般是com.company.product格式，相当于安卓的包名，也要确保唯一。
Bundle Id和应用的名字确定之后，就可以用账号密码登录苹果开发者网站，注册应用，同时生成必要的证书。一般只要Bundle Id和应用的名字不和现有的重名，都能成功。

关于证书

证书主要是开发者用，和普通用户没什么关系。
分为开发证书，和发布证书两类；分别对应开发版(Debug)和发布版(Release)
一些特殊的功能，比如推送，需要额外的证书，也分为开发证书和发布证书两种。实际使用中，推送证书只要一种发布证书就可以了，开发版(Debug)和发布版(Release)都可以用。
当前版本XCode会自动管理证书，只要工程配置正确，使用的时候一般不会有什么大问题。

测试设备

测试设备需要先到苹果开发者网站注册才能用。
注册的方式有两种，一种是提供手机的UUID，可以通过iTunes，iTools等方法查看。一般是一个32位的字符串。然后登陆苹果开发者网站，进行注册。
另外一种方式是通过XCode自动注册，非常方便。一般都可以采用这种方式。
测试设备的总量不能超过100台，并且只能增加，不能删除。所以，对于测试设备的添加需要进行一定的管理和控制。当然，每年账号续费的时候，有一次清空注册设备的机会，要谨慎使用。

开发过程

整个移动开发，可以看成一个“一云多端”的模式。业务逻辑和数据在我们的后台系统中。iOS和Android等终端，是后台和用户交互的媒介。
对于移动开发者来说，后台数据和界面资源是两大制约条件。用户手机上展示的数据，在后台，所以，当需求确定之后，前后端之间约定数据接口，并形成相关文档，就是非常重要的一件事情。我们现在使用的swagger-ui就是一种网页式的接口文档，非常方便，比以前的word文档要好很多。
移动开发依赖的界面资源，由我们的UI同学提供；界面的布局，组件的尺寸，一些按钮的图片等等，都需要UI同学先确定。（尺寸标注，包括颜色值等；图片资源，iOS要提供2倍图，3倍图两套。）
当然，需求文档和交互文档，是开发测试等都需要的，一般由产品或者交互提供。主要内容是：需要实现怎么样的功能，页面跳转逻辑，异常如何处理等等。

兼容性

第一个兼容性是设备类型兼容。是只支持iPhone，还是iPhone和iPad都能用？iPhone和iPad公用一套界面，还是分开用两套界面？

我们现在的做法就是默认的做法：iPhone和iPad都能用，只有一套界面，在iPad上展示的时候，会有一个手机的轮廓。

第二个兼容性是手机的类型，比如iPhone6, iPhone7, iPhoneX等硬件设备。这个主要影响的屏幕尺寸和图片资源的分辨率。iOS要提供2倍图，3倍图两套资源，就是因为不能设备的分辨率不一样。
第三个兼容性是手机的软件版本。就是常说的iOS10，iOS11，iOS12等等。按照苹果的期望，iOS的最低支持版本越高越好。XCode的默认设置都是当前版本。这是一种值得推荐的做法，可以有效防止版本的碎片化。为了达到这个目标，苹果还做了“静默升级”，也就是当iPhone在电量充足，比如充电的时候，并且有WiFi的情况下，会自动将iPhone升级到最新的版本。

关于测试

最方便的是开发版测试，将测试机通过XCode安装一下就可以了。当然，测试机要注册（XCode自动完成），也在100台范围之内。
第二种是Ad-hoc测试。这种适用于开发和测试是异地的情况。当然，一些特殊情况，比如这次的推送测试，也用到了。主要原因是推送后台连生产环境的时候，要求iOS客户端是release版本。Ad-hoc测试是release版本；开发版是Debug版本。
Ad-hoc测试的手机也是注册，也在100台范围之内。
Ad-hoc版本不能直接通过XCode安装。需要先用XCode打包，导出Ad-Hoc选项的iPa包（相当于与Android的apk），然后通过其他工具，比如(iTools)进行安装。
当然，Ad-hoc测试也可以做个下载页面，给个二维码扫描安装，不过这就需要前端同学介入做下载页面了，稍微有点麻烦。
第三种是Test Flight测试。这是目前苹果推荐的测试方式。开发通过XCode将测试包上传苹果服务器；使用者通过扫描就可以安装使用，非常方便。
Test Flight上的包是release版本的；
通过Test Flight安装的手机不需要提供UUID，没有100台范围限制；
Test Flight需要通过苹果审核，这是非常麻烦的地方；
用户需要先安装Test Flight应用，才能扫码下载安装，有一点点不方便。

应用发布

APP开发完成，测试好了，接下来就是要发布了。

首先，要上苹果发布网站（iTunes Connet）创建应用。

image.png

在苹果开发者网站创建的Bundle Id和应用的名称，在这里都要用到。不需要手填，只要选择就可以了。

其次，通过Xcode打包，导出App Store的iPa包；这个包是用来在苹果的App Store发布用的，和Ad-hoc测试包有本质区别。
然后，将iPa包上传到苹果后台，可以用Xcode直接上传，也可以用工具Application Loader上传。

苹果审核

这是整个过程中最麻烦的地方，也是被吐槽最多的地方，也是苹果特色的地方。

需要登录苹果的发布网站，也就是iTunes Connect，填写一些资料。比如应用的简介，描述，支持网站，应用分类，测试账号等等。内容比较多，一般由产品来写。还需要提供屏幕截图，短视频也支持。
资料完整之后，就是提交审核，进入排队过程。一般来说，第一版等的时间比较长，以后的升级过程会快一点。
如果审核有问题，会被拒绝，相关问题可以在苹果网站上看到，同时也会发邮件通知。所以，提交审核之后，要经常上苹果网站查看状态，并且留意苹果账号邮箱是否接到苹果的问题邮件。
一般情况，这个过程一周左右。当然，快的两三天就通过审核，顺利上线的也有，只是这样的例子并不多。如果遇到问题，通过邮件沟通，按照要求改，一来一去，第一版十天半个月上不去也是常有的事。

常见的问题

这里只是列出几种情况，被拒的原因五花八门，真的需要耐着性子，好好的与苹果进行邮件沟通才能过。

如果iPad也能用，还要提供iPad上的截图，虽然有个手机外形。所以，没有必要，还是省事点好，直接只支持iPhone就好了。
截图上有的功能，但是苹果审核人员看不到，那么就会被拒。功能和截图不符，肯定过不了。所以，截屏，只要提供几张常见的图片就可以了，比如启动页，首页，个人信息页等。千万不要贴那种不容易出现的页面，比如摇一摇的隐藏页面，地理位置变换页面等特定条件才能出现的页面。
提供的测试账号，一定要有效，并且，最好有数据。比如，账单页面，如果这个账号是新的，没有交易记录，是空页面，苹果审核人员就可能认为这是个空页面，认为功能不全而拒绝。
一些特殊领域页面要注意，比如银行理财，苹果就会要求提供金融资质证明文件，不然就不给过。
屏幕出现的按钮都要能点。如果有三个按钮，只有一个按钮可点，另外两个，点一下，提示“功能升级中...”之类，也是会被拒的。苹果认为这是demo版，不可用。所以，这种情况，干脆只放一个可点的按钮，还没开发好的模块按钮不可见，反而能过。
广告id，这是一个比较热门的话题。有些早期的第三方库，采用广告id来做手机的唯一标识符，但是应用中并没有出现广告，也是会被拒的。理由是：苹果后台扫描出了广告id，但是没有看到广告，拒绝。
iPv6，这也是曾经很折磨人的一个地方。中国的网络运营商整体都是不支持iPv6的，但是苹果却要求我们的应用支持iPv6，真是没天理啊。所以，审核那几天，要保持iPv6能通；如果实在不行，那么就拍个视频，本地搭一个iPv6，证明能用，并且把视频放到美国能访问到的某个网站上，并提供相关链接，让审核人员能方便看到。

环境切换

这个和苹果没有关系，是我们的后台部署在不同的服务器上，域名不同而导致的。
为了方便更换域名，提供了一个的操作页面。这个页面一般不容易进，并且还需要密码，一般是给内部测试人员用的。比如连续点关于图标5次，并且在弹出的对话框中输入正确的密码才能进。