做了七年 Android 应用之后，iA 在 2024 年 9 月 26 日发出一则公告：iA Writer 的这个版本要暂时下架，停止增加新功能。公司表示，既有用户仍保留访问，关键更新会在平台允许的条件下提供。[1]
公告描述的困难，很大一部分发生在编辑器之外。按 iA 的自述，Google Drive 访问受阻以后，团队持续修改资料、处理验证，又遇到年度安全评估要求；不同设备上的问题排查也在占用时间。这是公司的个案陈述，本文没有拿到双方完整的处理记录。[1]
这里也需要区分个案和一般规则。Google 官方用户数据政策对特定敏感、受限权限设置了附加要求，年度第三方评估是否适用，取决于所访问的 API、授权或用户规模。不能把这件事概括成所有 Android 应用都必须接受同样的评估。[2]
这段经历让我更在意一个做产品时容易算窄的问题：决定支持某个平台，到底是在安排哪些人的哪些工作？
初版计划通常容易列。页面要适配，文件要打开，编辑操作要能用。完成这些事项，可以演示一款应用。往后一年会发生什么，却不一定出现在同一张计划里：某个连接需要重新验证，设备升级后有人打不开旧文件，产品说明需要跟着能力变化，客服还要解释为什么昨天可用的入口今天出了问题。
这些工作没有固定出现在同一天，也未必能靠一次重写消失。一个小团队如果只计算首次开发，就容易在上线之后才发现，原来有人需要持续为这些事情留时间。
举个假设。一个两人团队已经有桌面观察笔记工具，用户希望在户外用手机随时记录观察结果。团队打算做移动版，于是写下“编辑、同步、导出”三个功能。三个词看起来很小，但用户实际要完成的事情可能差别很大。
一位用户只是在现场打开昨天的笔记，补几行字，回到住处再手动带回电脑。另一位用户希望手机和电脑始终同步，多人修改也能立即合并。两人都可能回答“我需要手机版”，后面需要维护的依赖却不同。
在开始承诺之前，我会先给每种任务写一个完整句子，例如：“在没有网络时查看已经存到手机的笔记，并保留本次修改。”这样的句子可以交给开发者、客服和用户共同理解。它也会迫使团队继续追问：用户换了手机怎么办？文件还没下载时怎么办？所谓保留，保存到了哪里？
接着为这句承诺补一份短记录：它依赖哪些平台能力或外部服务，谁能处理相关变更，下一次在什么事件发生时复查。复查可以由系统大版本发布、权限调整或实际故障触发；不必假装所有问题都能排进一张准确的年度日历。
这张记录也可以揭示可缩小的范围。移动版也许先支持打开用户明确选择的文件，而全自动同步另作评估。这样调整的理由应来自目标任务和维护能力；不能先砍掉一半体验，再用“轻量”解释所有遗漏。具体实现仍要核对平台当时的要求，换一种接口并不自动消除责任。
如果团队已经提供了某项能力，后来的收缩还多一层工作：说明哪些任务仍能完成，哪些将不再承诺。
只写“进入维护模式”，用户未必知道明天还能做什么。更有用的说明，是把打开旧文件、编辑、新建、同步、导出和重新安装分别讲清；其中无法确定的事项也要直说。这里列的是假设笔记工具需要回答的问题，不是对 iA Writer 当时全部能力的描述。
同样，“暂时不做新功能”和“停止所有支持”也有不同含义。iA 的公告为既有访问和关键更新保留了条件，还提到将来可能探索面向机构的安排。那是当时的后续设想，不能据此宣布它已经找到新的可持续模式。[1]
对小团队来说，支持范围可以随着资源和需求变化，但变化需要翻译成用户能理解的具体任务。内部决定省下一项工作，外部可能意味着一个人要改掉已经养成的习惯。两边都记录清楚，才能讨论哪些承诺继续、哪些需要重新协商。
在跨平台项目开始时，除了问“这一版要多久做出来”，还可以让负责的人试着回答：“下一年，这个平台最可能把谁的时间叫走？”答案未必准确，却会比只看上线日更接近真实经营。
资料与日期：
