阅读 427

iOS APP针对产品的版本迭代管控总结

对于iOSer来说,上架APP是常有的事,特别是外包公司往往短短1-2个月就能套一个APP出来。不过事后估计也不会咋管这些APP了。但对于很多在做真正产品的小伙伴来说,一个APP的版本迭代管控是非常重要的。简而言之,以我现在理解则是:\color{red}{尽最大努力减少线上问题的影响范围}。 下面我将分享一些自己整理的APP版本管控内容,不足之处还望指点。

一、线上BUG收集

作为程序员,谁都不敢保证自己写的程序永远不会出问题。即使你的代码或者架构弄得再好,也可能出现一些系统更新不兼容、特殊设备环境、以及蛋疼的第三方问题,因此线上BUG的收集是至关重要的。千万别指望苹果自带的Crash收集系统,虽然界面很酷炫,自带符号表解析、功能齐全,然而用户要是没有同意或开启诊断和用量,根本接收不到Crash信息。

因此建议使用一些第三方的线上BUG收集库,列如:友盟,bugly等。我本人是使用的bugly,能快速接收到crash信息,并且全面支持Swift。

二、版本号

我们都知道版本号是x.x.x这样的。关于它的命名规则,这里有篇简单的文章可以浏览一下版本号命名规范及原则,大致意思就是:

  • 第一个数代表一些比较大的变动,比如全新的UI界面之类。
  • 第二个数代表一些功能的新增或变化。
  • 第三个数则代表一些bug的修复了,它往往很频繁。

这样做既可以明确当前版本的定位,也可以让该产品在多端之间达到沟通便利。

假如线上是1.0.0版本,新版本是1.0.1,对比方式不能仅仅比较它们是否相等,就做出提示更新操作。 我们可以通过将当前版本,和最新版本号都转换成整数,然后判断新版本号是否大于当前版本号,下面是一个简单的例子,如果有最新版本返回true,否则返回false

func checkVersion() -> Bool {
    
    //服务器获取到的新版本号
    let newVersion = "1.0.1"
    
    if let infoDic = Bundle.main.infoDictionary {
        
        //获取当前版本号,并转成整形
        let currentVersion: String = infoDic["CFBundleShortVersionString"] as! String
        var currentVersionInt = 0
        let currentArray = currentVersion.components(separatedBy: ".")
        if currentArray.count == 3 {
            currentVersionInt = Int(currentArray[0])! * 100 + Int(currentArray[1])! * 10 + Int(currentArray[2])!
        }
        
        //将最新版本号转成整形
        var newVersionInt = 0
        let newArray = newVersion.components(separatedBy: ".")
        if newArray.count == 3 {
            newVersionInt = Int(newArray[0])! * 100 + Int(newArray[1])! * 10 + Int(newArray[2])!
        }
        
        //对比两个版本号
        if newVersionInt > currentVersionInt {
            return true
        }
    }
    return false
}
复制代码

三、版本更新

在上一节中我们判断出有新版本,但此时还不能去做提示更新的操作,因为并不是所有新版本发布都会立即让用户更新,当然也有特例情况。因此可以分为3种方式。

  • 1、静默更新 静默更新是指iPhone设备在用户允许的情况下,自动更新App Store市场上的APP。也就是说只要你发布了新版本,即使不通过代码的手段提示更新,也会有一部分用户会自动更新到最新版本。

  • 2、提示更新 提示更新也就是我们最常见的一种,这种应该是新版本已经在静默更新中被一部分用户持续稳定运行一段时间(通过线上BUG收集,和客服部反馈等),确定没有问题后,主动提示所有用户(当然也可以根据代码来控制部分群体用户)进行更新。当用户看到这个界面后,可以点击更新,也可以不更新(一般都有关闭按钮)。选择权依然在用户手里,而且APP启动时只检测一次,对用户体验非常友好。

  • 3、强制更新 强制更新重点就在强制,我的理解就是\color{red}{不更新,就别用了}。 比如APP中某个API准备要废弃了,但是老版本的APP还有用户在使用,此时就可以用强制更新,解决一些“老”用户不更新的问题。在上一种方式的界面基础上,取消掉所有可以关闭的按钮和手势即可。

总结:通过上述的3种方式,一般在首页请求一个检测版本更新的接口,该接口含有最新版本号,是否提示更新,是否强制更新3个字段。发布新版本后,我们一般先任其静默更新一段时间,观察新版本是否稳定,若有问题,则立即修复发布新版。若没有问题则可以提示用户进行更新。

四、阶段更新

在使用App Store connect发布APP时,可以选择阶段更新,在7天内依次叠加向所有发布。注意这里的发布是指向已打开自动更新的用户发布,也就是之前我们所说的静默更新。但所有用户依然可以去应用市场手动更新至最新版本。并且中途我们可以暂停分阶段发布(最多暂停30天)。通过此方法,可以说是极大的提高了APP版本迭代的可控性,若发现BUG便可在影响最少用户的情况下及时作出反应。

五、总结

通过上述所介绍的几种手段,可以说给APP新版的发布套上了层层的安全保障。 即使出现重大的BUG,影响也会被降到最低。在版本迭代中还有很多奇淫技巧,这里只是大概介绍了一些基本常用的。例如热更新,还需要在与苹果爸爸不断的博弈当中汲取经验。TestFlight发布测试版本,邀请用户进行Beta测试等等。总之我们的宗旨就是确保发布更新的版本要稳定,如果大家对文中有什么意见,还望指出不足之处。

关注下面的标签,发现更多相似文章
评论