今天和大家聊下app新旧版本上的那些坑，当然本文不涉及什么复杂难懂的技术话语（其实本人也不懂），更多的是从让用户层更加容易接受的角度出发进行描述。

说在前面

17年转行做产品，到现在也算半个产品人了吧？！

刚开始做产品接触的是web端的saas类产品，新功能更多的是直接web部署上线，不存在太多新老版本的问题，登陆网址大家就可以享用最新的功能。当时也并不是很了解app上新老版本的一些问题，然后最近开始接触移动端相关的产品设计，开始把所有新老版本的坑都走了一遍，着实难受，因此今天做下总结。

一、版本

什么是版本，简单的理解就是app store或应用宝等市场提示你该软件要更新了，更新的这个就是最新版本，只有下载了最新版本才能体验到app的最新功能。

一般app会有几种方式提示你有新版本去更新：

1. 强制更新，不更新就用不了（全局性强制和模块式强制）；
2. 提示更新，可以选择忽略；
3. 某个功能场景下提示更新。

强制更新一般较少使用，不给用户选择的权利导致体验较差；提示更新是当前较为主流的办法，支持旧版可以正常使用的情况下告知用户有新版本，选择权在用户手里。

场景提示更新其实也属于提示更新，这里单独拎出来说明一下：当应用功能模块较多时，当只有涉及到一个功能模块更新时，就可以采用当用户使用这个模块时进行提示更新，提示更新仍可分为两种：忽略和强制。

而更新的方式大体有两种，大部分应用采用通过跳转至应用商店让用户更新至最新的app：

1. 下载整个应用包，跳转至应用商店现在或直接进行下载；
2. 下载局部更新包，不需要关闭app就可完成更新。

二、功能

更多的更新方式不做赘述，什么情况下采用什么样的更新方式呢？

我们回归本质的东西：版本。

每次发布app版本都是涉及到功能的更新，所以我们可以从发布的功能大小、涉及面等进行划分三大类：

1. 新功能；
2. 原功能大改版；
3. 优化功能。

1.1 功能对比图

新功能和优化功能可以看成新的模块，旧版本就是没有开放使用的入口，并不会影响用户继续使用旧版本的app，如果有需要使用最新功能则可以进行更新。

一般这种情况下我们引导用户更新，选择权在用户手上。

原功能大改版比较复杂，因为涉及到的业务逻辑都发生了改变，逻辑发生改变意味着数据层面的交互发生改变，数据层面发生改变就意味着数据接口需要改变。

当然这里有两种处理办法：

1. 改造原来的数据接口以支持新版；
2. 重新写一套接口，新旧接口共存。

1.2 新旧版本处理方式

相比于第一种半强制更新的办法，第二种更加的友好，用户有权利选择是否去更新，但是由于需要提供两套接口且接口需要跟着app版本走，开发成本会增加。

当然大厂一般都是第二种方案处理的，等大部分用户都在新版后，数据同步一致了，旧甚至是更旧版本便会强制用户进行更新，随着版本越高，旧的接口维护起来就越不划算。

同时采用第二种新旧接口共存仍然会存在一些问题，当应用功能涉及到用户间的交互，如用户A在用旧版，用户B在用新版，此时两端发生两端交互时，可能存在新版“输出”的东西旧版识别不了。

1.3 用户新旧版本对照

如果产品设计框架上本身就考虑了很多拓展性，新旧版本便不存在这些问题；如果框架上不支持，且通过兼容的方式成本又比较大，则可以引导旧版进行强制更新的方式。

三、新老数据

当功能发生很大变化时，必会导致旧数据和新数据字段或功能不一的情况，假设只是原来字段的增删改，新版通过数据的清洗保持一致即可，但是假设需要更多的其他形式的支撑，原来的数据列表情况无法支持，这时可选择将原来的数据作为历史数据保存一份，和最新数据分开来，也就是存在两个数据列表：一新一旧。

1.4 新老数据

总结

产品从设计开始之初在框架上做好拓展性，即便后期进行版本升级，旧版本和新版本依旧可以正常使用，如果条件允许新旧版本可以保持两套接口。新旧版不影响使用，不强制用户升级对用户使用体验较好；否则就只能强制用户升级了。

本文由 @F.yrun 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。