从 SwiftUI 概念到 App Store：数周内完成

iOS 项目常遇到一种特定的延期：原定“几周内”发布的功能，三个月后仍在开发，因为范围不断扩大，提交流程的步骤也比预期多。实际上，快速发布 SwiftUI 应用的关键不在开发速度，而在于及早决定应用不做什么，并在想再加一个功能时坚持这个决定。

我们曾在短期内发布多款 SwiftUI 应用。这套流程可以重复，但需要严格控制范围、清楚理解 Apple 的提交流程，并愿意发布质量良好但功能尚未齐全的产品。以下是具体做法。

首次提交代码前就要确定范围

快速发布 iOS 应用，最重要的工作发生在编码之前。要问的不是“这个应用应该做什么”，而是“第一版为用户解决的那个问题是什么”。与这个问题没有直接关系的功能，都留到第二版。

这比听起来更难，因为从零开始设计时，几乎每项功能都显得相关。通知似乎重要，社交功能似乎重要，详细的分析仪表盘也似乎重要。但实际上，用户只有先使用核心功能并认可其价值，才能评价这些附加功能。四周内发布、做好一件事的应用，比四个月后发布、六件事都做得尚可的应用，能带来更有用的反馈。

一个实用工具是开发前写好的两栏清单：MVP 包含什么，以及明确推迟什么。推迟清单不是待办清单，而是强制约束。项目进行中，每项新增功能都应先判断：它是否更适合进入推迟清单，而非当前迭代？大多数都应该推迟。

前两周：只做核心界面

目标单一且明确的 SwiftUI 应用，通常需要三到五个界面就能运行：新用户引导、一两个核心交互界面，以及设置或账户界面。前两周应让这些界面在功能上完整可用：使用真实数据，按正确顺序完成各自的任务。此时无须精雕细琢。动画和字体可以用系统默认，错误状态可以用简单的文本提示。

这一阶段重要的架构决策，是后期难以更改的那些：导航模型（NavigationStack、TabView 或自定义协调器）、状态管理方式（使用 Observation 框架的 @Observable，还是继续采用 ObservableObject），以及数据持久化策略（SwiftData、Core Data，或用 UserDefaults 保存简单状态）。及早明确这些选择，而不是让它们在开发中自然形成，可以避免到了第三周才发现应用的一半使用一种导航模型，另一半使用另一种。

集成 Supabase 后端的应用，在这一阶段尤其需要关注身份验证流程。Apple 的 App Review 指南将其视为两项独立要求：支持创建账户的应用必须允许用户在应用内删除账户（指南 5.1.1(v)）；使用 Google Sign-In 等第三方或社交登录方式来登录主要账户的应用，还必须提供注重隐私的同等登录选项，实际中通常是 Sign in with Apple（指南 4.8）。如果应用仅通过 Supabase 使用自己的邮箱和密码身份验证系统，就不必提供 Sign in with Apple，但账户删除流程必须纳入 MVP。这不是因为用户第一天就会用到，而是因为缺少这一功能会被 App Review 拒绝。如果添加社交登录，应同时规划同等的登录选项。

第三、四周：完善体验与 TestFlight

第三周，应用开始具备正式产品的样子。此时要处理加载状态（不只是“显示加载指示器”，而是“让加载指示器使等待显得合理”）、空状态（尚无数据时显示什么），以及错误状态（网络请求失败时如何处理）。这些不只是界面润色，而是新用户的实际体验：他们刚开始没有数据，也偶尔会遇到网络问题。

TestFlight 分发应从第三周开始，而非第四周。原因是第一次上传的构建会暴露出预料之外的问题。App Store Connect 在开放测试前会验证二进制文件，发现本地 Xcode 构建未暴露的问题，例如缺少权限声明、配置描述文件组合不正确，或缺少必需的 Info.plist 键。第三周遇到这些问题，才能在正式提交前留出修复时间；等到计划上线的前一晚才发现，就来不及了。

这一阶段，TestFlight 反馈最适合用来发现导航不清和操作入口缺失，而不是收集功能请求。应问测试者：“有没有您想做，却不知道如何操作的事？”而不是“您希望增加哪些功能？”后一个问题会产生一份足以将开发周期延长数月的清单。

App Store 提交流程

App Store 提交流程的步骤比初次提交者预期的更多，每一步都有可能阻碍发布。提前完成这些准备，而不是等应用代码全部完成后才开始，可以避免最后一周手忙脚乱。

提交前必须准备截图，尺寸必须符合相应屏幕尺寸所接受的像素规格之一。截至 2026 年 10 月，App Store Connect 要求提供 6.9 英寸屏幕类别（例如 iPhone 16 Pro Max）的 iPhone 截图；如果不提供 6.9 英寸截图，则须提供 6.5 英寸屏幕类别（例如 iPhone 14 Plus）的截图。如果应用可在 iPad 上运行，还需提供 13 英寸 iPad 截图（例如 iPad Pro（M4）或 12.9 英寸 iPad Pro（第 6 代））。用 Simulator 生成截图并不复杂，但留到最后一天会很耗时。简单的 Fastlane snapshot 配置就能将其自动化。

App Store Connect 的“应用隐私”部分要求声明应用收集的每种数据、用途，以及是否关联用户身份。这不是可选的元数据：填写不完整就无法提交。如果应用使用 Supabase 进行身份验证，至少会收集邮箱地址和用户标识符，两者都必须披露。第三方 SDK 和分析工具还会增加需要披露的项目。提交前准确梳理数据收集情况，可以避免上线后再修改这些信息。

Apple 表示，通常会在不到 24 小时内审核 50% 的提交，在不到 48 小时内审核 90% 的提交；如有特殊情况，例如修复严重错误或配合活动发布，可以申请加急审核。审核由人员对照 Apple 指南检查应用。首次提交最常见的拒绝原因包括：缺少账户功能（应用内账户删除，或在社交登录之外提供同等的登录选项），需要登录的应用未提供演示账户凭据，以及测试者未遇到、审核人员却遇到的边界场景崩溃。

哪些功能该删减，如何删减

快速发布最难的部分，是让删减显得经过考虑，而非仓促应付。用户能分辨刻意保持简单的应用和未完成的应用。区别主要在于已有功能是否完整：每个现有界面都应该完整，而不是界面数量有多少。

首版通常可以删减的功能包括：推送通知（正确配置较复杂，用户也需要先信任应用，才会欢迎通知）、社交功能（关注、分享、排行榜在用户规模较大时有用，上线初期却容易分散注意力）、高级个性化设置（多数用户从不更改默认设置），以及任何需要大量后端基础设施、而 MVP 原本并不需要这些设施的功能。

会损害首版体验的删减包括：错误处理（网络超时就崩溃的应用，会给用户留下持久的负面印象）、加载状态（卡住且没有视觉反馈的应用，看起来像出了故障），以及账户管理基础功能（即使是 MVP，用户也需要能重置密码和删除账户）。

上线后：前两周最重要

上线后前两周，App Store 评分最容易受到影响。测试中未出现的崩溃若在早期引发集中一星评价，会对长期评分造成不成比例的损害。第一周应每天检查 Instruments 和 Xcode 的崩溃管理器。发现严重崩溃后，应在 24 小时内提交修复版本；App Review 为崩溃修复提供加急审核通道。

上线后，至少两周内应抵制立即发布推迟功能的冲动。增加复杂度之前，先了解用户如何实际使用核心体验，比展示持续发布的势头更有价值。观察两周真实使用情况后，再设计推迟清单中的第二版功能，会比与首发并行开发时设计得更好。