iPhone Duo 上架新规：旧 App 怎么兼容，还能不能继续更新？

截至 2026 年 10 月 8 日。本文基于 Apple Developer 2026 年 10 月 5 日最新公告、iPhone Duo 适配指南和 App Store Connect 提交规则整理。

最近苹果给 iOS 开发者又布置了一道新作业：iPhone Duo 适配。

苹果已经确认，首款可折叠 iPhone ------ iPhone Duo 将于 2026 年 10 月 23 日正式发售。与此同时，Apple Developer 在 10 月 5 日发布了新的开发者公告，Xcode 27.1 开始提供 iPhone Duo 的开发、模拟和提交支持。

很多开发者看到消息后的第一反应是：

以后 App 上架是不是必须适配 iPhone Duo？

我已经上线几年的旧 App 怎么办？

如果不兼容，是不是连版本更新都提交不了？

我把苹果目前公开的规则和技术文档完整看了一遍，先给结论：

不是"从现在开始，不适配 iPhone Duo 就不能更新"。

真正需要关注的是 2027 年 4 月 这个时间点。

苹果目前明确了两项与提交相关的新要求：

从 2027 年 4 月开始，提交到 App Store 的 App 或游戏需要包含 iPhone Duo 截图。
从 2027 年 4 月开始，iOS / iPadOS App 需要使用 iOS / iPadOS 27 SDK 或更高版本构建，并至少支持 iOS 15。

而"必须使用 iOS 27.1 做到 Duo 全屏优化"目前并没有被苹果单独写成一个硬性的审核门槛。

但从开发角度看，如果你的 App 还停留在固定尺寸、固定方向、UIScreen.main、写死机型尺寸这一套逻辑，iPhone Duo 会把这些历史技术债一次性暴露出来。

所以这次真正值得开发者关注的，并不是多适配一台手机，而是苹果正在把 iPhone App 正式推进到一个更彻底的"可动态缩放"时代。

一、先说最关心的问题：旧 App 不适配，还能不能更新？

可以。

至少按照苹果截至目前公布的规则，现在已经上架的 App，不会因为没有完成 iPhone Duo 的完整适配就自动下架，也不是从今天开始就禁止更新。

Apple 在 iPhone Duo 的官方适配文档里明确写到：

所有 App 都可以在 iPhone Duo 上运行。

区别只是：不同 SDK 构建出来的 App，在 iPhone Duo 上能够使用的屏幕区域不同。

可以简单分成三个阶段来看。

时间	已上架旧 App	提交新版本	Duo 适配要求
现在 ~ 2027 年 3 月	可以继续运行	可以继续更新	建议使用 Xcode 27.1 适配，但 Duo 截图还不是硬性提交要求
2027 年 4 月开始	已上架版本不会因为这一条规则自动下架	需要满足新的提交要求	需要 iOS 27 SDK+，并提供 iPhone Duo 截图
长期	旧二进制仍可能以兼容方式运行	新版本会越来越依赖新的 SDK 和布局体系	建议完成动态布局和 Duo 全屏优化

这里有一个非常重要的区别：

"能运行"不等于"已经适配"。

旧 App 即使完全没有针对 iPhone Duo 写一行代码，系统仍然会尽量把它跑起来；但打开 Duo 内屏之后，可能出现大面积留白、页面比例不自然、工具栏位置异常，甚至部分页面被裁切。

如果这些问题已经影响基本功能，那么即使苹果没有一个叫"iPhone Duo Compatibility"的单独审核条款，也仍然可能因为普通的功能和 UI 问题增加审核风险。

二、iOS 26、iOS 27、iOS 27.1，Duo 上到底有什么区别？

苹果这次做得比较聪明，没有直接"一刀切"。

旧 App 会按照它使用的 SDK，逐级获得不同程度的适配能力。

1. 使用 iOS 26 SDK 或更早版本构建

App 可以运行，但属于明显的兼容模式。

当 iPhone Duo 展开时，App 会以一个比较传统的 iPhone 尺寸显示在内屏中间，四周可能存在较大的空白区域。

设备合上以后，App 则主要使用外屏中状态栏和前置相机左侧的区域。

也就是说：

旧 App 不会直接崩，但无法真正利用 Duo 的大屏。

2. 使用 iOS 27 SDK 构建

App 会开始真正参与动态缩放。

在内屏打开以后，可以使用更大的显示区域，空白明显减少。

但是它仍然会避开部分系统状态栏区域，因此还不算完整的 Duo 全屏体验。

3. 使用 iOS 27.1 SDK 或更高版本构建

这是苹果目前定义的 iPhone Duo 优化状态。

App 可以使用完整的显示区域，同时系统导航栏、Toolbar、Tab Bar 等标准控件会根据 Duo 当前形态自动调整。

一个最明显的变化就是：

部分 Toolbar 和 Tab Bar 会从传统的横向布局变成侧边竖向布局。

所以对于旧项目来说，最推荐的做法不是"等苹果强制"，而是：

直接把旧项目迁移到 Xcode 27.1 / iOS 27.1 SDK，再去修布局问题。

这样以后就不用经历 27.0 → 27.1 两次适配。

三、为什么 iPhone Duo 比以前换屏幕尺寸更麻烦？

以前适配 iPhone 主要解决的是：

4.7 英寸
5.8 英寸
6.1 英寸
6.7 / 6.9 英寸
刘海
Dynamic Island

本质上还是：App 启动时屏幕尺寸基本确定。

但 iPhone Duo 不一样。

用户可能在 App 正在运行的时候：

从外屏展开到内屏；
从内屏重新合上；
横过来使用；
以类似帐篷的姿态放在桌面；
进入 Split View；
在 macOS 27 的 iPhone Mirroring 中实时调整窗口大小。

也就是说，你的 App 在运行过程中，窗口尺寸本身就会发生变化。

这也是为什么苹果反复强调：

不要判断"我现在是哪台设备"，而要判断"我现在到底有多少可用空间"。

这个思路非常重要。

四、旧 App 最容易出问题的 6 种写法

1. 大量使用 `UIScreen.main.bounds`

以前很多项目都这么写：

swift 复制代码

let screenWidth = UIScreen.main.bounds.width
let screenHeight = UIScreen.main.bounds.height

在双显示屏设备上，main screen 本身已经变得含糊。

苹果甚至明确表示：这种用法未来会被废弃。

更合理的方式是从当前 View、Window 或 Scene 获取尺寸。

UIKit：

swift 复制代码

let size = view.bounds.size

或者：

swift 复制代码

let size = window.bounds.size

SwiftUI：

swift 复制代码

GeometryReader { proxy in
    let size = proxy.size
    ContentView(size: size)
}

2. 在 App 启动时读取一次尺寸，然后永久缓存

这种写法在普通 iPhone 上可能几年都没有问题：

swift 复制代码

let appWidth = UIScreen.main.bounds.width

然后全局到处使用。

但 Duo 在 App 运行过程中就会展开或合上，尺寸会实时变化。

UIKit 中应该把依赖尺寸的布局放到：

swift 复制代码

layoutSubviews()
viewDidLayoutSubviews()

需要响应尺寸切换时，可以结合：

swift 复制代码

viewWillTransition(to:with:)

而不是只在 viewDidLoad、viewIsAppearing 或 App 启动时计算一次。

3. 用"横屏 / 竖屏"决定页面布局

例如：

swift 复制代码

UIDevice.current.orientation

或者：

swift 复制代码

interfaceOrientation
statusBarOrientation

在 iPhone Duo 上，这些值已经不能可靠代表"页面当前是什么形状"。

尤其是内屏、Split View 和折叠状态下，设备方向和 App 实际可用区域并不是一回事。

苹果现在推荐根据：

Size Class；
当前 View 的宽高；
Safe Area；
Window Scene；

来决定布局。

SwiftUI：

swift 复制代码

@Environment(\.horizontalSizeClass)
private var horizontalSizeClass

@Environment(\.verticalSizeClass)
private var verticalSizeClass

UIKit：

swift 复制代码

traitCollection.horizontalSizeClass
traitCollection.verticalSizeClass

4. 认为 `.regular` 就一定是 iPad

这是非常典型的历史写法：

swift 复制代码

if horizontalSizeClass == .regular {
    // iPad UI
}

过去很多项目这么写问题不大。

但到了 iPhone Duo，内屏本身就可能出现 Regular Width。

也就是说：

Regular Width ≠ iPad。

因此不要再根据 Size Class 判断设备身份，而应该根据空间决定 UI。

比如大空间显示双栏，小空间显示单栏，这就够了。

5. Safe Area 默认左右对称

以前有人会这么计算：

swift 复制代码

let width = view.bounds.width - view.safeAreaInsets.left * 2

这隐含了一个假设：

left == right

但 iPhone Duo 上，由于摄像头、竖向 Toolbar、系统 UI、Split View 等原因，Safe Area 很可能是非对称的。

正确方式应该分别处理四个方向：

swift 复制代码

let contentBounds = view.bounds.inset(by: view.safeAreaInsets)

前景交互元素尽量留在 Safe Area 内。

而背景图、视频、渐变等视觉内容可以继续铺到屏幕边缘。

6. Banner 和视频永远 `AspectFill`

Duo 内屏比传统 iPhone 更宽。

如果你的首页大图、视频、轮播 Banner 永远使用：

swift 复制代码

.scaleAspectFill

或者 SwiftUI：

swift 复制代码

.aspectRatio(contentMode: .fill)

打开 Duo 后，很可能直接把人物、商品、Logo、二维码等关键内容裁掉。

建议根据当前宽高比动态决定 Fill / Fit，或者给图片设置明确的视觉焦点区域。

五、旧 App 怎么改？我建议分成 3 个兼容方案

并不是所有 App 都值得为了 Duo 立刻重构一遍。

可以按照项目生命周期选择不同方案。

方案 A：最低成本兼容方案

适合：

维护期项目；
工具类小 App；
页面数量不多；
暂时不准备针对 Duo 做特色功能。

目标不是"把 Duo 玩出花"，而是：

保证外屏、内屏、展开、合上之后页面不崩、不裁切、按钮能正常点。

最低需要做：

升级到 Xcode 27.1；
使用 iOS 27.1 SDK 重编译；
清理 UIScreen.main；
清理固定设备尺寸；
清理按 orientation 切 UI 的逻辑；
检查 Safe Area；
检查图片和视频裁切；
在 iPhone Duo Simulator 中完整跑一遍主流程。

对于布局原本就大量使用 Auto Layout / SwiftUI 自适应组件的项目，实际工作量可能并没有想象中大。

方案 B：标准自适应方案

适合大多数正常迭代中的 App。

目标是：

外屏保持手机体验，内屏自然升级为"大屏 iPhone"体验。

例如：

外屏：

text 复制代码

列表 -> 点击 -> 详情

内屏：

text 复制代码

列表 | 详情

SwiftUI 可以优先使用：

swift 复制代码

NavigationSplitView {
    SidebarView()
} detail: {
    DetailView()
}

UIKit 可以使用：

swift 复制代码

UISplitViewController

苹果已经针对 Duo 做了系统层适配。

设备合上时，多栏导航会自动折叠成单栏；设备打开后，又可以自然恢复成多栏。

TabView、UITabBarController、Sheet、Popover、Alert 等标准系统组件，也会自动适配不同形态。

这也是为什么苹果现在越来越鼓励：

能用系统组件，就不要自己造一整套假的导航和 Toolbar。

方案 C：iPhone Duo 增强体验

适合：

阅读类；
视频类；
地图；
文档；
创作工具；
游戏；
相机；
生产力 App。

这种 App 可以进一步利用 Duo：

内屏双栏 / 三栏；
外屏和内屏状态无缝延续；
折叠姿态下把内容和控制区分开；
Split View 多任务；
自定义侧边工具栏；
多 Scene / 多 Display 能力；
横向空间展示更多上下文信息。

如果你有大量自定义 UI，iOS 27.1 还加入了新的 Reserved Region 能力：

SwiftUI：

text 复制代码

ReservedRegion

UIKit：

text 复制代码

UIViewReservedRegion

它的作用可以简单理解为：

在尽可能使用屏幕空间的同时，告诉系统"我的自定义 UI 不要和状态栏、摄像头、系统控制区域打架"。

如果你的项目只是普通信息流 App，不一定需要上这一层。

六、我会怎么改一个已经上线 3~5 年的旧项目？

如果让我实际接手一个老项目，我不会一上来就改 UI。

我会按照下面这条路线走。

第一步：新建 Duo 兼容分支

例如：

bash 复制代码

git checkout -b feat/iphone-duo-compat

先不要和业务版本混在一起。

因为工具链升级以后，第三方 SDK、编译参数、废弃 API 都可能一起冒出来。

第二步：直接升级 Xcode 27.1

苹果在官方文档中明确建议现有 App 使用 Xcode 27.1 重新编译。

然后直接启动：

text 复制代码

iPhone Duo Simulator

先什么都不改，跑一遍。

把问题分成：

编译问题；
启动问题；
页面布局问题；
旋转问题；
展开 / 合上问题；
Safe Area 问题；
第三方 SDK 问题。

不要凭感觉重构。

第三步：先跑苹果自己的 App Resizability Skill

Xcode 27.1 里，苹果已经给 Coding Assistant 加了一个专门的 App Resizability 能力。

可以直接让 Xcode：

text 复制代码

get my app ready for iPhone Duo

它会扫描项目中与动态缩放有关的高风险代码，并给出修改建议。

如果你使用的是其他 Coding Agent，苹果还提供了导出 Skill 的方式：

bash 复制代码

xcrun agent skills export

这点我觉得非常有意思。

苹果这次不是只告诉你"应该适配"，而是直接开始用 Agent 帮开发者扫描老代码。

第四步：全项目搜索这些关键词

我建议旧项目先直接跑一轮：

bash 复制代码

rg -n 'UIScreen\.main|UIDevice\.current\.orientation|statusBarOrientation|interfaceOrientation|userInterfaceIdiom|UIWindow\(frame:' .

再搜索常见写死尺寸：

bash 复制代码

rg -n '375|390|393|428|430|844|852|932' .

第二条会有误报，但非常适合帮你快速定位历史布局代码。

重点排查：

text 复制代码

UIScreen.main.bounds
UIScreen.main.scale
UIDevice.current.orientation
statusBarOrientation
interfaceOrientation
userInterfaceIdiom == .phone
userInterfaceIdiom == .pad
固定的 width / height
固定刘海高度
固定状态栏高度
固定 TabBar 高度

第五步：替换几个最危险的模式

`UIScreen.main.bounds`

旧：

swift 复制代码

let bounds = UIScreen.main.bounds

新：

swift 复制代码

let bounds = view.bounds

或者：

swift 复制代码

let bounds = window.bounds

`UIScreen.main.scale`

旧：

swift 复制代码

let scale = UIScreen.main.scale

新：

swift 复制代码

let scale = traitCollection.displayScale

SwiftUI 可以从 Environment 获取 displayScale。

手动创建 UIWindow

旧：

swift 复制代码

let window = UIWindow(frame: UIScreen.main.bounds)

推荐根据 Scene 创建：

swift 复制代码

let window = UIWindow(windowScene: windowScene)

第六步：把布局从"设备驱动"改成"空间驱动"

不要再写：

swift 复制代码

if isIPhoneProMax {
    // ...
}

也不要写：

swift 复制代码

if isIPad {
    showSidebar()
}

改成：

swift 复制代码

if availableWidth > 700 {
    showTwoColumnLayout()
} else {
    showSingleColumnLayout()
}

或者直接依赖 Size Class。

这里的核心不是 700 这个数字本身，而是：

布局判断依据是可用空间，不是设备名称。

七、SwiftUI 项目怎么兼容？

如果项目本身已经大量使用 SwiftUI，整体上会比老 UIKit 项目轻松。

建议优先使用：

NavigationStack
NavigationSplitView
TabView
GeometryReader
Size Class Environment
Safe Area
系统 Sheet / Popover / Toolbar

例如：

swift 复制代码

struct RootView: View {
    @Environment(\.horizontalSizeClass)
    private var horizontalSizeClass

    var body: some View {
        NavigationSplitView {
            ListView()
        } detail: {
            DetailView()
        }
    }
}

NavigationSplitView 本身就能根据空间进行收起和展开。

如果确实需要自己根据宽度控制页面结构：

swift 复制代码

GeometryReader { proxy in
    if proxy.size.width >= 700 {
        WideLayout()
    } else {
        CompactLayout()
    }
}

而不是判断：

text 复制代码

这是 iPhone 还是 iPad？

八、UIKit 老项目怎么兼容？

UIKit 项目改造的重点其实也很明确：

优先使用 Auto Layout

如果你的页面还是大量：

swift 复制代码

view.frame = CGRect(...)

并且坐标基于屏幕宽高计算，那么 Duo 会比较痛苦。

优先逐步迁移到：

text 复制代码

Auto Layout
Safe Area Layout Guide
UILayoutGuide
UISplitViewController
UITabBarController
UINavigationController

如果必须手动布局，也要在尺寸变化时重新计算。

例如：

swift 复制代码

override func viewDidLayoutSubviews() {
    super.viewDidLayoutSubviews()

    let bounds = view.bounds.inset(by: view.safeAreaInsets)
    contentView.frame = bounds
}

不要只算一次。

九、Flutter、React Native、Hybrid App 怎么办？

这部分很多跨端开发者也会担心。

本质上仍然是两层问题：

第一层：原生容器必须能在 iOS 27.1 / Duo 下正常工作

你最终提交到 App Store 的还是一个 iOS App。

所以依然需要：

新版 Xcode；
新 SDK；
iPhone Duo Simulator；
检查第三方插件的 iOS 原生代码；
检查 Safe Area；
检查窗口尺寸变化。

Flutter

页面尺寸建议使用：

dart 复制代码

final size = MediaQuery.sizeOf(context);

或者：

dart 复制代码

LayoutBuilder(
  builder: (context, constraints) {
    return ...;
  },
)

避免把首次读取到的屏幕宽高存成全局常量。

同时检查：

text 复制代码

SafeArea
MediaQuery padding
横竖屏逻辑
固定宽高组件
原生 iOS Plugin

React Native

优先使用：

javascript 复制代码

const { width, height } = useWindowDimensions();

而不是在模块初始化阶段只执行一次：

javascript 复制代码

Dimensions.get('screen')

然后永远缓存。

同时建议检查 react-native-safe-area-context、导航组件和原生模块对新 SDK 的支持情况。

WebView / Hybrid

Web 页面至少要保证：

css 复制代码

width: 100%;
max-width: 100%;

并做好响应式布局。

需要全屏内容时检查：

css 复制代码

env(safe-area-inset-top)
env(safe-area-inset-right)
env(safe-area-inset-bottom)
env(safe-area-inset-left)

但不要只改 H5。

真正决定 App 窗口如何适配 Duo 的，仍然是最外层的 iOS Native 容器。

十、游戏要特别注意什么？

游戏往往比普通 App 更依赖固定比例。

苹果给出的方向很明确：

可以锁定 portrait 或 landscape；
但设备姿态发生变化时，仍然应该正确填充当前可用区域；
尽量通过调整画面宽高比适配；
不要一上来就大量 letterbox / pillarbox；
如果确实需要留黑边，尽量用游戏背景或装饰内容填充，而不是简单黑块。

因此 Unity、Unreal、自研引擎项目应该重点测试：

text 复制代码

动态分辨率
Safe Area
UI Canvas
HUD
虚拟摇杆位置
摄像机视口
Aspect Ratio
展开 / 合上过程

十一、`UIRequiresFullScreen` 能不能救旧 App？

有些老项目可能会想到：

text 复制代码

UIRequiresFullScreen = YES

能不能直接告诉系统：

我就按照以前的全屏方式跑，不要给我缩放？

答案是：不能把它当作 Duo 适配方案。

苹果说明，iPhone Duo 仍然会尊重 UIRequiresFullScreen，但是当设备展开或合上时，App 仍然会发生尺寸变化。

因此它无法让你绕开动态布局问题。

这点非常关键。

十二、App Store 截图也要重新准备

除了代码，App Store 运营素材也要变。

苹果已经公布 iPhone Duo 的截图尺寸。

外屏

text 复制代码

1398 × 2034 px
2034 × 1398 px

内屏

text 复制代码

2007 × 2853 px
2853 × 2007 px

目前苹果已经允许开发者上传 Duo 相关素材。

而从 2027 年 4 月 开始，苹果明确表示：

提交 App 或游戏时，需要包含 iPhone Duo 截图。

因此如果你有大量 App，尤其是公司账号下面几十个历史项目，建议不要等到 2027 年 4 月再统一处理。

代码适配完成以后，顺手把：

外屏截图；
内屏截图；
横屏场景；
关键业务页面；

都准备好。

苹果目前没有在这条公告里明确写"外屏和内屏必须各传几张"，所以实际提交时仍应以当时 App Store Connect 的必填提示为准。

十三、不做兼容，最坏会发生什么？

这个问题可以分成两个时间点。

现在不兼容

大概率结果是：

App 还能运行；
Duo 内屏显示不完整；
大面积留白；
导航和内容比例不好看；
部分硬编码页面发生错位；
个别业务流程可能出现不可点击或裁切问题。

但不是立刻禁止更新。

2027 年 4 月以后还完全不管

真正容易卡住提交的首先是：

SDK 版本不满足要求；
缺少 iPhone Duo 截图；
新 SDK 编译不过；
第三方依赖不支持；
新设备下页面已经严重不可用。

其中前两项是苹果目前已经公开写明的提交要求。

至于"必须做到 iOS 27.1 的完整全屏优化，否则一律拒审"，截至本文写作时，苹果没有这样表述。

所以网上如果有人直接说：

从 2027 年开始，不适配 iPhone Duo 的旧 App 全部不能更新。

这个说法并不严谨。

更准确的说法应该是：

从 2027 年 4 月开始，你想提交新版本，就需要进入新的 SDK 和 iPhone Duo 素材规则；而为了保证 Duo 上真实可用，旧 App 最好同步完成动态布局改造。

十四、给旧项目一份可以直接照着做的检查清单

如果你现在手上有一个已经上架的 App，可以按照下面这份清单处理。

工具链

安装 Xcode 27.1
使用 iOS 27.1 SDK 编译
所有 CocoaPods / SPM / 二进制 SDK 正常编译
TestFlight 可正常安装

代码

搜索并减少 UIScreen.main
不在启动时永久缓存屏幕尺寸
不依赖 UIDevice.current.orientation 决定布局
不依赖 interfaceOrientation 决定布局
不通过 userInterfaceIdiom 直接决定大屏 / 小屏布局
检查所有固定屏幕宽高
检查固定状态栏、导航栏、TabBar 高度
Safe Area 四个方向分别处理
大图 / 视频检查 AspectFill 裁切

UI

业务

App Store

十五、最后说一下我的判断

iPhone Duo 表面上看只是苹果第一次做折叠屏。

但对于开发者来说，它带来的影响可能比"多一个屏幕尺寸"更大。

因为苹果正在进一步弱化：

text 复制代码

设备型号
固定分辨率
横屏 / 竖屏
Phone / Pad

这些传统的布局判断方式。

取而代之的是：

text 复制代码

当前 Window 有多大？
当前 View 有多大？
当前 Size Class 是什么？
Safe Area 在哪里？
现在能放下多少内容？

这其实和 iPad 多任务、Stage Manager、Mac 窗口化、iPhone Mirroring 是同一条路线。

未来 Apple 平台上的 App，会越来越像真正的"可伸缩应用"，而不是一张绑定某个固定手机尺寸的 UI。

所以如果你的项目里现在还到处都是：

swift 复制代码

UIScreen.main.bounds.width

以及：

swift 复制代码

if isIPhoneXXX { ... }

那这次 iPhone Duo 可能就是一个非常合适的技术债清理节点。

我的建议是：

不要等 2027 年 4 月审核真正卡住再改。

现在用 Xcode 27.1 把 App 扔进 iPhone Duo Simulator 跑一遍，十几分钟就能知道你的项目到底欠了多少"屏幕适配债"。

iPhone Duo 上架新规：旧 App 怎么兼容，还能不能继续更新？