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

Apple의 iOS 27 릴리스 노트는 연속적으로 크기를 조절할 수 없는 iPad 앱을 위해 한 줄짜리 우회책을 제시합니다. Info.plist에 네 가지 인터페이스 방향을 모두 지원한다고 선언하라는 것입니다.¹ 이 노트가 빠뜨린 사실은, 시스템이 그 앱 전역 선언을 각 뷰 컨트롤러가 지원하는 방향과 교집합으로 계산한다는 점입니다.² 앱 전역 집합을 넓히면 모든 곳에서 넓어집니다. iPhone도 예외가 아닙니다. 방향을 제한해 둔 뷰 컨트롤러마다 supportedInterfaceOrientations를 재정의하지 않는 한 그렇습니다.

이 변경 사항을 한 줄로 요약한 설명은 현재 상태까지 잘못 전달합니다. Apple의 의도는 선언된 방향이 더 이상 연속 크기 조절을 좌우하지 않게 하는 것입니다. 그런데 그 의도를 기록한 릴리스 노트 항목은 알려진 문제(Known Issues)에 들어 있습니다. Beta 4에서는 여전히 방향이 조건으로 작동하기 때문입니다.¹

두 가지 모두 중요합니다. 현재 동작은 의도된 변경으로 가는 길목에 놓인 버그이고, 그 버그를 피하는 우회책에는 부작용이 있는데 어느 문서도 우회책과 같은 자리에 그 사실을 적어 두지 않았습니다.

요약

iOS 및 iPadOS 27 Beta 4에서는 iOS 27 SDK 기준으로 빌드한 iPad 앱의 UISupportedInterfaceOrientations에 네 방향 중 하나라도 빠져 있으면 연속 크기 조절이 불가능한 앱으로 처리됩니다. Apple은 이를 알려진 문제로 올려 두면서, 동시에 방향이 “더 이상 연속 크기 조절의 조건이 되어서는 안 된다”고 밝히고 있습니다.¹ 문서에 적힌 우회책은 네 방향을 모두 선언하는 것입니다. 그렇게 하면 앱의 방향 집합이 앱 전역에서 넓어지고, 시스템은 앱 전역 방향과 각 뷰 컨트롤러의 방향을 비교해 회전 여부를 결정합니다.² 나머지 알려진 문제 네 건은 UIRequiresFullScreen과 얽혀 있습니다. 원래는 새로운 UIScreen으로의 개별적인 변경으로 전달되어야 할 크기 변경이 연속 업데이트로 전달되는 문제입니다.¹ UIRequiresFullScreen도 UISupportedInterfaceOrientations도 지원 중단 상태가 아닙니다.³⁴

릴리스 노트가 실제로 말하는 것

iOS 및 iPadOS 27 Beta 4 노트의 UIKit 섹션에는 이 문제와 관련된 항목이 여섯 개 있고, 그중 다섯 개는 아직 해결되지 않았습니다.¹

조건 자체는 알려진 문제로 분류되어 있습니다:

“iPad에서 iPad 앱을 iOS 27 SDK 기준으로 빌드했고 해당 앱의 UISupportedInterfaceOrientations에 네 가지 인터페이스 방향이 모두 포함되어 있지 않다면, 그 앱은 연속적으로 크기를 조절할 수 없는 앱으로 처리됩니다. iOS 27부터는 지원하는 인터페이스 방향이 더 이상 연속 크기 조절의 조건이 되어서는 안 됩니다.”

두 번째 문장이 어느 시점을 말하고 있는지 눈여겨보세요. “조건이 되어서는 안 된다”는 표현은 의도된 동작을 설명합니다. 실제로 출시된 동작이 아직 그 의도와 맞지 않기 때문에 이 항목이 알려진 문제로 올라와 있는 것입니다.

이 구분은 개발자가 취해야 할 조치를 바꿔 놓습니다. 방향이 정말로 크기 조절의 조건에서 빠졌다면, 조언은 우회책을 제거하라는 쪽이 되었을 겁니다. 하지만 여전히 조건으로 작동하기 때문에, 조언은 우회책을 적용하되 그 이유가 언젠가 사라질 것을 염두에 두라는 쪽이 됩니다.

UIRequiresFullScreen을 둘러싼 알려진 문제 네 건:

iOS 27 SDK 기준으로 빌드하면서 UIRequiresFullScreen을 설정한 iPad 앱은 연속적인 크기 변경 업데이트를 받습니다. Apple의 설명대로라면 “각 크기 변경은 그 대신 갱신된 bounds를 가진 새로운 UIScreen으로의 개별적인 변경으로 전달되어야” 합니다. 같은 현상이 iPad에서 실행되는 iPhone 전용 앱에서도, 그리고 iPhone 미러링 안에서도 나타납니다.¹

네 번째 항목은 iPhone 미러링에서의 방향 처리를 다룹니다. iOS 27 SDK 기준으로 빌드한 앱은 “UISupportedInterfaceOrientations에 선언되었거나 UIViewController.supportedInterfaceOrientations가 반환하는 방향과 관계없이” 모든 방향을 지원하는 scene을 받습니다. 본래는 “사용자가 창 크기 조절을 시작하기 전까지는 그 방향 선언이 존중되어야” 합니다.¹

해결된 항목 하나: UIRequiresFullScreen이 설정된 상태에서 크기 조절 시 UIScreen.main의 bounds가 바뀌던 이전 문제는 이제 해결된 문제(Resolved Issues) 항목에 있습니다.¹ 이전 베타에서는 실제로 열려 있던 알려진 문제였습니다. 몇 주 전에 정리해 둔 메모를 보고 작업하고 있다면, 그 내용을 그대로 옮기기 전에 이 항목부터 확인하세요.

연속 크기 조절이 주는 것

대가를 따져 보기 전에, 조건에 걸려 있는 대상이 정확히 무엇인지 짚어 둘 필요가 있습니다. “연속적으로 크기 조절 가능”이라는 표현은 아주 구체적인 의미를 담고 있기 때문입니다.

iPad 창의 크기가 바뀌는 방식은 두 가지입니다. 하나는 미리 정해진 상태 사이를 건너뛰는 방식으로, 호환 모드에 있는 앱이 이 방식을 따릅니다. Apple의 표현으로는 시스템이 “앱의 scene 크기를 일정하게 유지하지만, 앱의 scene을 전체 화면으로 표시하지는 않습니다.”³ 다른 하나는 드래그를 따라가는 방식으로, 사용자가 크기 조절 컨트롤을 움직이는 동안 중간 크기 값을 연속으로 전달받습니다.

이 차이는 사용자의 손끝에서 드러납니다. 연속 크기 조절이 되는 앱은 창이 움직이는 동안 레이아웃을 실시간으로 다시 배치합니다. 그렇지 않은 앱은 레이아웃을 그대로 붙들고 있다가 마지막에 탁 맞춥니다. 드래그를 그대로 따라오는 시스템 앱 옆에 두면, 이런 앱은 굼떠 보입니다.

Apple은 수년에 걸쳐 이 호환 경로를 좁혀 왔습니다. UIRequiresFullScreen은 iPad 멀티태스킹과 동적 크기 조절에서 완전히 빠지기 위해 iOS 9에서 도입되었습니다.³ iPadOS 16의 Stage Manager와 iPadOS 26의 Windowed Apps 모드는 각각 창이 할 수 있는 일을 넓혔고, 이제 문서는 호환 모드를 그것이 무엇을 허용하는지가 아니라 무엇을 내주지 않는지로 설명합니다.

결국 이 우회책이 답하는 질문은, 내 iPad 앱이 현대적인 창 관리에 참여할 것인가 아니면 Apple이 계속 줄여 나가는 모드에 남을 것인가입니다. 그 정도면 Info.plist를 고칠 만한 값어치가 있습니다. 다만 아무런 안전장치 없이 고칠 만하지는 않습니다. 다음 절이 다루는 내용이 바로 그것입니다.

우회책의 대가

Apple의 우회책은 한 문장으로 끝납니다. Info.plist에 네 가지 인터페이스 방향을 모두 선언하라는 것입니다.¹ 그 결과가 무엇인지는 다른 문서에 적혀 있습니다.

회전이 어떻게 결정되는지는 UIViewController.supportedInterfaceOrientations 문서에 나와 있습니다.²

“회전 여부를 판단할 때 시스템은 뷰 컨트롤러가 지원하는 방향, 앱이 지원하는 방향(Info.plist 파일 또는 앱 델리게이트의 [메서드]로 결정됩니다), 그리고 기기가 지원하는 방향을 서로 비교합니다.”

세 개의 집합, 그 교집합입니다. Info.plist 선언은 지시가 아니라 상한선입니다. Info.plist에 방향 하나만 적어 두고 뷰 컨트롤러 수준에서는 아무것도 재정의하지 않은 채 세로 전용을 유지해 온 앱은, 이 우회책을 적용하는 순간 그 제약을 잃습니다.

유니버설 앱이라면 그 영향은 iPad뿐 아니라 iPhone에도 떨어집니다. 게다가 Apple 자신의 지침이 iPhone에서의 넓은 선언에 반대합니다. 거꾸로 세로 방향에 대해 이렇게 적혀 있습니다. “iPad idiom에서는 이 방향을 활성화하는 것이 모범 사례입니다. iPhone 12처럼 홈 버튼이 없는 iOS 기기는 이 방향을 지원하지 않습니다. iPhone idiom에서는 완전히 비활성화해야 합니다.”² Info.plist 문서도 반대편에서 같은 말을 합니다. 시스템이 “홈 버튼이 없는 기기에서는” 거꾸로 세로 옵션을 무시한다고 적고 있습니다.⁴

그러니 정직한 안내는 한 단계가 아니라 두 단계입니다.

<!-- Info.plist: the ceiling. Required for continuous resizability on iPad. -->
<key>UISupportedInterfaceOrientations</key>
<array>
    <string>UIInterfaceOrientationPortrait</string>
    <string>UIInterfaceOrientationPortraitUpsideDown</string>
    <string>UIInterfaceOrientationLandscapeLeft</string>
    <string>UIInterfaceOrientationLandscapeRight</string>
</array>

// And the floor, on every controller that must stay constrained.
final class CaptureViewController: UIViewController {
    override var supportedInterfaceOrientations: UIInterfaceOrientationMask {
        UIDevice.current.userInterfaceIdiom == .pad ? .all : .portrait
    }
}

두 번째 단계를 건너뛰면, iPad의 창 동작 하나를 얻자고 유니버설 앱에 iPhone에서도 화면을 거꾸로 돌리라고 지시한 셈이 됩니다. 이 실패는 크래시도 빌드 오류도 아닙니다. 누군가 사용하고 있는 도중에 카메라 화면이 홱 뒤집히는 일입니다.

supportedInterfaceOrientations의 기본값이 idiom에 따라 다르다는 점, 그리고 시스템이 shouldAutorotate가 true를 반환할 때만 이 값을 참조한다는 점도 함께 기억해 두세요.² shouldAutorotate를 재정의했다면, 제약이 그대로 유지된다고 가정하기 전에 두 속성의 상호작용을 다시 읽어 볼 필요가 있습니다.

내 앱이 영향을 받는지 확인하는 법

여기 나온 어떤 것도 빌드 오류를 내지 않습니다. 그래서 점검은 손으로 해야 합니다. 아래 세 가지 점검을, 수고를 덜어 주는 정도가 큰 순서대로 정리했습니다.

타깃별로 Info.plist가 실제로 무엇을 선언하는지 확인하세요. 방향 관련 키는 프로젝트를 만들 때 한 번 설정한 뒤 다시 들여다보지 않는 경우가 많습니다. 게다가 유니버설 앱은 UISupportedInterfaceOrientations~ipad를 통해 iPhone과 iPad에 서로 다른 선언을 담고 있을 수 있습니다. 둘 다 읽어야 합니다.

# Every orientation and fullscreen declaration across the project
rg -l 'UISupportedInterfaceOrientations|UIRequiresFullScreen' --glob '*.plist'

# And what each one says
/usr/libexec/PlistBuddy -c "Print :UISupportedInterfaceOrientations" Info.plist
/usr/libexec/PlistBuddy -c "Print :UIRequiresFullScreen" Info.plist

PlistBuddy는 키가 없으면 0이 아닌 종료 코드를 반환하는데, UIRequiresFullScreen의 경우에는 그 자체가 답입니다. 키가 없다면 애초에 호환 모드에 있던 적이 없다는 뜻입니다.

코드에서 방향을 제한하는 컨트롤러를 찾으세요. Info.plist를 바꾼 뒤에도 계속 제 역할을 하는 것이 바로 이들이고, 이들이 없다는 사실이 그 변경을 위험하게 만듭니다.

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

검색 결과가 비어 있고 Info.plist 선언마저 좁다면, 그것이 정확히 깨지는 조합입니다. 앱이 세로 전용인 이유가 오로지 Info.plist 선언 하나뿐이므로, 그것을 넓히는 순간 존재하던 유일한 제약이 사라집니다.

그다음에는 두 idiom 모두에서 앱을 직접 보세요. 이 실패는 눈에 보이는 문제이고, 자동화된 신호는 약합니다. 화면을 조작하고 그 내용을 검증하는 UI 테스트는 어떤 방향에서도 통과합니다. 찾아야 할 것은 예전에는 회전할 수 없었던 화면이 회전하는 장면입니다. 그러려면 Info.plist를 바꾼 뒤 iPhone 빌드를 실행해 기기나 시뮬레이터를 실제로 돌려 봐야 합니다.

미디어 촬영, 문서 스캔, 서명 입력란, 게임, 그리고 고정 비율 캔버스를 쓰는 모든 화면에서 예기치 않은 회전의 대가가 가장 큽니다. 동시에 컨트롤러별 재정의가 가장 분명하게 어울리는 자리이기도 합니다.

UIRequiresFullScreen은 폐기되는 것이 아니라 속이 비워지고 있습니다

해결되지 않은 다섯 건 중 네 건이 UIRequiresFullScreen과 얽혀 있습니다.¹ 앱을 iPad 멀티태스킹에서 빼 주던 이 키는, 이제 크기 변경 전달이 잘못 동작하는 조건이 되었습니다.

그렇다고 지원이 중단된 것은 아닙니다. UIRequiresFullScreen 문서에는 iOS 9.0과 iPadOS 9.0 지원이 표시되어 있을 뿐, 지원 중단이나 사용 불가, 베타 표시는 없습니다.³ iOS 3.2부터 제공된 UISupportedInterfaceOrientations도 마찬가지입니다.⁴

이 조합에는 이름을 붙여 둘 만합니다. 2026년에 UIRequiresFullScreen을 설정한 앱은 경고 없이 컴파일되고, 마이그레이션 안내 없이 출시되며, Apple이 계속 좁혀 가는 호환 모드에 안착합니다. 그 모드가 최신 시스템에서 무엇을 뜻하는지는 문서에 이미 적혀 있습니다. Windowed Apps 모드를 지원하는 iPad의 iPadOS 26 이상에서, 그리고 Stage Manager를 지원하는 iPad의 iPadOS 16 이상에서 시스템은 “앱의 scene 크기를 일정하게 유지하지만, 앱의 scene을 전체 화면으로 표시하지는 않습니다.”³

이 키는 더 이상 이름이 말하는 일을 하지 않습니다. 그런데도 퇴역하지 않았고, 빌드 과정의 그 어떤 것도 이 사실을 알려 주지 않습니다.

패턴: 어떤 SDK에 링크했는지가 결정합니다

위의 모든 항목은 하나의 조건을 공유하는데, 그 조건은 OS 버전이 아닙니다. 각 항목은 “iOS 27 SDK 기준으로 빌드한” 앱에 적용됩니다.¹

같은 소스, 다른 바이너리, 다른 동작입니다. 이번 릴리스에서 반복해서 등장한 패턴이기도 합니다. 메뉴 항목 이미지는 어떤 SDK에 링크했는지에 따라 달라지며, 두 세대의 SDK에 걸쳐 세 가지 서로 다른 동작이 나타납니다. 반면 macOS 27의 팀 간 컨테이너 접근 차단은 반대 사례로 보입니다. SDK 조건이 붙지 않은 OS 수준 정책입니다. 그렇기 때문에 이 구분은 짐작하지 말고 매번 확인해야 합니다.

테스트에 미치는 실질적인 영향은 이렇습니다. iOS 26 SDK 기준 빌드와 iOS 27 SDK 기준 빌드는 서로 다른 대상입니다. CI 매트릭스에 Xcode 버전이 하나뿐이라면, 그중 하나만 테스트하고 있는 것입니다.

지금 해야 할 일

연속 크기 조절이 애초에 필요한지부터 판단하세요. iPad 앱이 이미 네 방향을 모두 선언하고 있다면 여기 나온 내용은 해당되지 않습니다. 이 우회책은 방향을 의도적으로 제한해 둔 경우에만 의미가 있습니다.

우회책을 적용한다면 컨트롤러별 재정의를 함께 넣으세요. Info.plist 변경은 상한선일 뿐입니다. 제약은 그것이 필요한 컨트롤러의 supportedInterfaceOrientations로 옮겨 가야 하고, idiom을 기준으로 갈라야 합니다.

UIRequiresFullScreen은 따로 점검하세요. 해결되지 않은 문제 네 건이 이 키와 얽혀 있지만, 빌드에서는 아무런 표시도 나오지 않습니다. Info.plist 파일들을 grep으로 훑어보세요. iPad 앱이라고 생각하지 않는 타깃까지 포함해서 말입니다. 문제 중 하나가 iPad에서 실행되는 iPhone 전용 앱을 다루기 때문입니다.

이 조건이 사라질 것을 염두에 두세요. Apple은 방향이 더 이상 연속 크기 조절의 조건이 되어서는 안 된다고 밝히고 있습니다. 그 변경이 실제로 반영되면 네 방향을 모두 선언할 이유는 사라지지만, 넓혀 놓은 방향 집합은 누군가 지우기 전까지 Info.plist에 그대로 남습니다. 왜 거기에 있는지 설명하는 주석을 남겨 두세요.

움직이기 전에 릴리스 노트를 다시 확인하세요. 여섯 항목 중 하나는 이미 알려진 문제에서 해결된 문제로 옮겨 갔습니다. 이 글은 2026년 8월 2일 기준 Beta 4의 상태를 담고 있습니다.

핵심 정리

iPad 앱 개발자를 위한 정리: - Apple이 그래서는 안 된다고 밝혔음에도, Beta 4에서는 선언된 방향이 여전히 연속 크기 조절을 좌우합니다. 새로운 동작이 아니라, 우회책이 있는 버그로 다루세요. - 이 우회책은 앱 전역 방향 상한선을 넓힙니다. 컨트롤러별 supportedInterfaceOrientations 재정의를 추가하지 않으면 iPhone 빌드가 회전하기 시작합니다. - 해결되지 않은 문제 네 건은 UIRequiresFullScreen이 개별적인 크기 변경 대신 연속 업데이트를 전달하는 문제입니다.

오래된 앱을 유지보수하는 분들을 위한 정리: - UIRequiresFullScreen은 지원이 중단되지도 않았고 경고도 내지 않지만, 이 키가 요청하는 동작의 범위는 계속 좁아지고 있습니다. 따로 명시적으로 점검하세요. - 여기 나온 모든 문제는 사용자가 실행하는 OS가 아니라, iOS 27 SDK 기준으로 빌드했는지에 달려 있습니다.

자주 묻는 질문

선언된 방향이 이제 연속 크기 조절의 조건에서 빠졌나요?

Beta 4에서는 아닙니다. Apple은 “iOS 27부터는 지원하는 인터페이스 방향이 더 이상 연속 크기 조절의 조건이 되어서는 안 된다”고 밝히면서도, 현재 동작이 여전히 방향을 조건으로 삼기 때문에 이 문장을 알려진 문제 항목에 넣어 두었습니다.¹

실제 우회책은 무엇인가요?

UISupportedInterfaceOrientations에 네 가지 인터페이스 방향을 모두 선언하는 것입니다.¹ 여기에 더해, 제약을 유지해야 하는 뷰 컨트롤러에는 supportedInterfaceOrientations 재정의를 함께 넣어야 합니다. 시스템이 앱 전역 집합과 각 컨트롤러의 집합을 교집합으로 계산하기 때문입니다.²

iPhone 빌드에도 영향이 있나요?

유니버설 앱을 출시하면서 방향 제한을 Info.plist 하나에만 의존하고 있다면, 그렇습니다. Apple은 iPhone idiom에서는 거꾸로 세로 방향을 완전히 비활성화할 것을 권장하며, 홈 버튼이 없는 기기에서는 시스템이 이 옵션을 무시한다고 밝히고 있습니다.²⁴

UIRequiresFullScreen은 지원이 중단되었나요?

아닙니다. 문서에는 iOS와 iPadOS 9.0 지원이 표시되어 있고 지원 중단 표시는 없습니다.³ 다만 여기서 다룬 미해결 문제 중 네 건이 이 키와 얽혀 있으므로, 지원 중단 표시가 없다는 사실을 권장의 뜻으로 읽어서는 안 됩니다.

Apple이 이 조건을 고치면 우회책을 제거해야 하나요?

더 이상 필요 없어진 부분은 제거하고, 나를 지켜 주는 부분은 남기세요. 선언된 방향이 연속 크기 조절의 조건에서 빠지면 네 방향을 모두 나열할 이유는 사라지므로, UISupportedInterfaceOrientations를 앱이 실제로 지원하는 범위로 다시 좁힐 수 있습니다. 반면 컨트롤러별 supportedInterfaceOrientations 재정의는 어떤 경우에도 남겨 두는 편이 좋습니다. 방향 제약은 그 제약이 속한 자리에서 표현하는 편이 앱 전역 상한선에 기대는 것보다 오래갑니다.

피해야 할 실패는 그 반대입니다. 재정의가 촬영 화면을 똑바로 세워 주던 유일한 장치였다는 사실을 잊은 채 Info.plist만 다시 좁히는 경우입니다.

내 앱이 지금 연속 크기 조절이 되는지 어떻게 알 수 있나요?

iPad에서 창 크기를 조절해 보면서 레이아웃이 드래그를 따라오는지, 아니면 끝에서 한 번에 맞춰지는지 보세요. 따라온다면 연속 크기 조절이 되는 것입니다. 끝에서 맞춰진다면 두 가지를 확인하세요. 동적 크기 조절에서 완전히 빠지게 만드는 UIRequiresFullScreen이 설정되어 있는지, 그리고 이번 알려진 문제가 조건으로 삼는 UISupportedInterfaceOrientations에 네 방향이 모두 나열되어 있는지입니다.¹³

더 오래된 SDK 기준으로 빌드하면 이 문제를 모두 피할 수 있나요?

각 항목은 iOS 27 SDK 기준으로 빌드한 경우를 조건으로 삼습니다.¹ 더 오래된 SDK 기준이라면 여기서 다룬 문제들은 피할 수 있지만, 그것은 결국 찾아올 변경을 막는 것이 아니라 미루는 것일 뿐입니다.

출처