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

Apple의 iOS 27 릴리스 노트는 연속 크기 조절이 되지 않는 iPad 앱을 위해 한 줄짜리 우회책을 제시합니다. Info.plist에서 네 가지 인터페이스 방향을 모두 지원한다고 선언하라는 것입니다.¹ 노트가 빠뜨린 부분은, 시스템이 이 앱 전체 선언을 각 view controller가 지원하는 방향과 교집합으로 처리한다는 사실입니다.² 앱 전체 집합을 넓히면 iPhone을 포함해 모든 곳에서 넓어집니다. 제약이 걸린 view controller마다 supportedInterfaceOrientations를 재정의해 두지 않았다면 그렇습니다.

업데이트, 8월 24일: 이 조건은 해소되었습니다. 현재 릴리스 노트는 이슈 166422120을 Fixed로 표시합니다. beta 4판과 beta 6판 사이에 Known Issues에서 빠졌고, beta 7판에서도 그것이 확인됩니다. 선언된 방향은 더 이상 연속 크기 조절의 조건이 아니며, 아래에 인용한 의도와 일치하게 되었습니다.¹ 네 방향을 모두 선언하는 우회책을 이미 출시했다면 현재 베타에서는 더 이상 필요하지 않습니다. 다만 걷어내기 전에, 그 우회책과 함께 supportedInterfaceOrientations 재정의를 추가한 view controller들을 다시 확인하세요. 그 재정의들은 그 자체로 여전히 제 역할을 하고 있습니다(이 글에서 다루는 교집합 동작은 달라지지 않았습니다). beta 4 시절의 UIRequiresFullScreen 크기 조절 관련 알려진 이슈들도 마찬가지로 Resolved Issues에서 Fixed로 표시되어 있습니다. 아래 분석은 Beta 4를 기준으로 쓰인 그대로 남겨 두었습니다. 출시된 빌드에 우회책이 남아 있는 한 그 부작용의 작동 방식은 여전히 적용되기 때문입니다. 이 변화가 놓인 더 큰 그림은 크기 조절 가능한 iPhone의 시대에서 다룹니다.

이 변화에 대해 널리 퍼진 요약 역시 현재 상태를 잘못 설명하고 있습니다. Apple의 의도는 선언된 방향이 연속 크기 조절을 좌우하지 않게 하는 것입니다. 그 의도를 기록한 릴리스 노트 항목이 Known Issues에 들어가 있는 이유는, Beta 4에서는 여전히 방향이 조건으로 작동하기 때문입니다.¹

두 측면 모두 중요합니다. 이 동작은 의도된 변경으로 가는 길목에 놓인 버그이고, 그 버그의 우회책에는 같은 자리에 아무도 적어 두지 않은 부작용이 있습니다.

TL;DR

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

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

iOS 및 iPadOS 27 Beta 4 노트의 UIKit 섹션에서 여섯 개 항목이 이 문제와 관련되어 있고, 그중 다섯 개가 미해결입니다.¹

조건 자체, Known Issues로 분류:

“iPad에서 iPad 앱이 iOS 27 SDK로 빌드되었고 그 UISupportedInterfaceOrientations가 네 가지 인터페이스 방향을 모두 포함하지 않는 경우, 해당 앱은 연속 크기 조절이 불가능한 것으로 취급됩니다. iOS 27부터는 지원되는 인터페이스 방향이 더 이상 연속 크기 조절의 조건이 아니어야 합니다.”

두 번째 문장의 시제를 읽어 보세요. “조건이 아니어야 합니다”는 의도된 동작을 서술한 것입니다. 이 항목이 알려진 이슈로 존재하는 이유는, 출시된 동작이 아직 그 의도와 맞지 않기 때문입니다.

이 구분은 무엇을 해야 하는지를 바꿔 놓습니다. 방향이 정말로 크기 조절을 좌우하지 않게 되었다면 조언은 우회책을 걷어내라는 것이 되어야 합니다. 여전히 조건으로 작동하므로, 조언은 우회책을 적용하되 그 이유가 곧 사라질 것을 염두에 두라는 쪽이 됩니다.

UIRequiresFullScreen을 둘러싼 네 건의 알려진 이슈:

iOS 27 SDK로 빌드되고 UIRequiresFullScreen을 설정한 iPad 앱은 연속적인 크기 조절 업데이트를 받지만, 원래는 “각 크기 조절이 갱신된 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는 회전이 어떻게 결정되는지를 설명합니다.²

“회전 여부를 판단하기 위해 시스템은 view controller가 지원하는 방향을, 앱이 지원하는 방향(Info.plist 파일이나 app delegate의 [메서드]로 결정됩니다) 및 기기가 지원하는 방향과 비교합니다.”

세 집합의 교집합입니다. Info.plist 선언은 지시가 아니라 상한선입니다. Info.plist에 방향 하나만 나열해 세로 전용을 유지해 왔고 view controller 수준에서는 아무것도 재정의하지 않은 앱은, 우회책을 적용하는 순간 그 제약을 잃습니다.

유니버설 앱이라면 이는 iPad뿐 아니라 iPhone에도 떨어집니다. 게다가 Apple 자신의 지침이 iPhone에서의 넓은 선언에 반대합니다. 거꾸로 된 방향에 대해 “iPad 관용구에서는 활성화하는 것이 모범 사례입니다. iPhone 12처럼 홈 버튼이 없는 iOS 기기는 이 방향을 지원하지 않습니다. iPhone 관용구에서는 완전히 비활성화해야 합니다”라고 적혀 있습니다.² 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의 기본값은 관용구에 따라 다르며, 시스템은 shouldAutorotate가 true를 반환할 때만 이 값을 참조합니다.² 그쪽을 재정의해 두었다면, 제약이 유지된다고 넘겨짚기 전에 이 상호작용을 다시 읽어 볼 가치가 있습니다.

내가 영향을 받는지 확인하기

이 가운데 어느 것도 빌드 오류를 내지 않으므로 점검은 수작업입니다. 시간을 아껴 주는 순서대로 세 가지를 확인합니다.

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에 대한 답입니다. 키가 없다는 것은 애초에 호환 모드에 들어간 적이 없다는 뜻입니다.

코드에서 방향을 제약하는 controller를 찾으세요. Info.plist를 바꾼 뒤에도 계속 작동하는 것이 바로 이들이며, 이들이 없다는 사실이 그 변경을 위험하게 만듭니다.

rg 'supportedInterfaceOrientations|shouldAutorotate' --type swift

결과가 비어 있으면서 Info.plist 선언이 좁다면, 그것이 정확히 깨지는 유형입니다. 앱이 오로지 property list 덕분에 세로 전용이 된 상태이므로, 그것을 넓히면 존재하던 유일한 제약이 사라집니다.

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

미디어 캡처, 문서 스캔, 서명 입력란, 게임, 그리고 고정 종횡비 캔버스를 쓰는 것들이 예기치 않은 회전의 대가가 가장 큰 곳이고, 동시에 controller별 재정의가 가장 분명하게 어울리는 곳입니다.

UIRequiresFullScreen은 지원 중단이 아니라 속이 비워지는 중입니다

미해결 다섯 건 중 네 건이 UIRequiresFullScreen과 관련되어 있습니다.¹ 앱을 iPad 멀티태스킹에서 빼내는 이 키가, 이제는 크기 조절 전달이 잘못 동작하는 조건이 되었습니다.

지원 중단된 것은 아닙니다. UIRequiresFullScreen 문서는 iOS 9.0과 iPadOS 9.0 제공을 표시하며, 지원 중단이나 사용 불가, 베타 플래그가 없습니다.³ UISupportedInterfaceOrientations도 마찬가지로 iOS 3.2부터 제공됩니다.⁴

이 조합에는 이름을 붙여 둘 만합니다. 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 앱이 이미 네 방향을 모두 선언하고 있다면 여기 내용은 해당되지 않습니다. 우회책은 방향을 의도적으로 제약한 경우에만 관련이 있습니다.

우회책을 적용한다면 controller별 재정의와 짝지으세요. Info.plist 변경은 상한선이고, 제약은 그것이 필요한 controller의 supportedInterfaceOrientations로 관용구에 따라 옮겨 가야 합니다.

UIRequiresFullScreen은 따로 점검하세요. 미해결 네 건이 여기 걸려 있는데 빌드에서는 아무 표시도 나지 않습니다. Info.plist 파일들을 grep하되, iPad 앱이라고 생각하지 않던 타깃까지 포함하세요. 이슈 중 하나가 iPad에서 실행되는 iPhone 전용 앱을 다루기 때문입니다.

이 조건은 사라질 것으로 예상하세요. Apple은 방향이 더 이상 연속 크기 조절의 조건이 아니어야 한다고 밝혔습니다. 그것이 실제로 반영되면 네 방향을 모두 선언할 이유는 사라지지만, 넓혀 놓은 방향 집합은 누군가 걷어낼 때까지 Info.plist에 남습니다. 왜 거기 있는지 설명하는 주석을 남겨 두세요.

행동하기 전에 노트를 다시 확인하세요. 이 여섯 항목 중 하나는 이미 Known Issues에서 Resolved로 옮겨 갔습니다. 이 글은 2026년 8월 2일 기준 Beta 4를 반영합니다.

핵심 정리

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

오래된 앱을 유지보수하는 사람을 위해: - UIRequiresFullScreen은 지원 중단이 아니고 경고도 내지 않지만, 그것이 요청하는 동작은 계속 좁아지고 있습니다. 명시적으로 점검하세요. - 여기 나온 모든 이슈는 사용자가 실행하는 OS가 아니라 iOS 27 SDK로 빌드하는 것을 조건으로 삼습니다.

FAQ

선언된 방향은 이제 연속 크기 조절을 좌우하지 않게 되었나요?

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

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

UISupportedInterfaceOrientations에 네 가지 인터페이스 방향을 모두 선언하는 것입니다.¹ 그리고 제약을 유지해야 하는 view controller에는 supportedInterfaceOrientations 재정의를 함께 두세요. 시스템이 앱 전체 집합과 각 controller의 집합을 교집합으로 처리하기 때문입니다.²

이것이 제 iPhone 빌드에 영향을 주나요?

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

UIRequiresFullScreen은 지원 중단되었나요?

아닙니다. 문서는 iOS와 iPadOS 9.0 제공을 표시하고 지원 중단 플래그가 없습니다.³ 여기 나온 미해결 이슈 중 네 건이 이 키와 관련되어 있으므로, 지원 중단 표시가 없다는 것을 권장으로 읽어서는 안 됩니다.

Apple이 이 조건을 고치면 우회책을 걷어내야 하나요?

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

피해야 할 실패 방식은 그 반대입니다. Info.plist를 다시 좁히면서, 캡처 화면을 똑바로 세워 두던 유일한 장치가 그 재정의였다는 사실을 잊는 것입니다.

제 앱이 지금 연속 크기 조절이 되는지는 어떻게 아나요?

iPad에서 창 크기를 조절해 보고 레이아웃이 드래그를 따라가는지, 아니면 마지막에 딱 맞춰지는지 보세요. 따라간다면 연속 크기 조절이 되는 것입니다. 딱 맞춰진다면 두 가지를 확인하세요. 동적 크기 조절에서 완전히 빠지게 만드는 UIRequiresFullScreen이 설정되어 있는지, 그리고 UISupportedInterfaceOrientations가 네 방향을 모두 나열하는지입니다. 후자가 이 알려진 이슈가 말하는 조건입니다.¹³

더 오래된 SDK로 빌드하면 이 모든 것을 피할 수 있나요?

각 항목은 iOS 27 SDK로 빌드하는 것을 조건으로 삼습니다.¹ 더 오래된 SDK는 이 특정 이슈들을 피하게 해 주지만, 결국 올 변화를 막는 것이 아니라 미루는 것입니다.

출처