应用开发指南：成本、时间与常见问题

首先确定是否需要应用程序

最昂贵的应用程序决策在任何代码编写之前就已做出：是否要构建它。

应用程序必须在商店中找到、安装、获取权限，然后保留在用户定期清理的主屏幕上。这是一系列摩擦。只有在以下情况下，这种摩擦才值得克服：

• 离线功能 —— 现场工作人员、配送司机、信号不稳定的任何地方
• 推送通知 —— 真正有用的通知，而非营销广播
• 设备硬件 —— 相机流、蓝牙外设、后台定位
• 高频使用 —— 大多数日子都会打开的应用，节省三秒钟就能累积显著效果

如果以上都不适用，一个快速且优质的移动网站能以更低成本触达更多人。我们经常这样告诉客户，而这通常是首次通话中最有价值的建议。

英国应用程序的实际成本

公开的"应用成本计算器"都是营销工具。以下是我们报价的参考范围，针对的是英国专业代理商：

范围	典型价格区间
单平台，专注功能集	£15,000 – £30,000
跨平台，iOS 与 Android	£22,000 – £45,000
包含支付、实时数据或离线同步	£35,000 – £70,000
持续维护（每年）	建设成本的15–20%

最后一行是大多数预算忽略的部分，而它并非可选。iOS 和 Android 每年发布一个主要版本。Google 每年提高目标 API 要求并下架未达标的应用。没有维护预算的应用，实际可用寿命约为两年。

任何报价低于 £8,000 的应用，要么是白标模板，要么是固定价格——一旦遇到棘手问题，价格将被重新协商。

原生应用还是跨平台

这是最影响成本的决策，因此值得明确权衡，而非视为品味问题。

跨平台（Flutter、React Native）意味着使用同一套代码生成两个应用。你可节省约30–40%的开发成本，长期来看更能省下大笔费用，因为只需维护一套功能同步，而非两套。对于大多数商业应用——预订、下单、仪表板、内部工具——用户无法察觉差异。

原生（Swift、Kotlin）意味着两套代码库和两套平台专业知识。当应用严重依赖设备功能时，这是正确选择：持续相机处理、后台位置跟踪、ARKit，或动画复杂到中间渲染层变得明显。

次要问题是谁来维护。若你的团队已在用React，React Native能让他们与网页应用共享技能和部分代码，通常优于Flutter的技术优势。若你完全没有内部移动开发能力，Flutter是更稳妥的技术选择。无论如何，你将招聘的市场比基准测试更重要。

预算如何悄悄超支

我们接手的项目中，有五大因素导致大部分超支。

1. 离线行为被视为边缘情况

「它需要离线运行」听起来像一个功能。实际上这是架构问题。将本地存储和冲突解决机制植入一个围绕实时API构建的应用，几乎等同于重写。第一周就应决定此事。

2. 推送通知最后才加入

推送通知需要服务器基础设施、权限流程、分段和深层链接（打开正确页面）。若在最后阶段才加入，往往沦为「给所有人发相同消息」，用户会因此关闭通知——丧失应用原本用于提升留存的功能。

3. 未规划应用商店审核流程

首次提交到Apple通常会被拒。不是因为严重问题：隐私说明、订阅条款不明确、缺少账户删除功能、通用应用在iPad上的展示问题。若排期未预留一到两轮审核时间，排期必然会公开延期。

4. 后端被视为事后考虑

大多数应用是某项服务的前端。若该服务不存在，你其实在委托两个项目。若后端已存在，其API通常为网站设计，需为移动端重构——更简洁的端点、分页、适配移动连接的有效负载。

5. 仅在一台旗舰设备上测试

这主要是Android问题，且影响巨大。一款在最新旗舰机上运行流畅的应用，可能在英国大量用户使用的中端手机上无法使用。再加上制造商的电池管理器会终止后台进程，「通知停止工作」会成为你最常见的支持工单。

合理的时间线

对于跨平台商业应用：

1. 范围与设计 — 3至4周。功能清单、流程和界面设计在真机上审核。
2. 核心开发 — 8至12周，分为两周一个周期，每个周期结束时交付可安装的版本。
3. Beta测试 — 2周，真实用户在TestFlight和Google Play内测渠道测试。
4. 商店提交 — 1至3周，包括可能的审核往返。
5. 上线后 — 30天修复期，之后进入维护阶段。

总计约四到五个月。压缩时间通常意味着省去Beta测试，而这正是能避免用户在商店评论中公开报告问题的关键环节。

签约前应向任何供应商提的问题

• 谁拥有代码，我们能否获得代码仓库？
• 开发者账户是注册在我们名下还是你们名下？
• 若Apple拒绝提交，是否额外收费？
• 年维护费用是多少，是否有书面约定？
• 你们会在哪些具体设备上测试？
• 若我们终止合作，应用会如何处理？

这六个问题的答案比任何作品集都更有说服力。若任何问题引发犹豫，这就是答案。

下一步

若你在权衡是否开发应用，有用的首次对话不是关于功能——而是应用是否适合解决问题。我们乐意进行这场对话，并告诉你答案可能是一个网站。