iPhone Duo UI 마이그레이션부터 자동 QA까지

iPhone Duo UI 마이그레이션부터 자동 QA까지

Xcode 27.1 + Codex로 화면 수정하고 시뮬레이터에서 다시 검증하기

iPhone Duo 대응에서 처음 눈에 들어오는 것은 화면 크기입니다.

접었을 때와 펼쳤을 때 화면 비율이 달라지고, 가운데 fold가 생기고, 기존 상단이나 하단에 있던 navigation과 toolbar가 세로 방향으로 이동할 수도 있습니다.

하지만 실제 개발에서 더 부담스러운 부분은 따로 있습니다.

수정해야 할 화면보다 확인해야 할 상태가 훨씬 많아진다는 점입니다.

Closed
Open
Folded
Rotated

×

Navigation 상태
Modal 상태
Keyboard
Scroll 위치
Dynamic Type
Dark Mode

화면 하나를 고쳐도 여러 상태에서 다시 확인해야 합니다.

그래서 iPhone Duo 대응에서는 UI Migration뿐 아니라 Simulator Automation과 QA Workflow가 같이 중요해집니다.

최근 Xcode 27.1의 Duo Simulator와 Codex의 iOS Simulator 제어 Workflow를 조합하면 이 반복작업을 꽤 많이 자동화할 수 있습니다. Apple은 Xcode 27.1에서 Duo를 열고, 닫고, 회전하고, 접은 상태를 Device Hub에서 테스트할 수 있도록 했고, OpenAI는 Codex가 XcodeBuildMCP를 통해 Simulator를 실행하고 UI tree를 읽고 tap·type·swipe하며 screenshot, log, LLDB까지 사용하는 Workflow를 공식적으로 문서화했습니다.

---

1. Duo 대응은 단순한 화면 리사이징이 아니다

기존 iPhone 앱은 보통 세로 화면을 중심으로 만들어졌습니다.

UIScreen.main.bounds.width

같은 값을 기준으로 UI를 계산하거나,

if width > 700 {
    // tablet layout
}

처럼 특정 화면 폭을 기준으로 분기한 코드도 적지 않습니다.

Duo에서는 이런 가정이 훨씬 위험해집니다.

앱이 실행되는 공간이:

닫힌 상태
→ 일반적인 iPhone 형태

펼친 상태
→ 넓어진 내부 화면

접은 상태
→ fold가 화면을 분할

회전
→ 또 다른 비율

로 계속 달라지기 때문입니다.

Apple도 Duo 대응에서 화면 크기를 직접 추측하기보다 Size Class, Trait Collection, 현재 Scene과 실제 Layout Environment를 사용하라고 권장하고 있습니다. UIScreen.main 같은 main-screen 기반 코드 역시 멀티 디스플레이 환경에서 줄이는 방향입니다.

예를 들어:

let scale = UIScreen.main.scale

보다:

let scale = traitCollection.displayScale

처럼 현재 UI가 실제로 놓여 있는 환경에서 값을 얻는 것이 안전합니다.

Duo Migration의 첫 번째 작업은 의외로 새로운 API를 추가하는 것이 아니라,

UIScreen.main

고정 width / height

orientation 기반 분기

device model 기반 분기

absolute frame

같은 기존 가정을 찾아내는 것입니다.

---

2. 시스템 Navigation을 쓰면 생각보다 많은 것이 자동으로 해결된다

Duo에서 가장 먼저 다시 볼 부분은 Navigation입니다.

SwiftUI라면:

NavigationStack
NavigationSplitView
TabView

UIKit이라면:

UINavigationController
UISplitViewController
UITabBarController

같은 System Container를 사용하는 것이 중요합니다.

Apple은 Duo에서 표준 navigation container와 presentation이 각 pose에 맞게 적응하도록 설계했습니다.

예를 들어 Tab Bar는 내부 화면에서 상황에 따라 Sidebar 형태로 바뀔 수 있고 Navigation과 Toolbar도 세로 방향으로 이동할 수 있습니다.

그래서 문제가 되는 것은:

Custom UI

자체가 아닙니다.

문제는:

System Navigation과 완전히 분리된
Custom Navigation

입니다.

예를 들어:

VStack {
    CustomNavigationBar()

    ContentView()

    CustomTabBar()
}

처럼 모든 Navigation UI를 직접 배치했다면 Duo의 Vertical Bar나 새로운 Safe Area 변화가 자동으로 반영되지 않습니다.

---

3. 기존 Custom Tab Bar를 당장 버릴 필요는 없다

기존 서비스에서 Custom Tab Bar와 Custom Navigation을 전부 System Container로 한 번에 교체하는 것은 현실적으로 어렵습니다.

그래서 iOS 27.1에서는 ReservedRegion이 중요합니다.

SwiftUI에서는:

ReservedRegion

UIKit에서는:

UIViewReservedRegion

을 사용할 수 있습니다.

목적은 단순합니다.

Safe Area 밖까지 UI를 사용하면서도 시스템 UI나 하드웨어 영역과 충돌하지 않게 하는 것입니다.

따라서 마이그레이션은:

Custom UI 전부 삭제

보다

1. 기존 Custom UI 유지

2. ReservedRegion 대응

3. Navigation State와 UI 분리

4. System Container로 단계적 이동

이 현실적입니다.

---

4. 이제 fold 자체를 Layout 정보로 읽을 수 있다

이번 Duo 대응에서 꽤 중요한 변화입니다.

단순히:

Safe Area가 달라졌다

정도가 아닙니다.

앱이 어디에 fold가 있는지 직접 조회할 수 있습니다.

SwiftUI:

GeometryReader { proxy in
    let regions = proxy.reservedRegions(
        kind: .division
    )

    let frames = regions.map(\.frame)

    // layout
}

UIKit:

let regions = view.reservedRegions(
    kind: .division
)

let frames = regions.map(\.frame)

여기서 .division은 화면을 실제로 나누는 영역입니다.

Duo의 fold가 대표적입니다.

또:

.occlusion

도 존재합니다.

이건 카메라처럼 화면 일부를 가리는 영역을 의미합니다.

즉 이제 Layout은 단순히:

width = 1000

을 보고 판단하는 것이 아니라,

전체 화면
+
division
+
occlusion

을 같이 보고 결정할 수 있습니다.

---

5. fold가 펴져 있어도 미리 알 수 있다

조금 더 재미있는 API도 있습니다.

let regions = proxy.reservedRegions(
    kind: .division,
    options: .includeInactive
)

includeInactive를 사용하면 현재 fold가 활성화돼 있지 않은 상태에서도 해당 Region 정보를 확인할 수 있습니다.

Duo가 완전히 펼쳐져 있으면 fold의 division region은 inactive 상태이고 폭도 0이 될 수 있습니다.

하지만 앱은:

이 Device에는 division region이 존재한다

는 사실을 알 수 있습니다.

예를 들어 Grid UI라면:

Duo

→ Column을 짝수로 구성
→ 나중에 접혀도 자연스럽게 양쪽으로 분리

같은 선제적인 Layout 설계도 가능합니다.

---

6. ArrangementView가 꽤 중요해졌다

기존 Foldable 대응에서는 직접:

if folded {
    HStack { ... }
} else {
    VStack { ... }
}

같은 코드를 작성하기 쉽습니다.

Apple은 iOS 27.1에서 이 문제를 위해 ArrangementView라는 Layout Container를 제공합니다.

SwiftUI:

NavigationStack {
    ArrangementView {
        PlayerView()
    } secondary: {
        UpNextView()
    }
}

UIKit에서는:

UIArrangementViewController

를 사용할 수 있습니다.

Arrangement는 단순 Split View와 조금 다릅니다.

Size Class

Aspect Ratio

Division Region

현재 사용 가능한 공간

등을 기준으로 Primary와 Secondary Content를 배치합니다.

즉 Duo 대응의 핵심은:

크기 변경

에서 점점

Arrangement 변경

으로 이동합니다.

---

7. Center Layout도 다시 생각해야 한다

기존 앱에는 가운데 정렬 UI가 많습니다.

[       큰 이미지       ]

        제목

        버튼

Duo를 반쯤 접으면 가운데 fold가 그대로 콘텐츠를 지나갈 수 있습니다.

이때 단순하게 전체 View를 축소하는 것보다:

왼쪽
Image

       fold

오른쪽
Title
Button

처럼 콘텐츠를 이동시키는 편이 자연스러울 수 있습니다.

Apple은 이를 Displacement Pattern으로 설명하고 있습니다.

그래서 Duo Migration 시 다음 화면을 먼저 찾는 것이 좋습니다.

Center aligned Hero

Video Player

Camera Preview

Map

Large Chart

Two-pane editor

Media Player

이런 화면은 fold가 지나갈 가능성이 높습니다.

---

8. Vertical Bar 대응도 이제 단순한 Tab Bar 문제가 아니다

Duo 내부 화면에서는 Navigation, Toolbar, Tab Bar가 하나의 Vertical Region을 공유할 수 있습니다.

Apple은 이를 거의:

기존 Bar를
90도 돌려 배치한다

는 개념으로 설명합니다.

하지만 Custom Toolbar를 직접 만든 경우에는 자동으로 들어가지 않습니다.

SwiftUI에서는 가능한 한:

NavigationStack {
    ContentView()
        .toolbar {
            ToolbarItem {
                Button("Edit") { }
            }
        }
}

처럼 Navigation Container에 Toolbar를 연결하는 것이 좋습니다.

UIKit 역시:

UINavigationController
+
ViewController의 toolbarItems

방식이 권장됩니다.

직접 만든:

UIToolbar()
UINavigationBar()
UITabBar()

의 Content는 Duo의 시스템 Vertical Bar 구성에 자동 참여하지 않습니다.

---

9. 여기까지가 Migration, 문제는 QA다

여기까지 코드만 고쳤다고 해보겠습니다.

이제 확인해야 합니다.

Closed
✓

Open
?

Folded
?

Rotated Open
?

Rotated Folded
?

화면이 30개라면?

30 × pose 4

만 해도 120번입니다.

여기에:

Navigation

Modal

Keyboard

Scroll

Dynamic Type

Dark Mode

까지 들어갑니다.

그래서 Duo 대응에서는 시뮬레이터 QA 자동화의 가치가 커집니다.

---

10. Xcode 27.1에는 iPhone Duo Simulator가 있다

Xcode 27.1에서 iPhone Duo Simulator를 선택하면 Device Hub에서:

Open

Close

Rotate

Fold

상태를 직접 바꿔 테스트할 수 있습니다.

즉 예전처럼:

Preview width를 임의로 바꿔보기

가 아니라 실제 Duo 환경에서 UI를 확인할 수 있습니다.

이제 문제는:

누가 이걸 계속 눌러서 테스트할 것인가?

입니다.

여기서 Codex를 붙일 수 있습니다.

---

11. Codex는 이제 Simulator를 직접 조작할 수 있다

OpenAI는 Codex의 공식 iOS Use Case로:

Debug in iOS Simulator

를 제공하고 있습니다.

Codex와 XcodeBuildMCP를 연결하면:

Xcode Project 탐색
       ↓
Scheme 선택
       ↓
Simulator 선택
       ↓
Build
       ↓
Launch
       ↓
UI hierarchy 확인
       ↓
Tap
Type
Scroll
Swipe
       ↓
Screenshot
       ↓
Log
       ↓
LLDB

까지 진행할 수 있습니다.

즉 Codex가 단순히 Swift 코드를 작성하는 도구에서:

코드
+
실행 환경
+
UI
+
Debugger

를 같이 보는 형태로 바뀌고 있습니다.

---

12. 좌표를 찍는 매크로와는 조금 다르다

UI 자동화에서 흔한 방식은:

x: 320
y: 630

tap

입니다.

하지만 Layout이 조금만 바뀌어도 깨집니다.

OpenAI의 Codex Simulator Workflow에서는 가능하면 Accessibility Label이나 Element ID를 사용하고, 화면이 변경될 때 UI hierarchy를 다시 읽는 방식을 권장합니다.

예를 들어:

"로그인" 버튼 검색
       ↓
Tap
       ↓
화면 변경
       ↓
UI Tree 다시 조회
       ↓
"이메일" 입력창 검색
       ↓
Type

입니다.

Duo처럼 Layout이 pose에 따라 크게 달라지는 환경에서는 이 방식이 특히 중요합니다.

---

13. Duo QA Scenario를 자연어로 만들 수 있다

예를 들어 Codex에게 이런 작업을 줄 수 있습니다.

iPhone Duo Simulator에서 앱을 실행한다.

로그인 화면까지 이동한다.

테스트 계정으로 로그인한다.

홈 화면을 확인한다.

홈 → 상세 → 설정 화면까지 이동한다.

각 화면에서 스크린샷을 저장한다.

버튼이 잘리거나 다른 UI와 겹치는지 확인한다.

Navigation이 정상 동작하는지 확인한다.

로그에 constraint warning이나 crash가 있는지 확인한다.

문제가 있으면 원인을 찾고 최소한의 코드만 수정한다.

수정 후 같은 Flow를 다시 실행한다.

Codex가 담당할 수 있는 것은:

Reproduce

Observe

Diagnose

Fix

Verify

Loop입니다.

OpenAI도 공식 문서에서 이를 reproduce-fix-verify loop라고 설명합니다.

---

14. Duo에서는 QA Matrix를 먼저 만들어두는 것이 좋다

무작정 Agent에게:

전체 테스트해줘.

라고 하면 범위가 너무 큽니다.

Duo용 QA Matrix를 먼저 정의하는 것이 좋습니다.

예를 들어:

화면	Closed	Open	Folded	Rotate
Login	✓	✓	✓	✓
Home	✓	✓	✓	✓
Detail	✓	✓	✓	✓
Settings	✓	✓	✓	✓
Camera	✓	✓	✓	✓

그리고 각 화면에서:

Layout

Navigation

Interaction

Safe Area

ReservedRegion

Vertical Bar

Accessibility

Crash / Warning

을 검사합니다.

이렇게 하면 QA가 훨씬 명확해집니다.

---

15. Layout QA에서는 이것부터 찾으면 된다

Duo Migration에서 특히 잡아야 할 문제는 몇 가지가 반복됩니다.

Fixed Width

.frame(width: 390)

UIScreen.main

UIScreen.main.bounds

Orientation 의존성

UIDevice.current.orientation

Safe Area 무시

.ignoresSafeArea()

를 foreground control에 무분별하게 사용하는 경우.

Custom Navigation

Navigation Controller 밖에서
Tab / Toolbar / Navigation Bar 직접 배치

중앙 UI

fold와 겹치는
centered control

이 항목들을 먼저 Audit하면 전체 수정량을 빠르게 줄일 수 있습니다.

---

16. Safe Area QA는 네 방향을 따로 봐야 한다

기존 iPhone에서는:

left == right

라고 가정한 코드가 생각보다 많습니다.

Duo에서는 safe area나 layout margin이 비대칭일 수 있습니다.

따라서:

let insets = view.safeAreaInsets

print(insets.top)
print(insets.left)
print(insets.bottom)
print(insets.right)

처럼 각각 독립적인 값으로 취급해야 합니다.

Apple도 Duo에서 asymmetric safe area와 layout margin을 반드시 테스트하라고 강조합니다.

---

17. ReservedRegion QA도 별도로 만들어야 한다

Custom UI가 있다면:

Division Region

Occlusion Region

두 가지를 확인합니다.

예를 들어:

let divisions = view.reservedRegions(
    kind: .division
)

let occlusions = view.reservedRegions(
    kind: .occlusion
)

그리고 중요한 버튼이 해당 영역과 겹치는지 확인합니다.

QA 관점에서 보면:

Safe Area QA

와

Reserved Region QA

는 같은 것이 아닙니다.

Safe Area 안에만 넣으면 되는 일반 control도 있지만, edge-to-edge나 custom bar처럼 Reserved Region을 별도로 고려해야 하는 UI도 있습니다.

---

18. Screenshot QA도 꽤 유용해진다

Codex는 Simulator에서 screenshot을 캡처할 수 있습니다.

그래서 각 상태에서:

Home_Closed.png

Home_Open.png

Home_Folded.png

Home_Rotated.png

처럼 증거를 남길 수 있습니다.

다만 여기서 한 가지 구분해야 합니다.

Codex가 screenshot을 볼 수 있다는 것과 완전한 Visual Regression Test Framework가 있다는 것은 다릅니다.

진짜 픽셀 기반 회귀 테스트가 필요하다면:

SnapshotTesting
또는
사내 Snapshot Tool

같은 시스템과 결합하는 것이 더 안정적입니다.

구조는:

Codex
 ↓
Simulator Flow 실행
 ↓
Screenshot
 ↓
Snapshot Baseline
 ↓
Diff

형태가 됩니다.

Codex는 여기서 실행과 원인 분석을 담당하게 할 수 있습니다.

---

19. Accessibility QA도 같이 할 수 있다

Codex가 UI Tree를 읽을 수 있다는 점은 단순 자동 클릭보다 의미가 큽니다.

예를 들어:

Button인데 Label 없음

아이콘만 있고 의미 없음

동일한 Accessibility ID 중복

숨겨져야 할 요소가 노출

같은 문제도 QA 대상이 될 수 있습니다.

Duo에서 Layout이 재배치돼도:

화면상 위치

대신

Accessibility Identity

가 유지된다면 자동화 Script도 훨씬 안정적으로 동작합니다.

결국 Accessibility를 잘 만드는 것이 QA 자동화 품질도 높여줍니다.

---

20. Crash가 발생하면 LLDB까지 이어갈 수 있다

UI를 눌러보다 Crash가 발생하면 자동화가 끝나는 것이 아닙니다.

Codex 공식 Workflow는 필요할 경우 LLDB를 붙여:

Stack Frame

Variable

Backtrace

등을 확인하는 단계까지 포함합니다.

전체 흐름은:

Simulator
 ↓
Crash
 ↓
Log
 ↓
LLDB
 ↓
Root Cause
 ↓
Code 수정
 ↓
Build
 ↓
동일 Flow 재실행

입니다.

이 부분이 단순 XCTest 생성과 가장 큰 차이 중 하나입니다.

---

21. QA Agent에게 코드를 마음대로 고치게 하면 안 된다

자동화가 가능하다고:

문제 있으면 알아서 다 고쳐.

라고 맡기는 것은 추천하지 않습니다.

오히려 제한을 명확하게 주는 것이 좋습니다.

문제를 먼저 재현할 것

수정 전 screenshot과 log를 남길 것

Root Cause를 설명할 것

가장 작은 코드 변경만 할 것

Navigation Architecture는 변경하지 말 것

Public API는 변경하지 말 것

수정 후 동일 Scenario를 다시 실행할 것

같은 조건입니다.

OpenAI의 공식 Simulator 예제도 smallest code change 후 동일 Flow를 다시 실행해 검증하도록 안내합니다.

---

22. 실제 Codex Prompt는 이렇게 시작해볼 수 있다

예를 들어:

XcodeBuildMCP를 사용해서
현재 프로젝트를 iPhone Duo Simulator에서 QA해줘.

대상 화면:
- Login
- Home
- Detail
- Settings

확인 항목:
- UI clipping
- overlap
- asymmetric safe area
- reserved region 충돌
- navigation
- toolbar / tab bar
- scroll
- accessibility label
- Auto Layout warning
- crash

각 화면에서 screenshot을 남겨.

문제가 발견되면 바로 수정하지 말고
먼저 원인과 수정 계획을 정리해.

승인된 수정은 최소 범위로 적용하고,
수정 후 동일 Flow를 다시 실행해서 검증해.

여기에 Duo 전용 조건을 추가합니다.

Closed / Open / Folded / Rotated 상태를
모두 QA 대상으로 본다.

UIScreen.main,
고정 width / height,
orientation 기반 분기를 우선적으로 찾아본다.

Custom Tab Bar와 Custom Navigation은
현재 디자인을 유지하면서
ReservedRegion으로 대응 가능한지 먼저 검토한다.

System Container로의 마이그레이션은
별도 제안으로 분리한다.

이렇게 하면 기존 앱을 전부 갈아엎는 방향으로 흘러가는 것을 막을 수 있습니다.

---

23. Pose 변경 자체는 자동화 범위를 구분해서 봐야 한다

여기서는 한 가지 주의할 점이 있습니다.

Xcode 27.1의 Device Hub가:

Open
Close
Rotate
Fold

를 제공하는 것은 Apple이 공식적으로 확인한 기능입니다.

Codex + XcodeBuildMCP가 Simulator 내부의 UI를 자동으로 조작하는 것도 공식 Workflow입니다.

하지만 Duo의 모든 pose 변경을 XcodeBuildMCP가 자동 API로 제어할 수 있는지는 사용하는 XcodeBuildMCP 버전과 Tool 노출 범위를 확인해야 합니다.

그래서 현재 실무에서는:

앱 내부 UI QA
→ Codex 자동화

Pose 변경
→ Tool 지원 시 자동화

미지원 시
→ Device Hub에서 상태 전환

으로 나누는 것이 안전합니다.

이 부분까지 완전히 자동화된 것처럼 보는 것은 아직 이릅니다.

---

24. 자동 QA의 현실적인 1단계는 Smoke Test다

처음부터 모든 화면을 자동화할 필요는 없습니다.

가장 먼저:

앱 실행

로그인

홈 진입

핵심 화면 3개 이동

대표적인 Modal 열기

스크롤

주요 CTA Tap

정도를 자동화합니다.

그리고 이를:

Closed

Open

Folded

에서 반복합니다.

이것만으로도:

Navigation 깨짐

화면 잘림

Button 접근 불가

Modal 이상

Crash

같은 큰 문제를 상당수 잡을 수 있습니다.

---

25. 그다음 Regression QA로 확장한다

Smoke Test가 안정되면:

Critical User Flow

를 추가합니다.

예를 들어 쇼핑 앱이면:

Login
 ↓
Product
 ↓
Cart
 ↓
Payment

카메라 앱이면:

Camera
 ↓
Zoom
 ↓
Capture
 ↓
Preview
 ↓
Save

업무 앱이면:

Login
 ↓
List
 ↓
Detail
 ↓
Edit
 ↓
Submit

정도입니다.

그리고 Duo pose별로 돌립니다.

Critical Flow
      ×
Duo Pose

이게 실질적인 Duo Regression Suite가 됩니다.

---

26. QA 결과도 사람이 읽기 쉽게 남겨야 한다

Agent가:

테스트 완료했습니다.

라고 하면 의미가 없습니다.

최종 결과는 최소한 이렇게 받아야 합니다.

Simulator
iPhone Duo / iOS 27.1

Scheme
Production-Debug

Tested
12 scenarios

Passed
10

Failed
2

그리고 Failure마다:

Home / Folded

문제
Floating button이 division region과 겹침

Evidence
home_folded_before.png

원인
고정 trailing offset

수정
safeArea + reservedRegion 기반 위치 계산

검증
home_folded_after.png

형태로 남기는 것이 좋습니다.

이런 결과라면 개발자뿐 아니라 QA나 기획자도 이해할 수 있습니다.

---

27. Xcode의 App Resizability Skill도 같이 활용할 수 있다

Apple도 이 반복적인 Migration 작업을 AI 활용 영역으로 보고 있습니다.

WWDC26에서 소개됐던 App Modernization Skill은 Xcode 27.1에서 App Resizability로 이름이 변경됐고, SwiftUI와 iPhone Duo까지 지원 범위가 확장됐습니다.

즉:

Apple App Resizability Skill
→ Layout Migration Audit

Codex + XcodeBuildMCP
→ Simulator 실행 / 문제 재현 / 수정 / 검증

처럼 역할을 나누는 것도 가능합니다.

---

28. 앞으로 iOS QA Workflow가 조금 달라질 것 같다

기존에는:

Developer
 ↓
코드 작성
 ↓
Simulator 확인
 ↓
QA 전달
 ↓
Bug
 ↓
Developer 재현
 ↓
수정

이었다면,

Agent를 끼운 Workflow는:

Developer
 ↓
Codex
 ↓
Build
 ↓
Simulator
 ↓
Flow 실행
 ↓
Screenshot / Log
 ↓
문제 발견
 ↓
수정
 ↓
동일 Flow 재검증
 ↓
QA

가 됩니다.

사람 QA가 없어지는 이야기는 아닙니다.

오히려 사람이 반복적으로 확인하던:

앱 실행

로그인

버튼 누르기

화면 이동

스크린샷 찍기

로그 수집

수정 확인

을 Agent에게 넘기고,

QA는:

UX가 자연스러운가

실제 사용자 시나리오가 맞는가

예상하지 못한 문제가 있는가

에 더 집중하는 방향에 가깝습니다.

---

29. iPhone Duo가 이 변화를 더 빠르게 만들 수 있다

일반적인 iPhone 하나만 지원할 때는 직접 Simulator를 몇 번 눌러보는 것으로도 버틸 수 있었습니다.

하지만 Duo에서는:

Pose 증가

Resizable Layout

Vertical Navigation

Asymmetric Safe Area

Reserved Region

Multiple Display

Fold

가 동시에 들어옵니다.

검증 Matrix가 커집니다.

그래서 이번 Duo 대응의 중요한 변화는 단순히:

Foldable iPhone이 나왔다.

가 아닙니다.

개발 Workflow 관점에서는:

사람이 모든 UI 상태를 직접 확인하기 어려워지는 시점이 왔다.

는 쪽이 더 흥미롭습니다.

---

30. 정리

iPhone Duo Migration은 세 단계로 보는 것이 좋습니다.

1단계 — Architecture

UIScreen.main 제거

고정 Layout 제거

Size Class / Trait 사용

System Navigation 우선

2단계 — Duo Layout

Asymmetric Safe Area

ReservedRegion

Division / Occlusion

ArrangementView

Vertical Bar

3단계 — Automation & QA

Xcode 27.1 Duo Simulator

Codex

XcodeBuildMCP

UI Tree

Tap / Type / Swipe

Screenshot

Logs

LLDB

Regression

결국 중요한 것은 새로운 UI API를 몇 개 적용했느냐가 아닙니다.

Migration
      ↓
Run
      ↓
Observe
      ↓
QA
      ↓
Fix
      ↓
Verify

까지 반복할 수 있는 구조를 만드는 것입니다.

Codex의 iOS Simulator Workflow가 흥미로운 것도 이 때문입니다.

예전의 AI 코딩 도구가:

코드를 만들어주는 AI

였다면,

현재는 점점:

코드를 수정하고

직접 실행하고

화면을 누르고

문제를 재현하고

증거를 수집하고

수정한 뒤

다시 같은 화면을 확인하는 AI

쪽으로 이동하고 있습니다.

iPhone Duo처럼 UI 상태가 빠르게 늘어나는 환경에서는 단순 Code Generation보다 이 reproduce → fix → verify Loop가 훨씬 중요한 개발 기능이 될 가능성이 큽니다.

---

참고자료

Apple Developer — Prepare your app for iPhone Duo
iOS 27.1 SDK, Duo Simulator, flexible layout, asymmetric safe area, ReservedRegion, App Resizability를 설명합니다.
Apple 공식 Tech Talk 보기

Apple Developer — Strike a pose with adaptive layouts on iPhone Duo
Division/Occlusion Reserved Region, fold 대응, ArrangementView와 UIArrangementViewController를 다룹니다.
Apple 공식 Tech Talk 보기

Apple Developer — Raise the bar with iPhone Duo
Vertical Navigation, Toolbar, Tab Bar, Overflow와 Custom Bar 마이그레이션을 설명합니다.
Apple 공식 Tech Talk 보기

OpenAI — Debug in iOS Simulator
Codex + XcodeBuildMCP를 이용해 Simulator를 실행하고 UI Tree, Tap/Type/Swipe, Screenshot, Log, LLDB를 활용해 reproduce-fix-verify Loop를 만드는 공식 Workflow입니다.
OpenAI 공식 iOS Simulator Workflow 보기

공식 자료 기준으로 보면 Duo 대응의 중심은 더 이상 단순한 화면 크기 대응에 머물지 않습니다. Apple은 ReservedRegion, ArrangementView, Vertical Bar와 App Resizability까지 Layout 대응 범위를 넓혔고, 동시에 실제 Duo Simulator를 제공하고 있습니다.

여기에 Codex의 Simulator Automation을 붙이면 UI Migration → 실행 → 재현 → Screenshot/Log 수집 → 수정 → 재검증까지 하나의 Workflow로 연결할 수 있습니다.

다만 현재는 Duo Device Hub의 모든 pose 변경까지 Codex나 XcodeBuildMCP가 자동 제어한다고 단정하기보다는, Simulator 내부 앱 조작 자동화와 Device Pose Automation을 별개의 영역으로 보고 사용하는 Tool 버전에서 지원 여부를 확인하는 것이 안전합니다.