← 모든 글

크기 조절 가능한 iPhone의 시대: 9월 전에 앱을 준비하세요

크기 조절 가능한 화면에 맞춰 iPhone 앱을 어떻게 준비해야 할까요? Apple이 그은 경계선은 앱이 링크하는 SDK입니다. Xcode 27의 Device Hub는 iOS 26 이하 SDK에 대해 링크된 앱에서는 크기 조절 모드를 명시적으로 지원하지 않는다고 밝히고 있으며, iOS 27 릴리스 노트의 크기 조절 관련 항목은 모두 “iOS 27 SDK로 빌드된” 경우를 조건으로 삼습니다.12 그다음으로는 고정 크기를 전제한 모든 지점(UIScreen.main.bounds 참조, 하드코딩된 frame, 방향으로 분기하는 레이아웃)을 점검하고, size class와 레이아웃에 적응하는 SwiftUI 컨테이너에 기대며, Xcode 27의 Resizable Canvas 프리뷰와 Device Hub 크기 조절 모드에서 계속 테스트하면 됩니다.2 연속 크기 조절을 막고 있던 방향 전제 조건은 현재 릴리스 노트에서 Fixed로 표시되었으니, 길은 이미 열려 있습니다.1

Apple의 가을 베타는 이번 여름 내내 iPhone 개발자에게 한 가지 메시지로 수렴해 왔습니다. 화면이 고정된 사각형이라고 가정하지 말라는 것입니다. 근거는 기조연설이 아니라 개발 도구와 릴리스 노트에 있습니다. 크기 조절은 iOS 27 SDK 링크와 함께 도착하고, 프리뷰 캔버스는 자유롭게 크기가 바뀌며, 베타 주기가 성숙하면서 릴리스 노트는 마지막 구조적 장애물을 걷어냈습니다. 올가을 어떤 하드웨어가 나오든, 소프트웨어 쪽 계약은 이미 바뀌었습니다.

요약: iOS 27은 새 SDK로 빌드한 앱에 연속 크기 조절을 가져옵니다. Xcode 27은 그것을 검증할 테스트 표면(Resizable Canvas 프리뷰, Device Hub 크기 조절 모드)을 제공합니다. 그리고 현재 릴리스 노트, 즉 8월 24일에 공개된 beta 7 판은 방향 게이트를 Fixed로 기재합니다. 이 항목은 beta 4 판과 beta 6 판 사이에 알려진 문제(Known Issues)에서 빠졌고, 선언된 방향이 앱의 크기 조절 여부를 결정하는 일은 이제 없습니다.1 작업은 대부분 덧셈이 아니라 뺄셈입니다. 레이아웃이 화면 크기가 하나라고 믿는 자리를 찾아내고, 그 믿음을 지우는 일입니다. 아래는 제가 실제로 진행하는 순서대로 정리한 체크리스트입니다.

지금이어야 하는 이유

날짜가 붙은 사실 세 가지가 시계를 움직입니다.

  1. beta 7이 8월 24일에 도착했고 주기는 안정화 단계에 들어섰습니다. Apple의 후기 베타는 추가보다 수정에 집중하며, 정식 릴리스는 매년 9월에 나왔습니다.1
  2. 크기 조절의 경계는 SDK 링크입니다. Xcode 27 릴리스 노트는 “iOS 26 이하 SDK에 대해 링크된 앱”으로 Device Hub의 크기 조절 모드에 들어가는 것을 “unsupported”라고 기술합니다.2 같은 패턴이 iOS 노트에도 흐릅니다. 크기 조절 관련 항목은 전부 “iOS 27 SDK로 빌드된” 경우가 조건입니다. 다시 빌드하면 그 선의 크기 조절 쪽에 서게 되고, 예전 SDK에 머무르면 플랫폼이 향하는 방향에서 스스로 빠지는 셈입니다.
  3. 마지막 구조적 게이트가 해소되었습니다. beta 4 시기에는 UISupportedInterfaceOrientations에서 네 방향 중 하나라도 빠진 iPad 앱은 연속 크기 조절이 불가능한 앱으로 취급되었습니다. 알려진 문제였고, 문서화된 우회책에는 문서화되지 않은 비용이 따랐다는 점을 크기 조절 우회책을 다룬 글에서 살펴봤습니다. 이 항목은 노트의 beta 4 판과 beta 6 판 사이에 알려진 문제에서 빠졌고, 현재 판에는 Fixed로 기재되어 있습니다. “iOS 27부터는 지원하는 인터페이스 방향이 더 이상 연속 크기 조절의 조건이 되지 않아야 합니다.” beta 7 노트의 UIKit 알려진 문제 목록은 비어 있습니다.1

정리하면, 플랫폼은 이제 레이아웃이 기기 사양표가 아니라 컨테이너의 함수이기를 기대합니다. iPad가 멀티태스킹으로 이 교훈을 먼저 가르쳤고, iOS 27은 같은 계약을 iPhone까지 확장합니다.

체크리스트

1. iOS 27 SDK로 다시 빌드하고, 실제로 눈으로 확인하기

옵트인의 실체는 다시 빌드하는 일입니다. 레이아웃 코드를 한 줄도 고치기 전에 Xcode 27로 빌드하고, Device Hub의 크기 조절 모드를 열고, 드래그해 보세요. 잘 분리된 SwiftUI 앱은 이 첫 접촉을 작성자의 예상보다 잘 견디는 편입니다. 깨지는 지점이 오히려 배울 거리이고, 매번 같은 몇 군데에서 깨집니다. 이 체크리스트의 나머지가 바로 그 몇 군데입니다.

2. 고정 크기라는 믿음을 사냥하기

전형적인 문제 지점을, 보통 발목을 잡는 순서대로 정리하면 이렇습니다.

  • UIScreen.main.bounds를 “그 화면 크기”로 사용하는 코드. 크기가 계속 바뀌는 세계에는 그 화면 크기라는 것이 없고, UIScreen.main은 iOS 26부터 공식적으로 더 이상 사용되지 않습니다. 크기는 window scene에서 끌어내거나, SwiftUI라면 GeometryReader를 아껴 쓰거나 containerRelativeFrame(_:)을 의도적으로 써서 컨테이너에서 끌어내세요.
  • 특정 기기에 맞춘 하드코딩된 frame과 매직 넘버(“너비 390포인트면 iPhone”). if width == <숫자> 식의 기기 추론은 언젠가 반드시 거짓말을 합니다.
  • 크기 대신 방향으로 분기하는 레이아웃. 방향 확인은 늘 대리 지표였습니다. iOS 27이 방향과 크기 조절을 분리한 지금, 그 대리 지표는 공식적으로 짐일 뿐입니다. 수평과 수직 size class로 분기하세요. 애초에 그 용도로 만들어진 장치입니다.
  • 실행 시점에 치수를 캐싱하는 코드. 시작할 때 한 번 측정해 저장한 값은 첫 크기 조절 이후 이미 낡은 값입니다.

3. 적응형 컨테이너에 일을 맡기기

SwiftUI의 현대적인 레이아웃 도구는 정확히 이 상황을 위해 만들어졌습니다. 배치를 고를 때는 ViewThatFits, 화면이 아니라 컨테이너를 기준으로 크기를 잡을 때는 containerRelativeFrame, 그 사이의 모든 경우에는 grid와 유연한 frame이 있습니다. 앱이 고정 사각형 시대부터 이어져 왔다면, 가장 효과가 큰 리팩터링은 보통 하중을 지고 있는 GeometryReader 더하기 산술 계산 레이아웃 하나를 이 프리미티브들로 바꾸는 일입니다. UIKit 앱도 size class와 UICollectionViewCompositionalLayout의 환경 기반 섹션으로 같은 결과를 얻습니다.

iOS 27의 툴바와 레이아웃 변경 사항도 같은 방향을 밀어붙입니다. 프레임워크는 공간이 부족해지는 지점에서 명시적인 제어권을 넘겨주고, 이제 공간은 동적으로 부족해집니다.

4. 크기 조절이 실제로 일어나는 곳에서 테스트하기

Xcode 27은 목적에 맞게 만들어진 표면 두 개를 제공하며, 둘 다 베타 주기 초반에 이미 안정화되었습니다.

  • 프리뷰의 Resizable Canvas 모드 — 더 이상 특정 크기 비율에 묶여 있지 않으므로(이 제약은 beta 2에서 풀렸습니다) 앱이 놓일 수 있는 형태의 전 범위를 드래그해 볼 수 있습니다.2
  • 실행 중인 앱을 위한 Device Hub 크기 조절 모드 — 탈출 경로 문제는 beta 3부터 수정되었습니다(크래시나 백그라운드 전환으로 크기 조절 모드를 벗어나도 재부팅 전까지 기기 화면이 멈추는 일이 더는 없습니다).2

주요 화면마다 두 표면에서 각각 한 번씩 훑어보세요. 발견되는 버그는 캐싱하거나, 가정했거나, 추론한 화면에 몰려 있습니다.

5. 몇 년 전에 설정한 플래그를 다시 검토하기

UIRequiresFullScreen과 범위를 좁힌 UISupportedInterfaceOrientations 선언은 앱이 역사적으로 iPad 멀티태스킹의 요구에서 빠져나오던 방법입니다. 둘 다 더 이상 사용되지 않는 키는 아니지만, 이제는 새로운 방식으로 하중을 지고 있습니다. 베타 주기는 이 키들이 연속 크기 조절과 어떻게 상호작용하는지를 여러 판에 걸쳐 정리해 왔고, beta 4 시기에 있던 UIRequiresFullScreen 크기 조절 동작 관련 알려진 문제들은 현재 해결된 문제(Resolved Issues) 아래에서 Fixed로 표시되어 있습니다.1 2019년에 내린 결정 때문에 그 키들이 아직 Info.plist에 남아 있다면, 그 결정을 의도적으로 다시 내릴 달이 바로 이번 달입니다. 우회책의 비용을 분석한 글에서 범위를 넓히기 전에 확인해야 할 방향 집합의 부작용을 다룹니다.

6. 2차 효과까지 감안하기

크기 조절이 가능해진다는 말은, 텍스트 줄바꿈이 달라지고 이미지 크롭이 달라지고 NavigationSplitView가 누군가의 변덕에 따라 접히고 펼쳐지며, 공들여 다듬은 빈 상태 화면이 한 번도 프리뷰해 본 적 없는 화면비로 표시된다는 뜻입니다. 하나하나는 어렵지 않습니다. 그런데도 하드웨어가 나오는 주가 아니라 지금 체크리스트를 시작해야 하는 이유가 바로 그 전부입니다.

제가 건너뛸 것

특정 기기를 두고 추측하는 일은 건너뛰세요. 크기 조절 계약은 오늘 내려받을 수 있는 SDK 안에 있고, 오늘 읽을 수 있는 릴리스 노트에 문서화되어 있으며, Xcode 27 첫 베타에 들어온 도구로 테스트할 수 있습니다. 접히는 iPhone이 올가을에 나온다면 위 목록을 마친 앱은 준비된 상태입니다. 내년 봄에 나온다 해도 같은 작업은 iPad 멀티태스킹과 플랫폼이 다음에 크기를 바꿀 무엇에서든 곧바로 값을 돌려줍니다. 소문에 대비하는 것보다 메커니즘에 대비하는 편이 낫습니다.

핵심 요약

  • 옵트인의 선은 SDK 링크입니다. iOS 27 SDK로 다시 빌드하면 크기 조절은 앱의 과제이자 기회가 됩니다. Device Hub는 예전 SDK로 빌드한 앱의 크기 조절 모드를 지원하지 않는 것으로 취급합니다.2
  • 방향 게이트는 해소되었습니다. 선언된 방향이 크기 조절 여부를 결정하지 않습니다. 이 항목은 현재 노트에서 Fixed로 표시되었고, UIKit의 알려진 문제 목록은 비어 있습니다.1
  • 작업은 기능을 더하는 일이 아니라 가정을 지우는 일입니다. 화면 크기 참조, 매직 넘버 레이아웃, 방향이라는 대리 지표, 시작 시점 캐시를 찾아내 컨테이너에서 도출하는 레이아웃으로 바꾸면 끝입니다.
  • 진짜 표면에서 테스트하세요. Resizable Canvas 프리뷰와 Device Hub 크기 조절 모드는 정확히 이 목적으로 존재합니다. 화면별로 두 곳을 각각 한 번씩 훑으면 나중에 발목을 잡을 문제의 대부분이 드러납니다.

자주 묻는 질문

제 앱은 자동으로 크기 조절이 가능해지나요?

Apple이 그은 경계는 SDK 링크입니다. Xcode 27 릴리스 노트는 iOS 26 이하 SDK로 빌드한 앱의 크기 조절 모드를 지원하지 않는다고 하고, iOS 노트는 모든 크기 조절 동작을 iOS 27 SDK로 빌드하는 것을 조건으로 둡니다.12 그다음에 벌어지는 일은 레이아웃에 달려 있습니다. 컨테이너 기반 SwiftUI는 대체로 적응하고, 고정 크기 가정은 버그로 드러납니다.

연속 크기 조절을 위해 아직도 네 방향을 모두 선언해야 하나요?

아닙니다. 현재 릴리스 노트는 방향 조건을 Fixed로 표시하며(beta 4 판과 beta 6 판 사이에 해소되었습니다), “지원하는 인터페이스 방향이 더 이상 연속 크기 조절의 조건이 되지 않아야 합니다”라고 밝힙니다.1 이전 베타에서는 네 방향을 모두 선언하는 우회책이 필요했는데, 그것을 이미 출시했다면 앱 전역에 미치는 부작용을 이해해 둘 가치가 있습니다.

이제 UIRequiresFullScreen은 사용 중단된 건가요?

아닙니다. 여전히 지원되는 키이고, 크기 조절 동작과 관련해 베타 주기에 있던 알려진 문제들은 현재 노트의 해결된 문제(Resolved Issues) 아래에서 Fixed로 표시되어 있습니다.1 다만 이 키는 크기 조절이 기본이 된 플랫폼에서 의도적으로 다시 판단해 볼 가치가 있는, 여러 해 묵은 옵트아웃의 전형입니다.

이 일이 급해지는 시점은 언제인가요?

iOS 27 정식 릴리스는 9월로 예상되며, Apple의 가을 SDK 요건 주기에 따라 그 이후 신규 제출은 Apple의 통상적인 일정에 맞춰 iOS 27 SDK로 넘어갑니다. 위 체크리스트는 대부분의 앱에서 집중해서 한 주 정도의 작업입니다. 지금 시작하면 출시 시즌 전에 여유 있게 끝낼 수 있습니다.

출처


  1. Apple Developer Documentation, iOS & iPadOS 27 Release Notes (Beta 7 판, 2026년 8월 24일). issue 166422120의 Fixed 상태에 대한 출처: “On iPad, if your iPad app is built with the iOS 27 SDK and its UISupportedInterfaceOrientations doesn’t include all four interface orientations, the app is treated as non-continuously resizable. Beginning with iOS 27, supported interface orientations should no longer be a condition for continuous resizability.” 이 항목은 beta 4 판에서는 알려진 문제(Known Issues) 아래에 있었고 beta 6 판까지 해결된 문제(Resolved Issues)로 옮겨졌습니다(아카이브된 사본으로 확인). beta 4 시기의 UIRequiresFullScreen 크기 조절 관련 문제 네 건(178558224, 178559386, 178560235, 178562971) 역시 해결된 문제 아래에서 Fixed로 표시되어 있고, beta 7 판의 UIKit 알려진 문제 목록은 비어 있습니다. ↩↩↩↩↩↩↩↩↩↩

  2. Apple Developer Documentation, Xcode 27 Release Notes (Beta 6). 다음 내용의 출처: “an app linked against an iOS 26 or earlier SDK”로 Device Hub 크기 조절 모드에 들어가는 것이 “unsupported”라는 점, “iOS previews in Resizable Canvas mode no longer constrained to specific size ratios”, 수정된 크기 조절 모드 종료 시 화면 표시 버그, 그리고 “Xcode 27 beta 6 includes Swift 6.4 and SDKs for iOS 27, iPadOS 27, tvOS 27, watchOS 27, macOS 27, and visionOS 27.” ↩↩↩↩↩↩↩

관련 게시물

개발자를 위한 iPhone Duo: 1.42 문제와 SDK 공백

개발자를 위한 iPhone Duo 정리. App Store Connect 스크린샷에서 추론한 디스플레이 포인트, 두 가지 화면 형태, Split View, Touch ID, SDK 일정, 그리고 6개의 Tech Ta…

37 분 소요

iOS 27 iPad 크기 조절: 우회책에는 대가가 따릅니다

iOS 27에서도 iPad의 연속 크기 조절은 여전히 선언된 방향에 묶여 있습니다. Apple의 우회책은 앱 전체의 방향 집합을 넓히며, iPhone에서도 마찬가지입니다.

12 분 소요

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

Apple의 iPhone Duo 디자인 가이드와 세 편의 Tech Talk를 규칙으로 읽습니다. 포즈별 레이아웃이 아닌 두 개의 사이즈 클래스, 접힘부에서의 변위, arrangement, 그리고 사이드 바.

17 분 소요