WWDC25 之后，iOS 26 带来的第一印象很容易被概括成“界面更像玻璃了”。但对已有应用而言，真正需要适配的并不只是给几个按钮加透明效果，而是重新检查内容、导航和系统控件之间的层级关系。Liquid Glass 是一套会随环境、尺寸和交互变化的设计系统；如果把它当成一张静态背景图，最终往往既损失可读性，也错过系统已提供的适配能力。
本文以 2025 年 7 月 20 日前 Apple 在 WWDC25 公布的资料为边界，整理一次面向存量 iOS 应用的观察。它不是发布版兼容性承诺，也不替代在目标 SDK 和系统版本上的实际测试；重点是如何用较小风险看清变化、找到边界，再决定哪里值得采用新 API。
一、先理解：这次变化主要发生在“导航层”
Apple 将 Liquid Glass 描述为兼具玻璃光学特征与流动感的动态材质。它会根据下方内容、显示空间和交互状态调整呈现，以保持内容与控件之间的分离和可读性。这个定义里最重要的词是“动态”：它不是固定透明度、固定阴影或固定模糊半径的替代品。
从现有界面结构看，最先变化的通常是系统导航与控制区域：标签栏、工具栏、搜索、菜单、弹窗，以及标准控件在交互时的外观。内容本身仍应该由内容层承担。WWDC25 的设计建议也很明确：玻璃适合导航层，不宜把它铺满内容层，更不应在玻璃上再叠一层玻璃来制造“更未来”的视觉效果。
这给适配提供了一个简单的判断题：这个元素是在帮助用户浏览、切换、执行短操作，还是在承载需要长时间阅读、编辑或比较的信息？前者可以优先交给系统新外观；后者更需要关注信息密度、文字对比度和滚动时的连续性。
二、第一步不是改代码，而是用最新 SDK 看一遍原界面
对于主要使用 TabView、NavigationStack、NavigationSplitView、系统工具栏和标准控件的应用，最有价值的起点通常是：使用最新 Xcode 与 iOS 26 SDK 编译，在 iOS 26 上直接浏览既有流程。Apple 的适配文档指出，标准 SwiftUI、UIKit 和 AppKit 组件会自动获得新外观与行为；这意味着许多问题首先是结构和层级问题，不需要立刻写自定义材质。
建议按用户任务而不是按页面截图来走查：
- 从冷启动进入最常用路径，观察首屏、导航切换、返回和模态呈现。
- 在浅色、深色、图片密集和长列表背景下，检查工具栏、标签栏和浮动操作是否仍清晰。
- 改变动态字体、增大对比度、减少透明度和减少动态效果，确认关键信息没有只依赖某一种视觉效果。
- 在不同尺寸的 iPhone，以及支持时的 iPad 分屏环境下，观察控件是否遮住内容、点击区域是否仍稳定。
此阶段最好只记录现象，不急着“修复”每处不同。系统组件的形状、间距和滚动边缘效果发生变化，并不天然代表回归；真正的回归是任务无法完成、语义层级混乱或辅助功能路径中断。
三、先清理旧的视觉补丁，再谈自定义玻璃
存量项目常有为旧系统外观叠加的导航栏背景、固定高度、手工模糊、半透明遮罩和强制前景色。这些代码在旧版本也许解决过实际问题，但在动态材质下可能变成双重背景、对比度冲突或不自然的过渡。
清理并不等于删除所有自定义。一个可控的顺序是：先确认系统容器能否直接表达目标结构；再把只为仿系统效果而存在的覆盖层逐项移除；最后保留品牌色、业务状态和内容可读性所需的最小定制。每一次删除或替换都应在深浅色、滚动和辅助功能设置下回归，而不是只看静态截图。
尤其要警惕把透明度当作层级。透明只是视觉属性，层级来自内容、导航和操作之间清晰的职责。当页面既有大图、又有可滚动文字和多组按钮时，应先减少同时争夺注意力的元素，再考虑材质。用模糊掩盖拥挤，通常只会把问题留到更复杂的背景上。
四、SwiftUI 的采用路径：让标准结构先获得新行为
对 SwiftUI 页面，优先保持标准容器和语义化控件。下面的片段只展示 iOS 26 SDK 上可选择采用的新外观；它需要放在已有 SwiftUI 视图的 body 中，不是一个可独立运行的完整工程。
struct ActionsView: View {
var body: some View {
if #available(iOS 26.0, *) {
Button("新建项目", systemImage: "plus") {
// 执行业务动作。
}
.buttonStyle(.glass)
} else {
Button("新建项目", systemImage: "plus") {
// 与新系统保持相同的业务动作。
}
.buttonStyle(.bordered)
}
}
}
这里的重点不是把每个 Button 都换成玻璃样式。#available 让新外观只在 iOS 26 可用时参与编译后的运行路径，旧系统仍使用它们认识的标准样式；两边共享同一业务动作，避免为视觉分支复制状态和网络逻辑。实际页面还应优先检查工具栏、标签栏和导航容器能否自动满足需求，再决定是否需要显式设置按钮样式。
当一组相邻的自定义操作确实需要共同的玻璃形态时，可以使用容器把它们作为一组处理。下面是概念性片段，展示容器应服务于“同一组操作”，而不是为了装饰把不相关控件硬合并：
struct QuickActions: View {
var body: some View {
if #available(iOS 26.0, *) {
GlassEffectContainer(spacing: 12) {
HStack(spacing: 12) {
Image(systemName: "line.3.horizontal.decrease")
.padding(12)
.glassEffect()
Image(systemName: "square.and.arrow.up")
.padding(12)
.glassEffect()
}
}
}
}
}
示例中的图标没有附带业务事件，真实项目应使用可访问的 Button 并提供标签。容器内元素的间距和出现时机也需要稳定；若要让元素在状态切换中产生形变，再为会插入、移除或移动的元素添加稳定的 glassEffectID(_:in:)，而不是给静态图标徒增标识。
五、UIKit 项目先守住系统容器，再审视自绘控件
UIKit 的适配逻辑与 SwiftUI 相同：系统提供的栏、搜索、菜单、弹窗和分栏优先跟随新设计。对于大量 UIViewController 的项目，建议先集中审查三类代码：
- 设置导航栏、标签栏
appearance的全局代码； - 为安全区、栏高度或圆角写死的布局约束；
- 模仿系统模糊与材料的自绘视图。
它们不一定都要废弃，但必须逐个确认仍有业务理由。UIKit 在 iOS 26 也增加了将 Liquid Glass 用于自定义界面的 API；不过在自绘控件已经承担选择、输入、列表和层级等多项职责时，先拆清职责通常比先加材质更重要。只有系统控件无法表达、且自定义元素确实位于导航或操作层时，才值得把新 API 作为最后一步。
六、兼容策略：把“新体验”与“最低可用版本”分开
适配不等于抬高最低系统版本。可以把改动分为三类：
| 类型 | 做法 | 旧系统表现 |
|---|---|---|
| 系统自动更新 | 保持标准容器与控件 | 保留原有系统外观 |
| 结构性修正 | 移除硬编码尺寸、重复背景和错误层级 | 同样获得更稳定布局 |
| iOS 26 增强 | 用可用性判断包裹新 API | 回退到语义相同的标准控件 |
第三类尤其需要避免“功能与外观绑死”。例如某个操作在 iOS 26 使用新样式，旧系统也必须能找到并执行；某个动画在减少动态效果时弱化，状态改变也必须仍可理解。将数据、业务动作和可访问性标签放在分支外或两端保持一致，才能让差异停留在呈现层。
七、最后用真实环境验证，而不是只相信预览图
Liquid Glass 的价值恰恰在于对背景、尺寸和交互的适应，因此静态设计图只能发现一部分问题。发布前至少应覆盖：长内容滚动穿过导航区域、图片或视频背景、浅深色模式、文本放大、减少透明度、增加对比度、减少动态效果、旋转或窗口尺寸变化，以及多次推入和返回后的导航状态。
测试结果应描述任务是否完成，而不只写“看起来正常”。例如“在减少透明度下仍能辨认主操作”“滚动到长标题时搜索和返回可用”“旧系统上不出现缺失符号或不可点击区域”。这类描述能同时约束设计、实现和回归测试。
截至 WWDC25，最务实的结论是：先让系统组件做它们本来擅长的适配，再把自定义玻璃严格限制在有明确层级意义的少数地方。这样既能获得新系统的统一感，也能保留存量应用最重要的品质——稳定、清楚且可访问。