iPhone Duo를 위한 디자인: 움직이는 것, 나뉘는 것, 그대로 있는 것

iPhone Duo를 위한 디자인에는 무엇이 필요합니까? 포즈마다 하나씩이 아니라 두 개의 레이아웃이 필요합니다. “외부 디스플레이용 compact width 레이아웃과 내부 디스플레이용 regular width 레이아웃이 있으면 모든 포즈에 대응할 기본기가 갖춰집니다”라고 하며, Apple 자신의 조언은 “앱을 자유롭게 크기 조절할 수 있도록 설계하라”는 것입니다. (4:32)¹² 이 토대 위에 가이드와 세 편의 동반 Tech Talk가 설명하는 네 가지 패턴이 얹힙니다. 컨트롤은 디스플레이 측면으로 이동하며 위에서 아래로의 순서를 유지합니다. 콘텐츠는 의도적으로 화면 가득 채우는 경우가 아니라면 그 컨트롤로부터 오프셋됩니다. 인터랙티브 요소는 접힘부에서 멀어지도록 변위하지만 스크롤되는 콘텐츠는 변위하지 않습니다. 그리고 새로운 컨테이너인 arrangement가 규칙에 따라 두 개의 뷰를 분할하거나 겹칩니다. 마지막 두 가지를 뒷받침하는 API는 Tech Talk에서 다루며, arrangement는 iOS 27.1과 함께 등장합니다.³

Apple은 기조연설 당일 오후 Human Interface Guidelines에 Designing for iPhone Duo를 공개하면서, 디자인을 다루는 Tech Talk 세 편도 함께 내놓았습니다. “Design for iPhone Duo”, “Strike a pose with adaptive layouts on iPhone Duo”, “Raise the bar with iPhone Duo”입니다.¹²³⁴ 이 사이트의 개발자용 글에서는 포인트 계산과 SDK 규칙을 다루었습니다. 이 글이 다루는 것은 가이드가 요구하는 디자인상의 판단입니다. Apple 자신의 표현을 각 Tech Talk의 타임스탬프와 함께 인용하고, 제 앱에서는 그것을 어떻게 다룰 계획인지 정리합니다.

TL;DR: 두 개의 사이즈 클래스를 대상으로 디자인하고, 포즈 처리는 시스템에 맡기십시오. 바는 외부 디스플레이 측면과 가로 방향의 내부 디스플레이에서 세로로 놓입니다. 세로 방향의 내부 디스플레이만 가로 바를 유지합니다.⁴ 아이콘이 있는 항목은 세로로 가고, 텍스트만 있는 항목은 가로로 남습니다. 세로 바의 맨 위는 Back이나 Close의 자리이며, 그다음에 Done 같은 눈에 띄는 액션이 옵니다.⁴ 콘텐츠는 몰입형이면서 스크롤하지 않는 경우가 아니라면 가로 방향 안전 영역을 통해 바로부터 오프셋됩니다.² 접힘부에서는 북 포즈일 때 “알림 같은 요소가 trailing 쪽으로 이동”(4:09)하고, 테이블에 놓은 포즈에서는 인터랙티브 컨트롤이 아래쪽 절반으로 이동합니다. 반면 “기사, 피드, 문서, 목록처럼 연속적으로 스크롤되는 콘텐츠는 변위하지 않습니다.”(3:46)³ arrangement는 새로운 레이아웃 컨테이너로, split이거나 overlay입니다. 무엇을 고를지에 대한 Apple의 규칙은 이미 쓰고 있는 그대로입니다. 가로나 세로 스택은 split이 되고, ZStack은 overlay가 됩니다.³

패턴에 앞선 하나의 규칙

세 편 중 두 편의 Tech Talk와 가이드가 같은 문장을 되풀이합니다. 디자인의 출발점으로 삼아야 할 문장입니다. Apple 디자인 팀의 Vince는 이렇게 말합니다. “사람들은 iPhone Duo를 다양한 포즈로 사용할 것이고, 여러분은 그 모든 포즈에서 앱이 멋져 보이기를 바랄 것입니다. 그러나 그것이 포즈마다 맞춤 레이아웃을 만들라는 뜻은 아닙니다. 대신 두 개의 사이즈 클래스에 집중하십시오. 외부 디스플레이의 compact width와 내부 디스플레이의 regular width입니다. 고정 너비, 브레이크포인트, 특정 화면에 묶인 수치는 피하십시오”(3:50).² 가이드도 포즈를 다룬 절에서 같은 말을 합니다.¹ Vince는 선택 사항인 레이아웃을 하나 덧붙입니다. 노트북처럼 테이블에 놓인 상태를 위한 것으로, “미디어는 위쪽에, 탭할 수 있는 컨트롤은 아래쪽의 안정적인 받침에 둘 수 있습니다”(4:48). 다만 “다른 포즈와 동일한 컨트롤과 전반적인 위계를 갖춘다”(4:57)는 조건이 붙습니다.²

Apple의 2026년 9월 9일 이벤트 스트림 중 태평양 시간 오전 11시 5분 장면으로, 스탠딩 포즈입니다. 가이드가 제시하는 목록은 “책처럼 부분적으로 접기, 표면에 내려놓기, 모서리로 세우기”입니다.

아래 내용은 모두 이 토대를 전제로 합니다. 크기 조절 가능한 iPhone 체크리스트가 점검하고 iPad 크기 조절에 관한 글이 설명하는 것과 같은 토대입니다. 레이아웃이 사이즈 클래스, 레이아웃 여백, 안전 영역 인셋으로 짜여 있다면 Vince의 약속은 이렇습니다. “여러분의 앱은 이미 iPhone Duo에 적응하고 있을 것입니다”(4:27).²

측면: 무엇이 옮겨 가고 무엇이 남는가

외부 디스플레이에서는 그동안 위아래에 있던 컨트롤이 “세로 공간을 최대화하고 오른손 엄지로 더 쉽게 닿게 하기 위해 디스플레이 오른쪽으로 이동”합니다(1:18).² 측면이 맡는 것은 탭 바, 툴바, Back 같은 내비게이션 컨트롤, 상태 표시줄, 그리고 “Live Activities가 도착하면 세로로 확장되는” Dynamic Island입니다(1:48).² 내부 디스플레이에서는 가로 방향일 때 바가 세로로 유지되고 세로 방향에서는 가로로 되돌아갑니다. 세로 방향은 “가로 바를 남겨 둔 유일한 포즈”(5:27)이며, 그 이유는 “앱 콘텐츠를 위한 세로 공간이 충분하기”(5:32) 때문입니다.² Split View에서는 “앱이 왼쪽에 있으면 컨트롤도 디스플레이 왼쪽 가장자리로 이동합니다”(3:11).² 또한 바는 하드웨어를 기준으로 정렬되므로 “오른쪽에서 왼쪽으로 쓰는 언어에서도 기기의 같은 쪽에 머무릅니다”(4:21).⁴

Apple의 2026년 9월 9일 이벤트 스트림 중 태평양 시간 오전 10시 59분 장면입니다. 내부 디스플레이를 앞으로 향한 채 반쯤 접힌 기기와, 그 오른쪽 가장자리에 자리한 측면 장착 컨트롤이 보입니다.

특정 컨트롤이 세로로 갈지는 두 가지가 결정합니다. 첫째는 컨테이너입니다. UI Frameworks의 Anna는 이렇게 말합니다. “TabView나 NavigationStack 같은 내비게이션 컨테이너가 제공하는 바를 사용하고 있는지 확인하십시오”(2:19). 커스텀 UIToolbar, UINavigationBar, UITabBar 인스턴스의 콘텐츠는 “고려되지 않기”(2:58) 때문입니다.⁴ 스플릿 뷰에서는 “detail 열만 참여하고”(3:43), 인스펙터는 “자체 바를 받지 않습니다”(3:53).⁴ 둘째는 항목의 콘텐츠입니다. 세로 바는 “항목 높이가 유연하고 너비는 고정”(6:10)이며, 그래서 “심볼만 있는 항목 표현에 더 적합합니다”(6:13).⁴ 따라서 “back이나 share 버튼처럼 아이콘이 있는 항목은 축을 세로로 바꿉니다. edit 버튼처럼 텍스트만 있는 항목은 계속 가로 축에 머무릅니다”(7:06).⁴ Vince의 표현은 디자이너를 위한 것입니다. “텍스트 버튼이나 세그먼티드 컨트롤처럼 오른쪽 공간에 비해 너무 넓은 툴바 항목은 iPhone Duo에서도 내비게이션 바에 그대로 두어야 합니다”(6:22).²

순서 규칙은 짧습니다. “맨 위는 back이나 close 같은 주요 내비게이션 컨트롤을 위해 남겨 두고, 그다음에 done 같은 눈에 띄는 액션을 배치하십시오”(4:47).⁴ SwiftUI에서는 커스텀 Back이나 Close에 cancellationAction 배치를 쓰고(5:02), 눈에 띄는 액션에는 topBarPinnedTrailing을 씁니다(5:24). UIKit에서는 leading 항목에 leftItemSupplementsBackButton을 기본값 false로 둔 채 사용하고(5:06), 눈에 띄는 액션에는 pinnedTrailingGroup을 씁니다(5:27).⁴ 나머지는 원래 그룹 구성을 유지하며, “세로 스페이서가 위쪽과 아래쪽 배치를 시각적으로 분리합니다”(5:34).⁴

바를 다룬 Tech Talk가 개별 항목에 대해 제시하는 규칙과, 각각의 단서가 되는 문장입니다.⁴

• 커스텀 항목의 판단 기준: “그것은 단순히 심볼을 보강하는 것입니까, 아니면 독립적인 정보를 담고 있습니까?”(9:36)
• 개수는 배지에 넣습니다. 그러면 텍스트와 심볼로 이루어진 항목이 심볼만 있는 항목이 되어 “세로 바에 자연스럽게 어울립니다”(9:23). 반면 “금액을 표시하는 장바구니 버튼”은 가로로 남습니다(9:52).
• Edit처럼 심볼과 텍스트를 오가는 항목은 가로로 남습니다. 시스템 Edit 버튼은 이미 그렇게 동작하며, 커스텀 항목에는 가로 전용 AxisBehavior를 지정합니다(8:11, 8:32).
• 커스텀 뷰나 복잡한 뷰는 기본적으로 가로에 머무릅니다(8:40). “세로 표현을 지원한다면”(8:48) 세로를 선호하는 axis behavior를 지정해 바에 넣을 수 있습니다(8:54).
• 심볼을 표시하는 항목에도 반드시 제목을 붙이십시오. “항목이 오버플로 메뉴나 확장된 형태로 이동할 때마다 시스템이 그것을 사용하기”(7:44) 때문입니다.
• 키보드 액세서리 바는 “세로 축으로 옮기지 말고 키보드에 붙어 있는 상태를 유지해야 합니다”(10:00).
• 커스텀 뷰는 toolbarVerticalEdge 환경 속성(UIKit에서는 트레이트)을 읽어 세로 바가 있는지 알 수 있습니다(10:35).

오버플로는 디자인상의 우선순위가 드러나는 자리이며, Tech Talk는 다섯 가지 규칙을 제시합니다.⁴

• “기본적으로 항목은 아래에서 위로 오버플로됩니다”(13:23). 각 항목에는 high, low 또는 커스텀 표시 우선순위를 부여할 수 있습니다. 우선순위는 먼저 “그룹 단위로”(13:36) 정하고, 그다음 그룹 안에서 정합니다. 우선순위와 오버플로 API는 WWDC26에서 추가된 툴바 관련 API로, 이 사이트의 iOS 27 SwiftUI 글에서 다루었습니다. 13:49에서는 SwiftUI의 새로운 기능을 다룬 Apple의 WWDC26 세션을 안내합니다.
• 무엇이 먼저 압축될지 정하십시오. 내비게이션 중심 뷰에서는 “툴바가 먼저 압축되어 주요 목적지에 계속 접근할 수 있습니다”(12:07). 이것이 기본값입니다. 작업 중심 뷰에서는 “자주 쓰는 액션을 남기기 위해 탭 바가 먼저 압축됩니다”(12:18). 지정에는 toolbarCompressionBehavior를 씁니다(12:22).
• 앱 자체의 오버플로 메뉴는 시스템 메뉴에 통합하십시오. SwiftUI에서는 ToolbarOverflowMenu, UIKit에서는 additionalOverflowItems를 쓰고(12:36, 12:43), 말줄임표는 오버플로 전용으로 남겨 둡니다(12:53).
• “Mail의 Compose나 Notes의 New Note처럼 자주 쓰는 액션은 오버플로로 옮겨 가는 순서가 가장 늦은 축에 속해야 합니다”(13:59).
• 배지가 붙은 항목은 “한눈에 파악할 수 있는 상태를 유지하기 위해 더 오래 보이는 상태로 남아야 합니다”(14:11).

세로 바가 필수는 아닙니다. Calculator처럼 아래쪽이 무거운 단일 페이지 레이아웃이나 Close 같은 툴바 항목이 하나뿐인 시트에서는 toolbarVerticalBehavior 또는 preferredVerticalBarBehavior로 바를 끌 수 있습니다(14:28, 14:37, 14:47).⁴

가운데에 둘 것인가, 오프셋할 것인가

바가 한쪽으로 치우치면서 “많은 레이어가 이제 비대칭이 됩니다”(6:33).² Vince는 세 가지 배치를 제시합니다. 대부분의 콘텐츠는 컨트롤 뒤에 가려지지 않도록 오프셋을 둡니다. “앱이 가로 방향 안전 영역 인셋에 맞춰 정렬한다면 그 오프셋은 자동으로 적용됩니다”(6:58).² 일부 UI는 오프셋 없이 디스플레이 전체를 기준으로 가운데에 놓인 채로 남습니다. 이것은 “스크롤하지 않는 몰입형의 시각적 인터페이스에 잘 맞습니다. 단, 인터랙티브 요소가 오른쪽 컨트롤에 가려지지 않는다고 확신할 수 있어야 합니다”(7:10).² 그리고 둘을 섞는 방식도 있습니다. “전체 너비의 배경 이미지나 헤더와, 안쪽으로 들여 놓은 스크롤 가능한 전경 콘텐츠”(7:22)의 조합이며, 조건은 “모든 인터랙티브 요소가 그 스크롤 영역 안에 있어서 아무것도 가려지지 않는 것”(7:28)입니다.² 가이드의 안전 영역 관련 설명은 Split View 사례를 덧붙입니다. 반대쪽 가장자리에는 다른 앱의 컨트롤이 올 수 있으므로, 안전 영역은 양쪽 가장자리 모두에서 의미가 있습니다.¹

접힘부: 변위(displacement)

Apple의 2026년 9월 9일 이벤트 스트림 중 태평양 시간 오전 11시 8분 장면으로, 디스플레이의 층 구조입니다. 부분적으로 접었을 때 가운데를 지나는 곡면이 가이드에서 말하는 “folding region”입니다.

Apple의 디자인 시스템을 담당하는 Human Interface Designer인 Maria는 원칙으로 이야기를 시작합니다. “iPhone Duo를 위한 훌륭한 디자인은 언제 적응시켜야 하는지 아는 데 달려 있습니다”(2:25).³ 많은 인터페이스는 “reserved region 주위로 자연스럽게 흐를 수 있습니다”(2:30). 나머지는 변위를 사용하는데, 이는 “사용 가능한 공간을 기준으로 기존 요소의 프레임을 조정해, 기기가 부분적으로 접힌 상태에서도 중요한 콘텐츠가 보이고 닿을 수 있으며 가려지지 않도록 유지하는” 것입니다(2:39).³ 이 패턴에는 “버튼 하나에서 컨테이너 전체 또는 레이아웃의 더 큰 부분까지”(3:03)라는 적용 범위가 있고, 두 가지 규칙이 따릅니다. “요소가 독립적으로 적응할 수 있다면 그것만 옮기십시오. 요소들이 함께 작동한다면 그 관계를 지키기 위해 함께 옮기십시오”(3:17). 그리고 “과도한 이동에 유의하십시오”(3:26). “요소를 원래 위치에서 멀리 옮기면 시각적 관계가 약해지기”(3:29) 때문입니다.³ Maria의 예시는 선택한 사진에 뜬 컨텍스트 메뉴입니다. 메뉴를 trailing 영역 가운데에 두는 대신, “두 요소가 함께 움직이며 접힘부를 기준으로 정렬됩니다”(3:39).³

예외는 디자이너가 가장 많이 기대게 될 항목입니다. “기사, 피드, 문서, 목록처럼 연속적으로 스크롤되는 콘텐츠는 변위하지 않습니다. 이런 경험은 이미 스크롤을 통해 적응하고 있으므로, 사용 가능한 영역들 사이로 옮기면 연속성이 끊길 수 있습니다”(3:46).³ Vince는 반대쪽에서 같은 말을 합니다. 시스템이 인터랙티브 요소를 곡면 밖으로 밀어내는 이유는 “버튼이 접힘부에 정확히 놓이면 탭하기 어렵기”(9:28) 때문이며, 이 동작은 “시트, 알림, 메뉴, 툴바 버튼 등”(9:40)에 내장되어 있고 “스크롤 가능한 콘텐츠는 이 영역을 피할 필요가 없습니다”(9:57).²

접힘부의 방향이 영역을 정합니다. 북 포즈에서는 접힘부가 세로로 지나가고 영역은 왼쪽과 오른쪽이 됩니다. 테이블에 놓거나 세로 방향일 때는 접힘부가 가로로 지나가고 영역은 위와 아래가 됩니다.²³ 변위된 요소가 어디로 가는지는 포즈에 따라 다르며, 그 이유를 설명하는 Maria의 말이 쓸모 있는 부분입니다. 북 포즈에서는 “알림 같은 요소가 trailing 쪽으로 이동합니다. 이렇게 하면 기기를 닫아 경험이 외부 디스플레이로 이어질 때 나타날 위치에 더 가까워집니다”(4:09).³ 테이블에 세워 둔 경우 “위쪽 영역은 멀리서도 잘 보이는 것이 유리한 콘텐츠에 적합하고”(4:29), “아래쪽 영역은 인터랙티브 컨트롤에 적합합니다”(4:39). “미디어 컨트롤처럼 탭할 수 있는 요소가 이곳으로 옮겨 와, 터치를 위한 더 안정적인 면을 제공합니다”(4:43).³ 원칙을 다룬 Tech Talk도 같은 이야기를 합니다. 세로 방향으로 부분적으로 접힌 상태에서는 “인터랙티브 요소가 디스플레이 아래쪽 절반으로 이동해, 기기를 표면에 안정적으로 둔 채로도 더 쉽게 닿을 수 있게 됩니다”(2:33).² 여러 영역이 후보가 될 때는 맥락을 따르십시오. 검색 필드는 기기가 펼쳐져 있을 때 “여분의 공간을 활용하고”(5:00), 접히는 과정에서는 “검색 대상 뷰 위에 계속 있도록 너비와 위치가 적응합니다”(5:04).³

이 대부분은 시스템이 처리합니다. “액션 시트, 알림, 메뉴, 팝오버는 모두 가벼운 맥락적 경험이며 reserved region 위에 나타날 수 있습니다”(5:23). 그리고 시스템이 “reserved region 주위로 컴포넌트의 위치를 자동으로 조정합니다”(5:34).³ 스플릿 뷰는 “너비를 조정하고 균등한 50/50 분할로 배치해 두 열을 모두 보이게 유지합니다”(5:40).³ 직접 책임져야 할 것은 그리드입니다. Maria의 Fitness 디자인에서는 “바깥쪽 여백은 그대로 두면서 힌지 주변 간격을 넓혀, 각 컨테이너를 자기 영역 안에 유지할 수 있습니다”(5:56).³ 모든 예시에 대한 Maria의 요약이 곧 디자인 지침입니다. “우리는 이미 있는 것을 옮기고, 크기를 바꾸고, 재배치하는 것입니다. 사람들이 iPhone Duo를 어떻게 사용하든 경험 전체에 접근할 수 있도록 콘텐츠, 기능, 레이아웃을 계속 사용할 수 있는 상태로 두십시오”(6:04).³

Reserved region, 변위를 떠받치는 장치

Maria는 적응형 레이아웃 Tech Talk에서 이 용어를 소개합니다. “새로운 하드웨어 특성도 사용 가능한 공간의 모양을 만드는 데 한몫합니다. 힌지와, 외부 및 내부 디스플레이에 걸친 두 개의 카메라가 그것입니다. 우리는 이를 reserved region이라고 부릅니다”(0:37). 그리고 이를 “레이아웃이 이미 적응하고 있는 다른 영역과 똑같이”(0:53) 다루라고 권합니다. 예시로 든 것은 iPadOS의 윈도우 컨트롤입니다.³ reserved region은 세 가지입니다. 외부 카메라, 활성 상태인 동안의 내부 카메라, 그리고 접힘부입니다(1:00, 1:18, 1:32).³ 각각에 대한 가이드의 정의와, 가이드가 이 API들의 문서를 링크하지 않았다는 제 확인 결과는 개발자용 글에 정리해 두었습니다. 그래서 이 절은 장치 쪽에 집중합니다.¹ UI Frameworks 엔지니어인 Harry가 API를 설명합니다. “SwiftUI에서는 GeometryReader나 onGeometryChange 수정자에서 얻은 GeometryProxy로 reserved region을 조회합니다. geometry proxy의 새로운 reservedRegion 메서드를 사용하면 해당 뷰에서 사용 가능한 영역을 가져올 수 있습니다”(6:38). UIKit에서는 “UIView에서 제공하는 reservedRegion 메서드를 사용하고”(7:03), “reserved region의 frame 속성을 조회해 자신의 레이아웃에 반영할 수 있습니다”(7:07).³

종류는 두 가지입니다. 접힘부는 “더 큰 영역을 여러 개의 작은 영역으로 나누기 때문에 division reserved region으로 뒷받침됩니다”(6:55). 그리고 “누군가 기기를 접었을 때만 활성화됩니다. 평평할 때는 비활성이며 너비가 0입니다”(7:26).³ 카메라는 occlusion 영역입니다. 이들은 “영역을 나누지 않고 대신 가립니다”(7:54). 이 영역은 “카메라가 활성일 때 활성이고 카메라가 비활성일 때 비활성입니다”(8:12).³ 비활성 영역은 includeInactive 옵션으로 조회할 수 있으며, Harry가 그것을 살펴보라고 하는 이유는 디자인상의 판단에 있습니다. “그리드형 레이아웃에서는 division 영역이 존재할 때 그 활성 상태와 무관하게 짝수 개의 열을 선호할 수 있습니다”(7:41).³ 가이드도 이를 규칙으로 되풀이합니다.¹ 기조연설 당일 태평양 시간 오후 4시 15분 기준으로 가이드는 이 API들의 문서 페이지를 링크하지 않았고, Apple의 개발자 페이지는 Xcode 27.1 beta를 “이달 말”로 표기하고 있습니다.¹⁵

Arrangement: split 또는 overlay

Apple의 2026년 9월 9일 이벤트 스트림 중 태평양 시간 오전 11시 정각 장면입니다. Apple이 80퍼센트 더 크다고 말하는 내부 디스플레이, 곧 arrangement가 겨냥하는 캔버스입니다.

Harry의 정의는 이렇습니다. “레이아웃 컨테이너는 이 내비게이션 컨테이너와 콘텐츠 컨테이너 사이에 자리합니다. 이 레이아웃 컨테이너는 일련의 규칙에 따라 두 개의 뷰를 배치합니다. 이를 arrangement라고 부릅니다”(9:20).³ 규칙이 받는 입력은 “뷰의 가로 및 세로 사이즈 클래스, 뷰의 높이 대비 너비의 종횡비, 그리고 활성화된 division 영역이 있는지 여부”(10:37)입니다. 산출되는 것은 “그 뷰를 아예 표시해야 하는지”(10:52)와, 표시한다면 “그 프레임이 어떻게 되는지”(10:54)입니다.³ 그리고 시기는 이렇습니다. “iOS 27.1에서는 시스템이 제공하는 arrangement를 여러분의 앱에서 사용할 수 있습니다”(11:02).³

SwiftUI에서는 ArrangementView가 primary와 secondary 뷰를 받고(11:25), 스타일은 arrangementViewStyle로 설정합니다(11:57). UIKit에서는 UIArrangementViewController가 primary와 secondary 뷰 컨트롤러를 받습니다(11:39).³ 기본값인 split 스타일은 “뷰가 높이보다 너비가 클 때 가로로 분할하고”(12:13), 높이가 더 클 때는 세로로 분할하며, 한 축으로 제한할 수도 있습니다. 주축에서 분할할 수 없으면 “단 하나의 뷰만 표시하기를 선택합니다”(12:49).³ overlay 스타일은 “콘텐츠를 서로 위아래로 배치하기를 선호하고”(13:31), 기기가 접히면 “primary와 secondary 뷰를 나란히 배치하기를 선호합니다”(13:51). 뷰는 overlayArrangementZIndex 환경 속성으로 이를 감지해 접힌 형태와 펼친 형태를 전환할 수 있습니다(14:01).³

둘 사이의 선택은 이 Tech Talk에서 가장 명확한 조언이며, 가이드도 그대로 받아들입니다. “앱의 일부에서 HStack이나 VStack 같은 컴포넌트로 이미 split에 가까운 레이아웃을 구현하고 있다면 split arrangement 사용을 고려하십시오. ZStack 같은 컴포넌트로 이미 overlay에 가까운 레이아웃을 구현하고 있다면 overlay arrangement 사용을 고려하십시오”(14:44).³ 기존 패턴이 없다면, overlay는 “뷰들 사이에 전경과 배경의 관계가 분명할 때”(15:10) 사용합니다. Accessibility Reader에서 읽을거리 위에 컨트롤이 놓이는 경우가 그렇습니다. split은 “주와 상세의 관계에 더 가까울 때”(15:32) 사용하며, 팟캐스트와 그 대본처럼 “둘 중 어느 쪽도 결코 가려지지 않는 것이 중요한”(15:43) 경우가 여기에 해당합니다.³ 두 가지 제약, 곧 내비게이션 컨테이너를 arrangement 안이 아니라 바깥에 두는 것과 List나 ScrollView 안에 arrangement를 두지 않는 것은 Tech Talk의 16:15와 16:26에 나옵니다. 가이드가 언급하는 것은 앞의 것뿐이며, 그 문장은 개발자용 글에 인용해 두었습니다.¹³

내부 디스플레이: 정직한 세 가지 레이아웃

“그저 잡아 늘인 iPhone 앱을 원하지는 않으실 겁니다”(7:39).² Vince는 세 가지 형태를 제시합니다. 첫째는 스플릿 뷰로, “앱 위계의 여러 단계를 동시에”(7:46) 보여 줍니다. 조건은 그 위계가 “외부 디스플레이와 내부 디스플레이 사이에서 달라지지 않는”(7:51) 것입니다. 사람들이 “앱을 쓰는 동안 기기를 자주 여닫을 수 있으므로, 안팎에서 예측 가능하고 일관되어야 하기”(7:59) 때문입니다.² 둘째는 Music을 따른 리플로로, “세로로 쌓은 레이아웃”(8:15)이 “가로 공간이 더 있을 때 2열 레이아웃”(8:18)이 됩니다.² 셋째는 탭 바를 “내부 디스플레이에서 사이드바로”(8:26) 보여 주는 방식이며, 이는 “Health의 이 예시처럼 정보 밀도가 높은 앱에 가장 잘 맞습니다”(8:33).² 가이드의 Mail 예시가 스플릿 뷰 사례입니다. 접혀 있을 때는 목록이나 메시지 중 하나, 펼쳤을 때는 둘을 나란히 보여 줍니다.¹

시트에는 시트만의 규칙이 있습니다. 외부 디스플레이에서는 “시트 컨트롤도 측면으로 이동합니다”(8:46). 툴바 버튼이 하나뿐인 시트에서는 이를 끌 수 있고, 그 경우 “시트는 전면 카메라 바로 앞에서 멈추고 상태 표시줄이 스스로 위치를 바꿉니다”(9:04).² 내부 디스플레이에서 시트는 기본적으로 “표준 가로 바를 사용하고”(9:13), 기기가 부분적으로 접혔을 때는 “접힘부에 놓이지 않도록 옆으로 미끄러져 갑니다”(9:20).² 바를 다룬 Tech Talk는 배치에 관한 예외를 덧붙입니다. 내부 디스플레이의 시트는 “기본적으로 가운데에 놓이고 항목은 가로로 유지”(4:03)되지만, preferredPlacement API를 쓰면 “왼쪽에 배치된 시트는 세로 바 없이 남고, 오른쪽에 배치된 시트는 세로 바를 받습니다”(4:11).⁴

점검 목록

바를 다룬 Tech Talk와 적응형 레이아웃 Tech Talk는 각각 점검 목록으로 끝납니다. 여기서는 하나로 묶었습니다. 바 Tech Talk의 마무리 목록(15:10)은 이렇습니다. 세로 바는 SDK를 통한 옵트인이므로 최신 SDK로 빌드할 것(2:06). 바와 그 순서를 점검하고(4:41), 커스텀 항목이 세로로 배치될 수 있도록 업데이트할 것. 그리고 “시스템이 적응할 수 있도록”(15:26) 표시 우선순위를 부여할 것.⁴ 이어서 적응형 레이아웃 Tech Talk(16:40)의 내용입니다. “앱의 가운데 정렬 레이아웃을 점검하는 것부터 시작하십시오. 2열 레이아웃으로 만들 수 있을지, 아니면 그 사용 사례에서 어떤 변위 패턴이 타당한지 검토하십시오.” 표준 컨테이너와 프레젠테이션을 사용해 기본으로 주어지는 동작을 활용할 것(16:49). 커스텀 split이나 overlay 레이아웃에는 ArrangementView를 쓸 것. 그리고 “뷰에서 수동으로 배치한 컨트롤 가운데 우선순위가 가장 높은 것을 찾아, 필요하다면 ReservedRegions API를 도입해 직접 변위를 구현하는 것을 검토하십시오”(17:06).³

나는 이것을 어떻게 적용할 것인가

제 앱 가운데 셋이 iPhone 앱이고, 가이드는 그것들을 깔끔하게 분류해 줍니다. 이 분류는 Apple의 것이 아니라 제 해석입니다.

• Get Bananas는 목록입니다. 목록은 변위하지 않고, 시스템 컨테이너를 계속 쓰는 한 탭 바와 툴바는 알아서 측면으로 이동합니다. 유일한 디자인상의 판단은 표시 우선순위입니다. 항목을 추가하는 액션이 제게는 Compose에 해당하므로, 오버플로로 가장 늦게 밀려나야 합니다.
• Reps는 각 세트를 무게, 반복 횟수, 기록 액션으로 이루어진 행으로 남기며, 운동 중에는 그리드로 표시합니다. 바로 Maria의 Fitness 예시입니다. 판단은 이렇습니다. 북 포즈에서는 3열짜리 행이면 가운데 열이 힌지에 올라가므로, 그리드를 두 개씩 짝지은 2열로 바꿉니다. 테이블 포즈에서는 기록 액션을 아래쪽 절반에 둡니다. 절충점은 세트마다 탭이 한 번 늘어나는 대신, 목표 지점이 결코 접힘부에 놓이지 않는다는 것입니다. Vince의 말대로 접힘부에서는 “버튼을 탭하기 어렵습니다”(9:28).² 휴식 타이머는 위쪽에 남깁니다. Maria가 “멀리서도 잘 보이는 것이 유리한 콘텐츠”(4:29)에 적합하다고 말한 영역입니다.³
• Return은 건강 차트를 그리며, 이것은 스크롤되는 콘텐츠입니다. 지금 차트와 기간 선택기가 세로 스택에 놓여 있는 부분은 Harry의 규칙에 따르면 split arrangement에 대응합니다. 그러면 기기가 접혀도 둘 다 계속 보입니다. 차트 자체는 결코 변위시켜서는 안 됩니다.

핵심 요약

디자이너를 위해: - 포즈가 아니라 두 개의 사이즈 클래스로 생각하십시오. 바깥은 compact width, 안쪽은 regular width입니다.¹ Apple 디자이너들이 제안하는 유일한 선택 항목은 동일한 컨트롤을 유지하는 테이블용 레이아웃입니다.² - 아이콘은 세로로, 텍스트는 가로로. 사이드 바의 맨 위는 Back이나 Close, 그다음이 Done입니다. 자주 쓰는 액션과 배지가 붙은 항목은 가장 늦게 오버플로됩니다.⁴ - 스크롤되는 콘텐츠는 결코 변위하지 않습니다. 알림, 메뉴, 시트, 컨트롤은 변위하며 목적지는 용도를 따릅니다. 알림은 북 포즈에서 trailing 쪽으로, 테이블에서는 위쪽 영역으로, 터치 컨트롤은 아래쪽 절반으로 갑니다.²³

디자인 엔지니어를 위해: - 접힘부는 division 영역으로 접었을 때만 활성이고 평평할 때는 너비가 0입니다. 내부 카메라는 occlusion 영역으로 카메라가 켜져 있을 때만 활성입니다. 둘 다 GeometryProxy나 UIView에서 조회할 수 있습니다.³ - arrangement는 iOS 27.1과 함께 제공됩니다. 스택은 split이 되고 ZStack은 overlay가 되며, 내비게이션 컨테이너는 그 바깥에 둡니다.³ - 내비게이션 컨테이너가 제공하는 시스템 바를 사용하십시오. 그러지 않으면 세로 레이아웃은 결코 일어나지 않습니다.⁴

자주 묻는 질문

포즈마다 레이아웃이 필요합니까?

아닙니다. Apple은 두 개의 사이즈 클래스, 곧 외부 디스플레이의 compact width와 내부 디스플레이의 regular width를 대상으로 디자인하고, 고정 너비나 브레이크포인트, 화면에 묶인 수치는 피하라고 말합니다.¹² 디자인 Tech Talk가 제시하는 유일한 선택 항목은 동일한 컨트롤과 위계를 갖춘 테이블 포즈용 레이아웃입니다.²

iPhone Duo에서 가로로 남는 컨트롤은 무엇입니까?

텍스트만 있는 항목, 세그먼티드 컨트롤처럼 사이드 바에 비해 너무 넓은 항목, Edit처럼 심볼과 텍스트를 오가는 항목, 그리고 키보드 액세서리 바입니다. 여기에 더해, 원한다면 아래쪽이 무거운 단일 페이지 앱이나 툴바 항목이 하나뿐인 시트에서는 바 전체를 가로로 둘 수 있습니다.²⁴

변위란 무엇입니까?

기기가 부분적으로 접힌 상태에서도 요소가 계속 보이고 닿을 수 있도록, 기존 요소를 옮기고 크기를 바꾸고 재배치하는 Apple의 패턴입니다. 알림, 메뉴, 팝오버, 시트, 툴바 버튼은 시스템에서 자동으로 적용받습니다. 스크롤되는 콘텐츠는 대상에서 제외됩니다.²³

arrangement view와 reserved region API는 언제 나옵니까?

적응형 레이아웃 Tech Talk는 시스템이 제공하는 arrangement를 iOS 27.1에서 각자의 앱에 사용할 수 있다고 말하며, Apple의 개발자 페이지는 Xcode 27.1 beta를 9월 하순으로 표기하고 있습니다. 디자인 가이드는 두 API 어느 쪽에 대해서도 아직 문서를 링크하지 않았습니다.¹³⁵

스크롤되는 콘텐츠도 접힘부를 피해야 합니까?

아닙니다. 디자인 Tech Talk와 적응형 레이아웃 Tech Talk 모두 스크롤되는 콘텐츠를 예외로 둡니다. 스크롤을 통해 이미 적응하고 있기 때문입니다.²³

출처