示例代码均为匿名化改写，用于说明模式；具体状态持久化与依赖由应用实现。
启动不只是显示一张图片
启动阶段往往要同时处理系统回调、隐私确认、凭据恢复和主界面依赖。若把所有工作塞进单个视图的出现回调，页面可能先展示未登录状态，第三方 SDK 也可能在用户同意前启动。
一个更清晰的拆分是：应用入口负责创建共享依赖并连接系统生命周期；根页面负责隐私确认、启动画面和登录恢复；栏目容器只在准备就绪后创建导航栈。这样各层只回答自己负责的问题。
状态推进顺序
首次启动时先呈现启动画面和不可意外关闭的隐私确认。用户同意后持久化选择、更新相关 SDK 的隐私配置，再恢复安全存储中的登录会话。动画完成、隐私确认和会话恢复都结束后，才进入主界面。
已确认过的用户可以并行恢复会话和播放短暂启动动画，避免界面先闪出错误的登录状态。协议文案中的文档链接也应由根页面集中处理，而不是散落在业务页。
一个最小的启动门闩可以把进入主界面的条件写清楚：
@MainActor
final class LaunchCoordinator {
var didAcceptPrivacy = false
var didRestoreSession = false
var canShowMainInterface: Bool {
didAcceptPrivacy && didRestoreSession
}
}动画完成与业务就绪应是两条独立条件：动画只控制视觉节奏，隐私选择和会话恢复完成后才进入主界面。用户同意状态需要持久化，第三方 SDK 也应在隐私配置完成后初始化。
需要守住的边界
启动动画延迟只应服务于视觉节奏，不要变成业务数据请求的固定等待。如果之后加入远端配置、版本校验等阻塞条件，应建模为可辨认的启动状态，而不是不断叠加无名的延时任务。
隐私确认和会话恢复之间存在取消路径。应确保应用在中断后能从持久化状态继续，并验证 SDK 初始化时机。代码只能保证顺序和跳转，不能替代隐私文本及合规内容的审核。
适用场景
- 首次运行需要先取得用户同意的应用。
- 登录凭据需要在进入主界面前异步恢复。
- 第三方回调需要由应用入口接收，再路由到具体业务页。