苹果于 2026 年 9 月 9 日发布了首款折叠屏 iPhone——iPhone Duo。预售从 10 月 16 日开始，10 月 23 日正式开卖，系统版本为 iOS 27.1。奇怪的地方在于节奏：苹果在同一天就公布了适配规则，但带 Duo 模拟器的 SDK 要到”9 月晚些时候”才会放出。文档已经就位，硬件却基本还没到手——这正是排查应用里那些曾经成立、现在悄悄失效的布局假设的最佳窗口期。对于用 FCM/APNs 触达海外用户的出海团队来说，这个窗口期同样适用：你的海外用户不会等你的下一个版本周期。
这篇指南不聊设备评测，那种文章接下来会有一百篇。推送通知本身由系统绘制，这部分不需要改动。真正需要处理的，是应用自己绘制的一切内容——应用内消息、富媒体、推送权限引导页、加载态——这些内容现在必须在会话进行中屏幕形状和宽高比随时变化的情况下依然成立。这正是苹果这次新写规则覆盖的部分，也是大多数团队即将直接错过的部分。
iOS 27 到底给折叠屏 iPhone 带来了什么变化
iPhone Duo 有两块宽高比接近但不完全相同的屏幕。内屏 7.6 英寸，屏幕面积比 iPhone 18 Pro Max 大约多 50%；外屏 5.4 英寸，屏幕面积约为 iPhone 18 Pro 的 90%。两块屏幕比例接近但并不一致，这也是为什么布局应该由 size class 驱动，而不是假设某个固定比例在两块屏幕上都成立。
每个应用都参与 Split View。Duo 是第一款能同时运行你应用多个界面实例的 iPhone，这意味着你的应用内消息完全可能出现在半屏，紧挨着别人家的应用。
而且屏幕形状会在会话进行中改变。用户可能在你的弹窗还开着的时候展开手机，或者半展开。布局不再是只在启动时决定一次的事情。
三个兼容层级，大多数应用会落在哪一档
苹果的规则很直白：你的应用不用重新编译就能在 Duo 上运行。问题在于它能拿到多少屏幕空间，这取决于你构建时用的 SDK 版本。
- 旧版 SDK： 能运行，但内容会被限制在手机形状的区域里。
- iOS 27 SDK： 界面可以在内屏上延伸到状态栏区域左侧。
- iOS 27.1 SDK： 界面可以铺到屏幕边缘，标准导航栏和工具栏按钮会纵向排列。
也就是说，什么都不做的团队，会把应用内消息以手机大小的方框，直接塞进一块 7.6 英寸的屏幕里。这不算崩坏，只是明显地毫无用心——旁边可能就站着一个认真适配过的竞品。
你的应用内消息布局为什么会失效
三个原因，而且会叠加。
宽高比变了。 大多数应用内消息和富媒体模板，都是按普通 iPhone 的比例设计的。内屏的比例不一样，按旧比例画的模板不会落在你原本设计的位置上。
方向不是正确的判断信号。 内屏在两个 size class 下都是 regular，也不遵循应用声明支持的界面方向。任何按屏幕方向分支的布局逻辑，读取的都是内屏根本不响应的信号。苹果的说法很直接：用 size class 决定布局，而不是方向。
安全区是不对称的。 Duo 上的 inset 和布局边距经常两侧不一样，所以每条边都要单独处理，不能假设一个对称的边框。然后再放到 Split View 里测一遍，那里边框又会变窄。
手机展开的瞬间，正好有一条应用内消息弹出
这是最值得提前想清楚的情况，因为目前还没有任何模拟器能让人实际看到它：一条模态应用内消息正显示在屏幕上，用户把手机展开了。已经呈现的视图下面，画面尺寸整个变了。
苹果在这里给了两套工具，混用是最容易犯的错误。
hinge API——SwiftUI 里的 onHingeChange，UIKit 里的 UIHingeInteraction——上报的是一个离散状态（关闭、部分展开、完全展开）加一个连续角度。它们是给实时监听、驱动交互和特效用的。苹果自己的演示是用折叠角度去弯曲一个虚拟乐器的音高。这是它们该出现的场景，不是用来挪动你的按钮的。
布局走的是另一套通道。苹果在”Strike a pose with adaptive layouts on iPhone Duo”这场演讲里指向的是排布（arrangement）和区域（region）相关 API，里面引入了 reserved region、带 split 和 overlay 布局的 arrangement view，以及 displacement——把已有元素重新安放到当前实际可用的空间里，让内容在设备折叠过程中始终可见、可触达。iOS 27.1 在 SwiftUI 里加入了 ReservedRegion，在 UIKit 里加入了 UIViewReservedRegion，让你的自定义界面能够申请自己需要的空间，而不会跟系统界面打架。你可以通过 reservedRegions(kind:) 查询它们，其中 .division 对应折痕本身，.occlusion 对应摄像头。
落到一条弹窗上，结论就是一条规则：不要用 hinge 角度去重新摆放它的位置。让它去响应 arrangement 和 reserved region，这样屏幕展开时你的内容会落在该在的位置，而不是死守着一个已经不存在的画面。
Split View 里的应用内通知
因为现在每个应用都在多任务池里，你的应用内通知完全可能被挤到半屏，旁边站着一个陌生应用。这块空间比完整的内屏窄得多，这正是为什么要专门在半屏宽度下测试。一条在全屏下看起来没问题的弹窗，到了失去一半空间的时候，可能会被裁切或挤在一起。
还有一堵硬墙需要知道：你不能在外屏上打开新窗口，外屏是留给内屏体验专用的。任何会生成新窗口的展示逻辑，都要把这一点算进去。
外屏：你的紧凑布局，外加小组件和 Live Activities
外屏的行为和普通 iPhone 屏幕一样。你的应用照常运行，它绘制的一切——包括应用内消息——也照常显示。苹果的说法是，外屏是一个 compact-width 布局，和普通 iPhone 一样，而内屏在两个维度上都是 regular。5.4 英寸的外屏，是这台设备上你的应用内消息能拿到的最窄的全屏画面，所以它应该出现在测试矩阵里，而不是被归进”不适用”那一堆。
外屏之上还叠着第二个场景。在 Duo 上，StandBy 在两块屏幕上都能运行，即使设备没有在充电：把手机立在桌上，外屏会保持点亮，面朝房间。一个既没有小组件也没有 Live Activity 的应用，在这个场景里就是彻底缺席的。要在这个场景里出现，靠的是小组件或 Live Activity——这和你为锁屏、动态岛已经做过的工作是同一份投入。如果你已经做了 Live Activities，这是这份投入第二次回本的地方。如果还没做，这就是再多一个要做的理由。
10 月 23 日前的折叠屏兼容性清单
实体设备你现在还碰不到，但除此之外的一切都可以先做：
- 盘点你的应用内消息和富媒体模板。 找出所有写死了画框、宽高比或手机形状方框的模板。
- 审查你的 16:9 素材。 任何按固定宽高比制作的素材，都需要一个适配内屏的方案。
- 找出按方向分支的布局逻辑。 按界面方向判断的布局，读取的是内屏根本不响应的信号，把它改成按 size class 判断。
- 逐条检查安全区的每一条边。 假设它是不对称的，不要假设有一个对称的 inset。
- 全局搜索
UIScreen.main。 在双屏设备上它的含义是模糊的，苹果表示会将其废弃。改用window?.windowScene?.screen读取屏幕，用traitCollection.displayScale读取缩放比例。 - 在紧凑宽度下测试，不只是展开状态。 外屏是你的应用内消息能拿到最少空间的地方，它是一个真实存在的展示场景。
- 提前排好你的 Device Hub 测试计划。 Xcode 27.1 beta 发布后，Duo 模拟器会出现在 Device Hub 里：打开它、合上它、旋转它，在屏幕上有一条消息展示时把它半折。
- 按设备型号做分群。 给自己留一个方法，能在 Duo 用户进入真实环境后单独把他们圈出来做测试。
- 重新审视你的推送通知和引导流程文案。 用户在引导流程里看到的权限弹窗依然是系统绘制的，但引导它出现之前的任何自定义预授权页面，都要遵守和你的应用内消息一样的布局规则。
这些都不需要用到实体设备。但所有这些都得在设备到用户手上之前做完，而不是之后。
让你的应用内消息为 Duo 做好准备
把应用内消息、富媒体和推送引导页在用户手上的每一块屏幕上逐个手动修好，比放进一套集成方案里统一处理要麻烦得多——这正是为什么值得把应用内消息和推送通知放进 Pushwoosh 这样一个统一的移动互动平台来管理：免费开始使用，或者联系我们的团队，在 10 月 23 日前让你的消息在 Duo 上做好准备。
