App 上架只是开始：海外产品为什么更看重”能接着改”
交付一个 App，和交付一个几年后还有人能接着改的 App，是两件事。本文讲长期维护型交付，工程结构与合同上要提前定什么。
交付一个 App，和交付一个”几年后还有人能接着改的 App”，是两件事。我们手上有一批面向海外市场的产品——社交、医疗设备配套、内容类都有——从首次上架到现在已经几年过去，还在按版本迭代。这篇文章讲的是这类长期维护型的交付，我们在结构上会提前做什么。
一、为什么海外产品更容易变成”长期活”
一个 App 只要还在商店里、还有人在用，就会一直有活要干：
- 手机系统每年出大版本，工程要跟着适配；
- 用到的第三方 SDK（登录、推送、统计、云服务）每隔一段时间就要升级，不升就会在某个版本上失效；
- 商店的审核规则与合规要求也在变，几年前能过的东西，今天未必还能过。
这些都不是”加新功能”，但没有它们，App 会慢慢变成”传不上去”的状态。
二、怎么核验你的外包方还在维护
判断你的外包方是不是还在维护这个 App，有一个很直接的方法：把工程仓库的最后提交时间和商店的最近更新时间对一下。
两份时间线吻合，说明代码还在动、包还在发；工程停了很久、商店却还在更新，就要问清楚是谁在维护、维护的是什么。这个动作不需要授权任何账号、也不用看对方的后台数据，公开信息就能核。
所以验收和续约之前，建议你实际做一次这个核对：「还在维护」不该是外包方的一句口头承诺，而应该是你能亲手核验的事实。
三、代码要经得起”换人接手”
长期维护最怕的不是难，是”只有一个人知道怎么弄”。所以工程结构上要提前做几件事：
- 按业务拆模块，而不是所有逻辑堆在一个壳里；
- 依赖清单完整、版本锁住：拿过工程就能看清用了什么、哪个版本；
- 构建与发布有步骤说明，而不是”某台电脑上能打包”；
- 老工程不等于该推倒：老语言写的工程可以混编、可以组件化，继续演进往往比推倒重来更划算。
选原生还是跨端，也会直接影响长期成本：跨端框架每次大版本升级都要评估迁移成本，原生工程的工具链相对更可预期。这个取舍我们在另一篇笔记里单独拆过。
四、上架之后真正会反复出现的三类活
- 平台侧强制更新：新系统 SDK 要求、权限用途说明、隐私清单、图标与截图规范；
- 第三方依赖升级：社交登录、推送、统计、云服务 SDK——隔一段时间就得动一次；
- 审核规则调整：条款变化、合规要求更新，以及偶尔的”这次为什么被拒”。
这三类活的特点是：不定期、不可预期、但不做不行。它们的排期很难提前排，只能靠”维护这件事有人负责”来兜。
五、”长期维护”怎么合作
常见有三种形态，选哪种取决于甲方自己的团队状况：
- 按人天：适合需求不连续、来一件做一件；
- 按版本：适合有固定的发版节奏；
- 多期合同：适合要连续演进几年的产品。
不管哪种，真正要写清楚的是维护范围的边界：
- 只管”保上架可用”，还是也含新需求？
- 响应边界多长、什么算紧急？
- 证书、账号、发布流程谁持有？
这几条不写，最后一定会变成”我们以为你们会做”。
六、给甲方的一份”长期视角”清单
选外包、或者准备接手一个既有 App 时，建议逐条问：
- 工程能不能独立构建——别人拿到源码，能不能打出包？
- 依赖清单是否完整、有没有锁版本？
- 发布流程有没有文档或脚本，还是只有某个人会传包？
- 证书与描述文件谁持有、什么时候到期？
- 商店账号与主体信息谁持有？
- 维护期、响应边界、计价方式，写进合同没有？
这六条问下来，基本上就能判断这个产品”两年后还能不能改”。
七、一条经验
我们评估这类合作的时候，最先看的不是功能列表，而是”两年后谁在维护、拿什么维护”。把这件事同时写进合同和工程结构里，比当期多做两个功能更值钱——功能会过时，能接着改的能力不会。
如果你的 App 已经上架、接下来几年还要继续演进，建议先把第六节的清单过一遍，再谈维护怎么合作。