ITMS-90474 iPad 방향 오류: Archive의 전용 배열 확인하기

먼저 답하면

ITMS-90474에 iPad Multitasking support requires these orientations가 보이면, 제출할 앱의 Info.plist에서 UIDeviceFamily, 기본 방향 배열, UISupportedInterfaceOrientations~ipad를 함께 확인한다. iPad 전용 배열이 있으면 기본 배열이 네 방향이어도 그 전용 배열이 두 방향으로 남을 수 있다.

먼저 Xcode Organizer에서 문제가 난 Archive를 선택하고 Finder에서 위치를 연다. .xcarchive 안의 Products/Applications/자기앱.app/Info.plist가 읽을 파일이다. 아래 첫 줄을 그 실제 파일의 경로로 바꾼다. 공백이 있어도 따옴표는 유지한다.

ORIENTATION_PLIST="/실제경로/자기앱.xcarchive/Products/Applications/자기앱.app/Info.plist"
plutil -extract UIDeviceFamily json -o - "$ORIENTATION_PLIST"
plutil -extract UISupportedInterfaceOrientations json -o - "$ORIENTATION_PLIST"
plutil -extract 'UISupportedInterfaceOrientations~ipad' json -o - "$ORIENTATION_PLIST"

[1,2]는 iPhone과 iPad를 지원하는 선언이다. 전용 배열의 출력이 LandscapeLeft, LandscapeRight 두 값뿐이라면 세로 두 값이 빠져 있다. 고칠 것은 프로젝트 입력이며, Archive 안의 파일을 직접 고쳐 제출하지 않는다. 전용 키가 없다는 오류는 곧 방향 전체가 없다는 뜻이 아니다. 기본 배열을 확인하는 분기로 이어진다.

전용 배열이 기본 배열과 다른 이유

Apple의 기기별 키 설명은 ~ipad를 iPad 전용 한정자로 정의한다. 기기·플랫폼에 가장 구체적인 키를 찾고, 해당 키가 없으면 한정자 없는 기본 키로 돌아간다. 따라서 기본 네 방향을 선언했다고 iPad 전용 배열까지 네 방향으로 바뀌지는 않는다.

네 값은 다음과 같다. 과거 Slide Over/Split View 가이드에도 iPad의 네 방향 선언이 나온다. 이 자료는 iOS 9·Xcode 7용이므로 당시 메뉴 그림과 전체 화면 탈퇴 안내를 현재 해결책으로 복사하지 않는다.

UIInterfaceOrientationPortrait
UIInterfaceOrientationPortraitUpsideDown
UIInterfaceOrientationLandscapeLeft
UIInterfaceOrientationLandscapeRight

최종 파일에서 읽은 상태	다음 확인·수정
기기군에 2가 있고 전용 배열이 있음	전용 배열에서 빠진 방향을 프로젝트 입력에 보강한다. 기본 배열만 고치고 끝내지 않는다.
기기군에 2가 있고 전용 키가 없음	기본 배열을 읽어 네 값이 있는지 확인한다. 키 없음 오류만으로 전용 키를 무조건 추가하지 않는다.
기기군에 2가 없음	오류의 번들 식별자·Archive·타깃이 일치하는지 먼저 확인한다. 다른 앱이나 오래된 산출물을 검사했을 수 있다.
이미 네 값이 있음	실제로 업로드한 파일과 검사한 파일이 같은지 확인한다. 이 절차로 해결되지 않은 검사 원인은 오류 전체와 함께 다시 조사한다.

기기군은 Apple의 UIDeviceFamily 설명에 따라 Xcode의 TARGETED_DEVICE_FAMILY에서 만들어진다. iPad 지원을 유지할 앱에서 2를 지우는 것은 방향 수정이 아니라 지원 대상 변경이다. 입력 plist에 이 값을 수동으로 덧붙이지 않는다.

두 방향에서 네 방향으로 바꾸는 독립 예제

OrientationProbe.zip 받기를 풀고 터미널에서 OrientationProbe 폴더로 이동한다. Xcode와 iPhoneOS SDK가 설치된 Mac이 필요하다. 프로젝트 파일이 들어 있어 XcodeGen·추가 패키지·Apple 계정은 필요 없다. 아래는 서명하지 않는 로컬 확인용 Archive다. 실제 제출용 빌드의 서명을 끄라는 뜻이 아니다.

xcodebuild -project OrientationProbe.xcodeproj -scheme OrientationProbe \
  -configuration Release -destination 'generic/platform=iOS' \
  -archivePath Probe.xcarchive -derivedDataPath DerivedData \
  CODE_SIGNING_ALLOWED=NO archive

ORIENTATION_PLIST="Probe.xcarchive/Products/Applications/OrientationProbe.app/Info.plist"
plutil -extract 'UISupportedInterfaceOrientations~ipad' json -o - "$ORIENTATION_PLIST"

첫 출력은 다음 두 값이다.

["UIInterfaceOrientationLandscapeLeft","UIInterfaceOrientationLandscapeRight"]

받은 예제의 **입력 Info.plist**에서 전용 배열을 바꾼다. 이 명령은 해당 키가 이미 있는 예제용이다.

plutil -replace 'UISupportedInterfaceOrientations~ipad' -json \
  '["UIInterfaceOrientationPortrait","UIInterfaceOrientationPortraitUpsideDown","UIInterfaceOrientationLandscapeLeft","UIInterfaceOrientationLandscapeRight"]' \
  Info.plist

그다음 첫 빌드 명령의 -archivePath Probe.xcarchive만 -archivePath Fixed.xcarchive로 바꿔 새 Archive를 만든다. 읽을 경로도 바꾼다.

ORIENTATION_PLIST="Fixed.xcarchive/Products/Applications/OrientationProbe.app/Info.plist"
plutil -extract 'UISupportedInterfaceOrientations~ipad' json -o - "$ORIENTATION_PLIST"

["UIInterfaceOrientationPortrait","UIInterfaceOrientationPortraitUpsideDown","UIInterfaceOrientationLandscapeLeft","UIInterfaceOrientationLandscapeRight"]

전용 배열만 고친 뒤 새 Archive의 출력에 세로 두 값이 추가됐다. 실제 앱에서는 먼저 앱 타깃·Release 구성의 INFOPLIST_FILE과 GENERATE_INFOPLIST_FILE을 확인한다. 입력 파일을 쓰면 그 파일의 방향 배열을, 파일 없이 생성하면 앱 타깃의 방향 설정을 수정한다. 예제의 Info.plist 경로를 자기 프로젝트에 그대로 적용하지 않는다. 입력이 올바른지 모르겠다면 자기 프로젝트·스킴으로 다음처럼 설정을 조회한다. workspace 프로젝트는 -project ... 대신 -workspace 자신의파일.xcworkspace를 쓴다.

xcodebuild -project OrientationProbe.xcodeproj -scheme OrientationProbe \
  -configuration Release -destination 'generic/platform=iOS' \
  -showBuildSettings > build-settings.txt

여러 타깃이 나오면 앱 타깃 구획을 읽는다. 설정을 바꾼 뒤에는 원래 제출 절차대로 다시 Archive·서명·내보내기하고 새 산출물의 값을 재확인한다. 이미 내보낸 IPA를 제출한다면 그 IPA도 새 Archive에서 만든 파일인지 확인해야 한다.

Archive 세 사례의 관측 결과

2026년 10월 10일 Xcode 27.0(27A266a), iPhoneOS 27.0 SDK, Release, SwiftUI 최소 앱을 별도 폴더에서 빌드했다. 기기군은 세 사례 모두 [1,2]였고 UIRequiresFullScreen은 넣지 않았다. 세 Archive 모두 생성에 성공했지만 이것은 업로드 검사 통과가 아니다.

프로젝트 입력	최종 기본 배열	최종 iPad 전용 배열
기본 네 값 + 전용 가로 두 값	네 값	가로 두 값
전용 배열만 네 값으로 수정	네 값	네 값
전용 키 제거, 기본 네 값 유지	네 값	키 없음

세 번째는 기본 배열로 돌아갈 수 있다는 공식 규칙과 대조하기 위한 사례다. 기기에서 실제 키 선택이나 화면 회전을 관측한 시험은 아니다. 첫 사례가 오류 메시지와 같은 종류의 누락을 가지고 있어도 이번 시험에서 ITMS-90474를 직접 재발생시킨 것은 아니다. 배포할 ZIP을 새 폴더에서 다시 풀어 첫·수정 Archive와 출력값도 재확인했다.

UIRequiresFullScreen을 넣으면 끝인가

오래된 질문 답변에는 이 키를 true로 넣으라는 해결책이 있다. 그러나 Apple TN3192의 2026년 8월 13일 갱신 내용과 구분해야 한다.

• iPadOS 26부터 해당 호환 모드는 사용 중단 권고 대상이다. “26에서 이미 무조건 무시된다”는 설명은 정확하지 않다.
• iOS/iPadOS 27에서 iOS 27 SDK로 빌드한 앱은 YES를 넣어도 크기 변경에서 탈퇴하는 대신 장면 크기를 단계적으로 바꾸는 동작을 한다. 별도의 버전별 무시 설정도 있어 적용 조건을 확인해야 한다.

TN3192는 크기 변경 가능한 장면을 위해 시작 화면, 모든 인터페이스 방향, 해당 키에서 벗어나는 업데이트를 함께 안내한다. 방향 배열만 네 개로 채워도 실제 레이아웃이 크기 변화에 대응한다는 뜻은 아니다. 방향을 추가할 앱은 회전과 창 크기 변경에서도 입력·버튼·콘텐츠가 제대로 작동하는지 별도로 시험해야 한다. 고정 가로 화면 요구가 있는 게임이라면 방향 잠금·장면 크기 대응 설계를 먼저 검토한다.

이 글은 서명, 실제 App Store Connect 업로드, 내보낸 IPA, 실기기 회전, 멀티태스킹과 기존 앱의 레이아웃을 시험하지 않았다. 이 절차가 끝내는 일은 누락된 방향 선언을 찾아 수정하고 최종 Archive에 반영됐는지 확인하는 것이다. 이후에는 원래의 서명·업로드 검사를 다시 실행해 같은 오류가 사라졌는지 확인한다. 다른 오류가 나오면 그 내용을 별도 원인으로 다룬다.