今天和大家聊下app新旧版本上的那些坑，当然本文不涉及什么复杂难懂的技术话语（其实本人也不懂），更多的是从让用户层更加容易接受的角度出发进行描述。
说在前面
17年转行做产品，到现在也算半个产品人了吧？！
一、版本
什么是版本，简单的理解就是appstore或应用宝等市场提示你该软件要更新了，更新的这个就是最新版本，只有下载了最新版本才能体验到app的最新功能。
一般app会有几种方式提示你有新版本去更新：
强制更新一般较少使用，不给用户选择的权利导致体验较差；提示更新是当前较为主流的办法，支持旧版可以正常使用的情况下告知用户有新版本，选择权在用户手里。
场景提示更新其实也属于提示更新，这里单独拎出来说明一下：当应用功能模块较多时，当只有涉及到一个功能模块更新时，就可以采用当用户使用这个模块时进行提示更新，提示更新仍可分为两种：忽略和强制。
而更新的方式大体有两种，大部分应用采用通过跳转至应用商店让用户更新至最新的app：
二、功能
更多的更新方式不做赘述，什么情况下采用什么样的更新方式呢？
我们回归本质的东西：版本。
每次发布app版本都是涉及到功能的更新，所以我们可以从发布的功能大小、涉及面等进行划分三大类：
1.1功能对比图
新功能和优化功能可以看成新的模块，旧版本就是没有开放使用的入口，并不会影响用户继续使用旧版本的app，如果有需要使用最新功能则可以进行更新。
一般这种情况下我们引导用户更新，选择权在用户手上。
原功能大改版比较复杂，因为涉及到的业务逻辑都发生了改变，逻辑发生改变意味着数据层面的交互发生改变，数据层面发生改变就意味着数据接口需要改变。
当然这里有两种处理办法：
1.2新旧版本处理方式
相比于第一种半强制更新的办法，第二种更加的友好，用户有权利选择是否去更新，但是由于需要提供两套接口且接口需要跟着app版本走，开发成本会增加。
当然大厂一般都是第二种方案处理的，等大部分用户都在新版后，数据同步一致了，旧甚至是更旧版本便会强制用户进行更新，随着版本越高，旧的接口维护起来就越不划算。
同时采用第二种新旧接口共存仍然会存在一些问题，当应用功能涉及到用户间的交互，如用户A在用旧版，用户B在用新版，此时两端发生两端交互时，可能存在新版“输出”的东西旧版识别不了。
1.3用户新旧版本对照
如果产品设计框架上本身就考虑了很多拓展性，新旧版本便不存在这些问题；如果框架上不支持，且通过兼容的方式成本又比较大，则可以引导旧版进行强制更新的方式。
三、新老数据
当功能发生很大变化时，必会导致旧数据和新数据字段或功能不一的情况，假设只是原来字段的增删改，新版通过数据的清洗保持一致即可，但是假设需要更多的其他形式的支撑，原来的数据列表情况无法支持，这时可选择将原来的数据作为历史数据保存一份，和最新数据分开来，也就是存在两个数据列表：一新一旧。
1.4新老数据
总结
产品从设计开始之初在框架上做好拓展性，即便后期进行版本升级，旧版本和新版本依旧可以正常使用，如果条件允许新旧版本可以保持两套接口。新旧版不影响使用，不强制用户升级对用户使用体验较好；否则就只能强制用户升级了。
本文由@F.yrun原创发布于人人都是产品经理，未经许可，禁止转载。