一句话结论：TestFlight（苹果官方测试分发渠道）的构建版本有效期是 90 天，到期之后 App 会直接打不开，且不能延长，只能重新提一个新的构建版本上去。
90 天从哪一天开始算
起算点是这个构建版本通过审核、可以开始对外测试的那一天，不是你上传的那一天。中间如果审核花了一周，这一周是不算进 90 天的。
TestFlight 的界面上会显示剩余天数，测试员列表里也能看到。这个数字是最准的依据，不要靠自己记日子。
到期前后会看到什么
临近到期时，测试员会收到 TestFlight 应用的提醒，说明某个 App 即将过期。到期当天，图标还在，点进去会弹提示说明这个版本已过期，需要更新。此时应用内的数据还在，但进不去。
如果服务商或者开发方在到期前上传了新的构建版本，测试员在 TestFlight 里点更新就能续上，本地数据通常会保留——前提是 Bundle ID（应用包名）没变、且没有卸载重装。
到期之后的三条路
第一条，续一个新的构建版本。这是最标准的做法。把代码重新打包上传，走一遍 Beta 审核（测试版审核，比正式上架那道审核宽松一些），通过后测试员更新即可。整个链路和第一次一样，只是省掉了邀请环节——已经在名单里的测试员不需要重新邀请。时间上要留出审核周期，别等到最后一天才动。
第二条，切换到其他分发方式。如果这次测试周期本身就长，或者版本迭代频繁到每 90 天提一次显得麻烦，可以把一部分用户迁到企业签或者超级签。这条路要考虑的是用户迁移成本：换方式意味着要重新下载安装，本地数据不保。
第三条，正式上架。如果产品已经到了可以公开的程度，上架 App Store（苹果官方应用商店）是从根上解决有效期问题的办法。审核门槛比 Beta 高，周期也不短，但一旦上去就不再有 90 天这一说。
经常被忽略的两个细节
第一，内部测试和外部测试的规则不同。内部测试成员（开发者团队账号下的成员）的构建版本同样有 90 天限制，但不需要审核，上传即用；外部测试组需要审核，但人数上限大得多。选哪种，取决于你要覆盖多少人。
第二，审核被打回会消耗时间。如果新版本在到期前一周才提交，一旦被要求修改，就会出现断档——老版本过期了，新版本还在审核里。稳妥的节奏是提前两周以上提交。
怎么提前安排
在日历上标两个时间点：到期前 21 天开始准备新版本，到期前 14 天提交审核。同时在 TestFlight 里保持至少一名内部测试员可以随时验证，别把验证环节全部压在外部测试通道上。
如果是找服务商代做，把这两个时间点明确写进沟通记录里，让对方也盯着。90 天是硬规则，没有任何办法可以绕过或者延长。
小结
90 天是 TestFlight 的硬约束，起算日是开始对外测试那天，到期不能续、只能换。提前 14 天提交新版本是安全线；版本迭代频繁或者周期长的项目，应该提前评估是否要换其他分发方式。
我是本期作者小思，想解决苹果企业签名、超级签名、TF签名问题？可以在微信公众号对话框找到我哦~（QQ：822404920 微信：A-mk5888）
