移动应用的发布说明：字数上限到底会砍掉什么

这个专题下关于怎样写发布说明的所有内容，默认前提都是你能完全掌控的一个页面：想要多长就多长，链接能正常点开，格式能正常渲染出来。而一个移动应用的发布说明，却生活在别人家的盒子里。苹果给大约 4000 个字符的空间，但在用户点开”更多”之前，只会展示最前面那几行；谷歌给的空间量级差不多，也存在同样实际的预览问题，而且这两个平台都不会把文字里的链接渲染成可以点击的样子。怎样写真正会被读完的发布说明 里的那些规则依然成立：说清楚到底改了什么、读者到底该做什么，但用来做这件事的空间，只是体验日志页面所允许空间的一小部分，取舍必须是刻意为之的，而不是不小心造成的。

看得见的预览区域，实际上到底能装下多少内容

最前面的一到两行，具体大约是 80 到 170 个字符，取决于设备和字号大小，在这之后读者才需要点一下才能展开看到更多。这就是发布说明里决定到底会不会有人愿意接着读下去的那部分内容，所拥有的全部预算，这也意味着最重要的那句话必须放在最前面，而不是版本号，不是问候语，也不是分类标题。一条以”本版本更新内容：“开头的发布说明，已经把三分之一的可见空间，花在了四个对读者什么都没说清楚的字上。

“现在能做什么、承诺过什么”这条规则，在这么短的篇幅下是不是依然成立

依然成立，而且会变得更严格，而不是变成别的东西。每条更新一句话，动词放最前面，不要铺垫：“在设置里就能把数据导出成 CSV 格式。“用三分之一的字数，说出了跟”我们新增了一项功能，用户现在可以把自己的数据导出为 CSV 格式了”完全一样的意思，还赢了。在体验日志页面那种篇幅下，一句稍微啰嗦一点的话，只不过让读者多花半秒钟。而在移动端发布说明这种篇幅下，同样的啰嗦程度，完全可能把整句话都挤到看得见的预览区域之外，结果读者根本看不到那个原本能告诉她到底改了什么的动词。

不好的写法，把预览区域浪费在了铺垫上：
"我们很高兴为你带来一次充满改进的全新更新！
继续阅读了解详情。"

好的写法，全部价值都在第一行：
"在设置里就能把数据导出成 CSV 格式。深色模式现在
会跟随系统设置了。修复了打开分享链接时的崩溃问题。"

一条网页版体验日志记录通常会保留的内容，在这里必须被砍掉哪些

首先是链接，因为两个应用商店都不会把它渲染成可以点击的样子，所以文字里的一个 URL，就成了一段读者不得不重新手打一遍的死重量。如果这条更新确实需要指向某个地方，那就换成说明在应用里该点哪里：“在设置 > 搜索里可以看到新的筛选项”是能用的写法；“更多内容请见 example.com/blog/filters”在这个界面上根本行不通。其次，任何带条件的、或者只针对特定人群的内容也要砍掉：一条网页版体验日志可以说”如果你在用这个 API，这条跟你有关”，但一条应用商店的更新说明，会同时触达每一个安装了这个应用的用户，所以一句带条件的话，对那 95% 完全用不上这条信息的用户来说，读起来就是噪音。带条件的细节，应该改放进一条应用内消息里，只针对真正跟这件事有关的账户触发。

是不是每一次发布都该有自己专属的更新说明，还是说反复使用”修复了一些错误，提升了性能”也没问题

对于确实只是这样的发布来说，反复使用是没问题的，但要经常审视一下这句话到底有多大比例的时候是真的属实。怎样写发布说明 已经讲过，为什么这句话会暴露出这是一份从内部视角写出来的说明，而不是为读者写的；在移动端，这会造成双重伤害，因为应用商店的发布说明是少数几个能让部分用户在两次更新之间，真的看到点什么的地方之一，而一长串”修复了一些错误，提升了性能”，读起来就像这个应用根本没有在变化，这给人留下的印象，比那段时间里干脆什么更新说明都没有还要更差。

发布说明到底会不会影响人们要不要去更新这个应用

会，但是通过可见度而不是说服力，间接地起作用。大多数用户是自动更新的，从来不会在更新前去读这些说明；这些说明真正重要的对象，是那一小撮手动检查更新的用户，以及那些会翻看应用商店更新历史的评测者或媒体记者。为这一小群读者去认真写，依然是值得的，因为一份带有真实的、具体的、有日期的更新历史的商店页面，读起来就像一个正在被积极维护的应用，而一份连续一整年都写着”修复了一些错误，提升了性能”的页面，无论那段时间里实际上到底发布了多少东西，都读不出这种感觉。

那强制更新呢？这种情况下说明必须解释清楚为什么用户根本没有选择余地

把原因和截止日期放在第一行说清楚，放在其他任何内容之前，因为强制更新是唯一一种读者在开始阅读之前就已经很不爽的情况。“这次更新是继续同步你的数据所必需的。请在[日期]之前完成更新，以免造成中断。“用一句话就说清楚了该做什么、为什么要做；如果把这个原因埋在三行毫不相关的功能更新说明底下，读起来就像这个应用在故意隐瞒那个让人不舒服的部分。

FAQ

移动端的发布说明是不是应该跟同一次发布的网页版体验日志保持一致? 应该覆盖同样的底层变更，但不需要逐字逐句一模一样。网页版体验日志可以承担得起完整的解释；移动端说明需要的是把同样的事实压缩成一句动词在前的话，这通常意味着这是一次重写，而不是一次复制粘贴。

给每一种支持的语言都做移动端发布说明的本地化，值得吗? 值得，甚至比网页版体验日志更值得，因为应用商店的页面，往往是部分用户在两次使用之间唯一能看到的、经过本地化的界面，而且这两个平台都支持按语言区域分别提供发布说明，除了翻译本身之外，不需要额外的工程工作量。

如果没有强制要求简短的字数上限，移动端发布说明到底该写多长? 还是应该短。iOS 上 4000 字符这个上限，很少是真正的限制因素；真正限制你的是那 2-3 行的预览区域，写得超出预览区域能展示的范围，只会让更少的人读到真正重要的那部分内容。

发布说明的可见文字里，需要包含版本号吗? 不需要。应用商店本来就已经在说明旁边显示了版本号。在文字里再重复一遍，只是在为读者眼前已经拥有的信息，多花一份本就宝贵的可见字符。

本文的技术内容未经独立审核。如有错误，请告诉我们，我们会更正。

changeloop 相关页面： 发布说明模板, changelog 示例