定制开发一个 App，一般多久可以上线第一版？

结论：没有首版范围、目标平台、现有资产和外部依赖，就不能给出可靠的“几周上线”。首版时间应按可验收功能的工作量、团队有效产能和最长依赖链计算，并把测试、数据迁移、账号资质、支付或地图联调、隐私整改和商店审核单独列出。滚水科技会在原型与依赖清单确认后给区间和置信度，不用单端 6—8 周、双端 8—12 周套所有项目。

“第一版”也需要定义。是内部演示包、邀请测试、应用商店可下载，还是已接真实支付并能服务客户？内部 Demo 可以用模拟数据，正式上线则需要生产账号、监控、备份、隐私声明和运营人员。两者相差的工作不是页面数量能解释的。

首版目标	必须包含的证据	常见最长依赖	何时算完成
可点击原型	关键角色、流程、状态和文案	业务决策与素材	真实用户可完成任务走查
内部 Demo	核心界面、模拟或隔离数据、已知限制	技术可行性与接口样例	演示环境按脚本稳定运行
邀请测试版	真实后端、账号、日志、测试分发	测试设备与第三方沙箱	指定用户完成核心闭环并反馈
商店首发版	生产配置、隐私、监控、回滚和审核材料	开发者账号、资质、商店审核	目标市场可下载且生产健康
交易可运营版	支付、对账、客服、退款和应急	商户号、合同、运营排班	完成一笔真实交易及异常演练

在安排里程碑、资源与验收节奏时，还可以对照 为什么需求字段没梳理清楚会直接影响工期和报价？ 和 如果参考一款成熟软件做定制开发，首期版本一般需要多久？；这些内容补充了需要放在同一项决策中考虑的上下文。

用工作包估算，不用页面数估算

先把首版拆成用户故事或工作包，每项写清输入、正常与异常路径、数据、权限、验收样本和依赖。团队分别估算产品、设计、客户端、后端、测试和部署工作量，再根据谁能并行、谁必须等待形成依赖图。两端共享业务逻辑不等于工作量减半，原生开发也不必然翻倍；摄像头、蓝牙、后台任务、推送和支付等原生能力会改变跨端收益。

有效产能不是“人数乘工作日”。同一模块多人并行会有沟通和集成成本，成员还承担评审、修复和会议。最可靠的速度来自该团队近期、相似技术和相似完成标准下的已完成工作。首次合作没有历史数据时，应给范围区间和风险区间，并在完成第一个迭代后重新预测，而不是把最乐观日期写成确定承诺。

商店审核是外部窗口，不是开发工时

Apple、Google 和国内市场的账号验证、测试要求、隐私申报、类目与审核时长会变化。提交前把账号、主体、合同、隐私、测试账号和商店素材列为客户侧依赖，并设置最晚就绪时间。开发完成只代表可提交，不代表审核一定通过；首次被拒后的整改与再次审核作为风险，不编造“一般 1—3 天”。

排期应至少展示基准日期、目标区间和关键风险。基准日期建立在当前范围与资源；目标区间包含已识别的不确定性；外部依赖如未获得测试环境，就标记为未承诺。新增需求、关键决策延迟、接口变化或审核驳回发生时，更新影响和新预测，保留旧基线，不能悄悄移动日期。

首版是否应该更小，用价值和风险选择。通常优先保留一个角色从进入到获得核心价值的完整闭环，以及必要的后台、权限、监控与退出；报表美化、复杂运营工具和低频设置可后移。但支付安全、个人信息删除、备份和高风险异常不能因为是 MVP 就省略。砍功能要连同数据和流程一起砍，不能留下半个不可运营模块。

验收进度不看“完成 80%”这种主观数字，而看已满足完成定义的工作包、剩余工作趋势、阻塞天数、未决事项、缺陷曲线和关键依赖状态。每个里程碑有可访问版本、测试结果和变更记录。范围和完成定义不变时，连续几个迭代的实际吞吐才能用于更可信预测。

滚水科技会先交付首版范围、原型、工作分解和依赖清单，再给日历区间；排期同时列客户材料、第三方和审核。若用户时间窗口固定，就反向裁剪范围并注明不能牺牲的上线门槛，而不是用加班承诺把所有功能塞进日期。

参考资料：

• The Scrum Guide 官方版本：用于参考迭代、可用增量、检查与调整，不用于证明具体项目周数。
• Apple App Review Guidelines：用于核对 iOS 提审时的产品和材料要求，审核状态以 App Store Connect 为准。
• 滚水科技软件开发服务流程：用于了解滚水科技公开的需求、设计、开发、测试和上线阶段。