iPhone Duo 应用适配指南:苹果折叠屏来了,iOS 开发者需要注意什么?
苹果正式带来了 iPhone Duo。 作为苹果第一款折叠形态的 iPhone,它带来的变化其实不只是“iPhone 多了一个新的屏幕尺寸”。
苹果正式带来了 iPhone Duo。
作为苹果第一款折叠形态的 iPhone,它带来的变化其实不只是“iPhone 多了一个新的屏幕尺寸”。
对于开发者来说,更重要的变化是:
以后一个 iPhone App,可能需要在完全不同的可用空间之间连续切换。
设备合起来时,用户使用外屏;展开以后,App 获得更大的内部显示空间;设备还可能处于部分折叠状态,甚至和另一个 App 一起运行在 Split View 中。
所以最近我也专门看了一下 Apple 官方刚刚发布的 iPhone Duo Human Interface Guidelines 和相关开发资料。
如果你手里已经有一个 iOS App,下面这些地方尤其值得检查。
一、先说一个好消息:大部分 App 不需要重新做
看到折叠屏,第一反应可能是:
我是不是得给 iPhone Duo 单独开发一套 UI?
实际上并不是。
Apple 在官方设计指南里专门强调了一点:
iPhone Duo 虽然是一种新的设备形态,但开发者仍然是在为 iPhone 设计 App。
如果你的 App 本身使用的是标准系统组件,并且 UI 已经能够随着可用空间变化,那么很多适配工作系统本身就能够完成。
比如常见的:
- NavigationStack
- NavigationSplitView
- List
- ScrollView
- TabView
- Toolbar
这些系统组件本身就具备比较强的自适应能力。
反而真正容易出现问题的,往往是以前为了某个固定 iPhone 尺寸“写死”的 UI。
所以与其说 iPhone Duo 带来了一套新的开发规则,不如说它开始真正检验一个 App 的布局是不是足够 Adaptive。
二、不要再简单根据“横屏 / 竖屏”决定 UI
这是我觉得现有 App 最值得检查的一点。
过去开发 iPhone App 时,我们很容易形成一种思维:
竖屏显示一种布局,横屏显示另一种布局。
但到了 iPhone Duo,这种判断方式就没有以前那么可靠了。
因为开发者真正应该关心的,不是:
手机现在到底是横着还是竖着?
而是:
我的 App 现在到底有多少可用空间?
Apple 推荐开发者更多通过 Size Class 和实际可用空间决定界面。
例如 SwiftUI 中可以读取:
@Environment(\.horizontalSizeClass)
private var horizontalSizeClass
然后根据 Compact / Regular 等环境变化调整布局。
这个思维上的变化非常重要。
以后不要先问:
“现在是不是横屏?”
而应该先问:
“现在的空间够不够显示第二栏?”
三、外屏和内屏,不应该只是简单地把 App 放大
如果只是把原来的 iPhone UI 等比例拉大,其实有点浪费 iPhone Duo。
Apple 官方用 Mail 举了一个很容易理解的例子。
设备合起来的时候,可以只显示:
邮件列表
↓
邮件详情
但是设备展开以后,有了更多横向空间,就可以变成:
┌──────────────┬─────────────────────┐
│ │ │
│ 邮件列表 │ 邮件详情 │
│ │ │
└──────────────┴─────────────────────┘
用户不需要来回跳转。
同样的思路其实适用于非常多 App:
笔记列表 | 笔记内容
文件列表 | 文件预览
聊天列表 | 聊天内容
文章列表 | 阅读页面
商品列表 | 商品详情
AI 对话列表 | 当前对话
这可能也是 iPhone Duo 给开发者带来的第一个真正有意思的产品机会:
过去在普通 iPhone 上因为屏幕太小无法实现的双栏、多栏交互,现在终于可以自然地出现在手机上。
四、NavigationSplitView 会变得更加重要
如果你的 App 天然存在“列表 + 详情”这样的信息层级,那么现在很值得重新看看 NavigationSplitView。
在较小空间下,它可以收缩成单栏导航。
空间足够时,又可以自然展开成多栏。
这恰好符合 iPhone Duo 的使用方式:
外屏
┌─────────────┐
│ │
│ List │
│ │
└─────────────┘
展开:
┌─────────────┬─────────────────┐
│ │ │
│ List │ Detail │
│ │ │
└─────────────┴─────────────────┘
相比自己监听屏幕尺寸,然后手动切换两套 View,这种方式通常也更符合 Apple 的适配思路。
五、Safe Area 这次真的不能忽略了
过去做普通 iPhone App,有些布局即使 Safe Area 处理得不够严谨,可能也不太容易暴露问题。
到了 iPhone Duo,这件事情会明显重要很多。
原因是设备上出现了更多会影响内容布局的区域。
Apple 在新的设计指南中专门介绍了 Reserved Regions。
其中包括:
外屏前置摄像头区域
这个区域始终存在,并且可能和 Dynamic Island 等系统 UI 产生关系。
内屏摄像头区域
内屏摄像头在特定状态下会影响可用空间。
Folding Region
当设备处于部分折叠状态时,中间的折叠区域会影响内容能够正常显示和交互的位置。
因此有一个以前很容易写出来的假设,现在尤其需要小心:
左侧 Safe Area = 右侧 Safe Area
在 iPhone Duo 上,布局很可能天然就是不对称的。
如果 App 中存在大量通过固定坐标计算出来的按钮、浮层或者自定义导航栏,就尤其值得检查。
六、不要把重要操作放在折叠区域
折叠屏还有一个普通 iPhone 不存在的问题:
物理折叠本身会影响交互。
设备处于部分展开状态时,内屏中间会形成 Folding Region。
如果一个非常重要的按钮、拖拽区域或者交互元素刚好位于这里,体验就会非常奇怪。
好消息是,如果使用系统提供的标准组件,很多情况下系统会自动避让这些区域。
例如菜单、Sheet、Alert、Split View 等系统 UI 都会根据可用区域进行调整。
真正需要开发者重点检查的,还是高度自定义的 UI。
特别是那些:
position(x:y:)
固定 Frame
GeometryReader + 手动坐标
自定义浮动按钮
自定义 Toolbar
这类布局尤其值得在 Duo 上重新测试。
七、工具栏可能不再出现在你熟悉的位置
这也是 iPhone Duo 一个很有意思的变化。
因为 Duo 外屏的比例和传统 iPhone 不一样,在部分使用状态下,系统会把原本位于顶部或底部的:
- Toolbar
- Tab Bar
- Navigation Controls
移动到屏幕侧边。
这么做的目的,是把宝贵的纵向空间更多地留给内容。
对于使用标准系统组件的 App 来说,这通常不需要开发者自己重新实现。
但如果你的 App 自己画了一整套 Navigation Bar、Tab Bar 或 Toolbar,那么最好重点检查一下 Duo 上的表现。
这也是为什么 Apple 一直鼓励开发者尽可能使用标准系统组件。
因为设备形态发生变化的时候,系统组件往往可以自动获得新的平台行为。
八、不要为折叠屏写四五套 UI
看到折叠屏以后,还有一个很容易出现的误区:
if closed {
ClosedLayout()
}
if halfFolded {
HalfFoldLayout()
}
if opened {
OpenLayout()
}
if landscape {
LandscapeLayout()
}
这样写下去,后面的维护成本会非常高。
Apple 的思路其实恰恰相反:
不要针对每一种设备姿态重新设计 App。
应该让现有布局根据可用空间自然扩展和收缩。
小空间的时候显示核心内容。
空间变大以后,可以增加第二级信息。
再大的空间,可以进一步利用多栏布局。
也就是说:
Device State 不应该决定整个 App 长什么样,可用空间才应该决定内容如何排列。
这也是 Responsive Web Design 已经用了很多年的思想,现在它在 iPhone App 上变得越来越重要了。
九、折叠和展开时,不要让用户“重新开始”
还有一个容易忽略的问题:
状态连续性。
假设用户正在阅读一篇文章。
他把 iPhone Duo 从外屏状态展开。
这时候最糟糕的体验就是:
页面重新加载,滚动位置消失,当前选择丢失,甚至重新回到首页。
正确的体验应该是:
设备变了,App 没变。
只是原来的内容获得了更多空间。
比如原来:
文章详情
展开以后:
文章目录 | 文章详情
用户依然停留在刚才阅读的位置。
所以开发者测试 Duo 时,不应该只测试几个静态截图。
更应该测试:
使用 App → 展开 → 折叠 → 半折叠 → 再展开
整个过程中,用户正在做的事情有没有被打断。
十、视频、游戏和沉浸式 App 要特别检查比例
对于普通信息类 App,更大的内屏通常意味着更多内容。
但视频和游戏不一定。
尤其是固定比例的视频内容,在新的屏幕比例下很可能产生更多留白。
这时候开发者就需要决定:
是保持完整画面?
还是允许裁切填满?
还是把多出来的空间拿来放播放控制、标题、评论或者其他信息?
游戏也是一样。
Apple 建议游戏在不同设备姿态变化时尽量填满可用空间,并保持文字和操作控件尺寸稳定。
换句话说:
不要简单把原来的画面套进一个更大的黑色矩形里。
十一、旧 App 会不会直接不能用了?
这可能是很多独立开发者最关心的问题。
答案没有那么可怕。
iPhone Duo 并不是要求所有 App 在设备上市当天全部重新开发。
原有 App 仍然可以运行。
真正的问题更多是:
“能运行”和“适配得好”是两回事。
一个没有针对新形态优化的 App,可能依然能够打开、浏览、操作。
但是展开设备以后,它可能只是把原来的手机界面放在一块更大的屏幕里。
而另外一个认真做过 Adaptive Layout 的 App,则可能立即变成:
Sidebar | Content | Inspector
两者的体验差距会非常明显。
十二、如果你已经有一个 iOS App,可以先检查这 10 项
我自己整理了一份比较简单的 Checklist:
① 有没有大量固定 Width / Height?
② 有没有根据 Portrait / Landscape 决定整个 UI?
③ 有没有正确使用 Size Class?
④ Safe Area 有没有被正确处理?
⑤ 有没有假定左右 Safe Area 一定对称?
⑥ Navigation、Toolbar、Tab Bar 是否尽量使用系统组件?
⑦ 自定义 UI 会不会落在 Folding Region?
⑧ App 展开以后,是否可以利用更大的空间增加信息层级?
⑨ List + Detail 类页面是否适合 NavigationSplitView?
⑩ 折叠、展开过程中,用户当前的操作状态能不能保持?
如果这十个问题基本都没有问题,我觉得很多 App 的 Duo 适配工作量其实没有想象中那么大。
最后
看完 Apple 这次的设计指南以后,我最大的感受反而不是:
“又要适配一个新的 iPhone 了。”
而是:
iPhone 的 App 设计边界变大了。
过去很多适合 iPad、Mac 的交互,因为普通 iPhone 的空间太小,很难真正搬到手机上。
但 Duo 展开以后,List + Detail、多栏布局、编辑器 + Preview、Chat + Context、文件列表 + 内容