Meet Assistive Access

Highlight

Apple 在 iOS 17 和 iPadOS 17 中引入了 Assistive Access（辅助访问），这是一种系统级模式，由信任的支持者在设置中配置后，将设备界面精简到核心功能。第三方 App 无需任何修改即可在该模式下运行；适配自适应布局的 App 可通过一个 Info.plist 键启用全屏显示。

核心内容

iPhone 和 iPad 功能强大，但对有认知障碍的人来说，过多的选项和交互反而构成障碍。一个普通用户打开手机后面对的是几十个 App 图标、通知、搜索栏、小组件——这些元素要求用户具备筛选信息、记忆操作路径和抑制无关干扰的能力。Apple 的 Accessibility 团队此前提供的旁白、辅助触控等功能主要解决视觉和肢体问题，对认知障碍的支持一直存在空白。

Assistive Access 填补了这块空白。它是一套完整的系统级模式：从锁屏、主屏幕到每个 App 内部的交互方式都经过重新设计。

配置过程由信任的支持者在”设置” App 中完成。支持者选择哪些 App 可以运行、是否显示电池图标、设置锁屏壁纸。配置完成后，通过辅助功能快捷键或设置中切换即可进入 Assistive Access 模式。

进入该模式后，用户看到的是一个完全不同的界面：锁屏有定制的壁纸和通知展示方式，主屏幕上 App 图标更大、文字更醒目。Apple 为五个核心功能重写了专用 App：电话（Calls）、信息（Messages）、音乐（Music）、相机（Camera）和照片（Photos）。每个 App 都只保留最基本的功能路径，去掉多余选项。

对于第三方 App，系统默认行为是自动兼容：App 在一个缩小后的区域内运行，屏幕底部有一个大的返回按钮。按下返回按钮回到主屏幕。这个设计保证了即使 App 内部有硬编码的布局，也不会因为 Assistive Access 而变形。

如果 App 已经使用自适应布局（不依赖固定屏幕尺寸），开发者可以通过 Info.plist 中的一个键申请全屏显示，去掉底部返回按钮占用的空间，让 App 使用全部可用面积。

详细内容

三个设计原则

（02:55）Assistive Access 的整个设计建立在三个原则上。

第一，减少选项。 每一步操作面临的选择越少，用户就越容易做出决定。这体现在主屏幕只显示被允许的 App、每个 App 内部只保留核心功能路径、去掉多余的导航层级。

第二，错误预防与恢复。 删除文件这类有后果的操作必须给出明确提示，让用户理解后果后再确认。减少有时间限制的操作。任何操作都应该可以轻松回退。

第三，熟悉且可预测的交互。 使用文字加图片的多模态方式呈现信息，用一致的交互模式降低学习成本。

第三方 App 的默认行为

（04:46）第三方 App 在 Assistive Access 下”开箱即用”。系统自动做了两件事：

1. 在屏幕底部添加一个大的返回按钮
2. 将 App 的渲染区域缩小，为返回按钮留出空间

这保证了即使 App 内部使用了基于设备屏幕尺寸的硬编码布局，显示效果也不会出问题。用户点击返回按钮回到主屏幕。

不需要写任何代码，不需要适配。这是默认行为。

启用全屏模式

（05:29）如果你的 App 已经支持自适应布局，可以通过在 Info.plist 中添加一个键来申请全屏显示：

<key>UISupportsFullScreenInAssistiveAccess</key>
<true/>

设置这个键为 YES 后，系统不再为 App 添加底部的返回按钮。App 的渲染区域扩展到整个屏幕。

关键点：

• 这个键仅在 App 使用了自适应布局时才应该设置为 YES。如果 App 有硬编码的屏幕尺寸假设，全屏模式下可能出现布局异常
• 设为 YES 后，系统仍会在屏幕顶部保留状态栏，但底部不再有额外的返回区域
• 这个键对 SwiftUI 和 UIKit App 都适用

SwiftUI 的自适应布局策略

（06:28）SwiftUI 开发者需要关注使用 Stacks 和 Grids 作为布局容器，而非手动计算位置：

struct ContentView: View {
    var body: some View {
        VStack {
            HStack {
                Text("标题")
                Spacer()
                Button("操作") { }
            }
            LazyVGrid(columns: [GridItem(.adaptive(minimum: 80))]) {
                ForEach(items) { item in
                    ItemView(item: item)
                }
            }
        }
        .padding()
    }
}

关键点：

• VStack 和 HStack 自动适应容器尺寸，不需要手动设置 frame
• LazyVGrid 配合 .adaptive(minimum:) 可以在不同宽度下自动调整列数
• .padding() 等修饰符基于系统安全区域自动计算边距
• 不要使用 UIScreen.main.bounds 或类似的固定尺寸值

UIKit 的自适应布局策略

（06:56）UIKit 开发者需要依赖两个关键特性：Safe Area 和 Layout Guide。

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()

        let label = UILabel()
        label.text = "Hello"
        label.translatesAutoresizingMaskIntoConstraints = false
        view.addSubview(label)

        NSLayoutConstraint.activate([
            label.topAnchor.constraint(
                equalTo: view.safeAreaLayoutGuide.topAnchor,
                constant: 20
            ),
            label.leadingAnchor.constraint(
                equalTo: view.safeAreaLayoutGuide.leadingAnchor,
                constant: 16
            ),
            label.trailingAnchor.constraint(
                equalTo: view.safeAreaLayoutGuide.trailingAnchor,
                constant: -16
            )
        ])
    }
}

关键点：

• safeAreaLayoutGuide 代替直接使用 view.topAnchor 等，确保内容不被系统元素遮挡
• 在 Assistive Access 全屏模式下，Safe Area 会自动调整，移除底部返回按钮的占位
• safeAreaInsets 属性可以在运行时读取当前安全区域的具体数值，用于自定义布局计算
• 不要硬编码基于设备型号的尺寸判断

核心启发

1. 为现有 App 启用 Assistive Access 全屏模式

   • 检查 App 布局是否已完全自适应。如果已经使用 SwiftUI Stacks/Grids 或 UIKit Auto Layout + Safe Area，只需在 Info.plist 中加一行 UISupportsFullScreenInAssistiveAccess = YES
   • 为什么值得做：这是成本最低的辅助功能改进，一行配置就能让认知障碍用户获得更好的体验
   • 怎么开始：先在本地进入 Assistive Access 模式，观察默认行为下的 App 表现，再决定是否启用全屏

2. 改造仍有硬编码布局的页面

   • 如果 App 使用了 UIScreen.main.bounds、UIDevice.current.model 或类似的设备特定判断，将其替换为 Safe Area 和自适应布局
   • 为什么值得做：除了适配 Assistive Access，这些改动也会让 App 在分屏、台前调度、外接显示器等场景下表现更好
   • 怎么开始：用 Xcode 的 View Hierarchy 工具定位硬编码布局的视图，逐个替换为 Auto Layout 约束或 SwiftUI Stacks

3. 为认知障碍用户设计专用的简化界面

   • 在 App 内部提供一个开关，开启后隐藏高级功能、增大字体和按钮、减少导航层级
   • 为什么值得做：不是所有认知障碍用户都会或愿意启用系统级的 Assistive Access。App 内置的简化模式门槛更低
   • 怎么开始：参考 Assistive Access 的三个设计原则（减少选项、错误预防、可预测交互），在 App 设置中加一个”简化模式”开关

4. 重新审视 App 的错误处理交互

   • 检查删除、支付、登出等操作是否给了用户足够的确认机会
   • 为什么值得做：好的错误预防对所有用户都有价值，不仅仅是认知障碍用户
   • 怎么开始：审计 App 中所有不可逆操作，为每个操作添加确认弹窗和撤销路径

关联 Session

• Build accessible apps with SwiftUI and UIKit — SwiftUI 和 UIKit 中的无障碍功能最新进展，与 Assistive Access 的自适应布局要求直接相关
• What’s new in SwiftUI — SwiftUI 的新布局能力，是实现 Assistive Access 全屏自适应布局的基础
• What’s new in UIKit — UIKit 的最新增强，包括构建自适应现代界面的新功能