iOS 27 런치 스크린 규칙: 네 개의 키냐, 리젝이냐

Apple의 iOS 27 릴리스 노트는 문서에 적혀 있던 한 문장을 심사 관문으로 바꿔 놓았습니다. “27.0 SDK 이상으로 빌드한 iOS 및 iPadOS 앱은 런치 스크린을 포함해야 합니다. 앱의 Info.plist에는 UILaunchStoryboardName, UILaunchStoryboards, UILaunchScreen, UILaunchScreens 중 하나가 반드시 들어 있어야 합니다. 런치 스크린이 없는 앱은 App Store가 27.0 SDK 빌드를 받기 시작하는 시점부터 리젝됩니다.”¹

요구사항 자체는 오래된 것입니다. Apple의 Xcode 문서는 “모든 iOS 앱은 런치 스크린을 제공해야 합니다”라는 문장으로 시작합니다.² iOS 27에서 새로 생긴 건 이걸 무시했을 때의 결과입니다.

요약

• iOS 27.0 SDK 이상으로 빌드한 앱은 네 개의 Info.plist 키 중 하나로 런치 스크린을 선언해야 하고, 선언하지 않은 빌드는 App Store가 리젝합니다.¹
• 걸리는 지점은 심사 제출이지 실행 시점이 아닙니다. Apple의 표현은 “App Store가 27.0 SDK 빌드를 받기 시작하는 시점부터 리젝된다”이므로, 실패는 사용자 기기가 아니라 App Store Connect에서 드러납니다.¹
• 이 규칙이 명시한 플랫폼은 iOS와 iPadOS뿐입니다. Apple은 같은 노트에서 tvOS, visionOS, Mac Catalyst로 범위를 넓히지 않았습니다.¹ 같은 주기에 들어오는 씬 생명주기 의무화는 성격이 다릅니다. 그쪽 마이그레이션 문서는 iOS 27, iPadOS 27, Mac Catalyst 27, tvOS 27, visionOS 27을 이름으로 못 박습니다.³
• 네 개의 키 중 둘은 단일 런치 스크린을 담당하고(UILaunchScreen은 프로퍼티 리스트 안에서 화면을 구성하고, UILaunchStoryboardName은 스토리보드 파일 이름을 가리킵니다), 나머지 둘은 URL 스킴별 변형을 담당합니다(UILaunchScreens, UILaunchStoryboards). 넷 중 셋은 딕셔너리이고, UILaunchStoryboardName만 문자열입니다.⁴⁵⁶⁷
• 최근 Xcode 템플릿으로 만든 프로젝트는 이미 이 규칙을 충족하는데, 충족 방식이 파일이 아니라 빌드 설정입니다.⁸¹¹ 그래서 저장소에서 네 개의 키를 grep으로 훑는 방식으로 점검하면 답 자체를 놓칩니다.

규칙을 정확히 말하면

Apple의 문장에는 무게가 실린 지점이 세 군데 있는데, 관련 기사들은 대개 이 셋을 뭉뚱그립니다.

첫째, 규칙을 촉발하는 것은 사용자가 쓰는 OS가 아니라 여러분이 빌드에 사용한 SDK입니다. iOS 26으로 컴파일한 바이너리는 스토어에 그대로 남아 있습니다. 새 SDK의 기능을 쓰려고 Xcode 27로 다시 빌드하는 순간 이 요구사항도 함께 따라붙습니다.

둘째, 강제가 일어나는 지점은 App Store의 빌드 수용 단계입니다. Apple이 쓴 단어는 “리젝(rejected)”이고, 이는 실패가 앱 실행이 아니라 심사 제출에서 발생한다는 뜻입니다. 이 점이 같은 주기에 들어오는 씬 생명주기 의무화와 런치 스크린 규칙을 갈라놓습니다. 씬 생명주기 쪽에서 Apple이 쓴 표현은 앱이 “실행되지 않는다(fail to launch)”입니다.¹ 한쪽은 빌드 하나가 리젝되는 비용이고, 다른 한쪽은 사용자 손에 든 폰에서 앱이 죽는 비용입니다.

셋째, 적용 범위는 iOS와 iPadOS입니다. Apple의 노트는 이 두 플랫폼만 이름으로 적고 끝냅니다. Catalyst나 tvOS 타깃을 유지 중이라면, 이 요구사항은 유추로 확장된 것이 아니라 아직 언급되지 않은 상태로 읽어야 합니다. 27 주기는 다섯 플랫폼에 걸친 씬 생명주기부터 Image Playground에서 빠지는 ImageCreator까지 곳곳에서 규칙을 강제하지만, 런치 스크린 노트만큼은 범위가 좁게 유지됩니다.

네 개의 키 중 무엇을 쓸 것인가

Apple은 런치 스크린을 만드는 방식 두 가지와, 화면이 하나냐 여럿이냐 두 가지를 제공하고, 그 조합에서 네 개의 키가 나옵니다.

UILaunchScreen은 스토리보드 파일 없이 프로퍼티 리스트 안에서 런치 인터페이스를 직접 구성합니다. Apple은 이를 “스토리보드에 의존하지 않는 방식으로 앱 실행 중 사용자 인터페이스를 구성하는” 방법이라고 설명하며, 배경색, 이미지, 그리고 내비게이션 바·탭 바·툴바의 표시 여부를 지정하는 하위 키를 받습니다.⁴ 첫 화면이 단색 배경뿐인 앱이라면 빈 UILaunchScreen 딕셔너리만으로 규칙이 충족됩니다. Xcode의 빌드 시스템도 이 경로를 택합니다. “GENERATE_INFOPLIST_FILE이 활성화되어 있으면” INFOPLIST_KEY_UILaunchScreen_Generation이 “Info.plist 파일의 UILaunchScreen 키 값을 빈 딕셔너리로 설정합니다.”⁸

UILaunchStoryboardName은 확장자를 뺀 파일 이름으로 스토리보드를 가리킵니다. LaunchScreen.storyboard 파일이라면 값은 문자열 LaunchScreen이 됩니다.⁵ iOS 9부터 있던 키이고, 넷 중 유일하게 딕셔너리가 아니라 문자열을 받습니다.⁵ 디자인된 런치 스크린이 있는 앱, 또는 Xcode가 지금도 스토리보드 템플릿에 넣어 주는 LaunchScreen.storyboard를 함께 배포하는 프로젝트라면 이 키가 맞습니다.²

복수형 키 두 개는 아주 특정한 상황을 위해 존재하며, 둘 다 배열이 아니라 딕셔너리입니다.⁶⁷ UILaunchScreens는 하위 키 세 개를 담습니다. 각각 UILaunchScreenIdentifier를 갖는 런치 스크린 구성들의 배열인 UILaunchScreenDefinitions, URL 스킴과 식별자를 연결하는 UIURLToLaunchScreenAssociations, 그리고 기본값인 UIDefaultLaunchScreen입니다.⁶ UILaunchStoryboards는 UILaunchStoryboardDefinitions, UIURLToLaunchStoryboardAssociations, UIDefaultLaunchStoryboard로 같은 구조를 그대로 따릅니다.⁷ 둘 중 어느 쪽이든, myapp://compose로 열린 앱이 홈 화면에서 열린 같은 앱과 다른 실행 화면을 보여 줄 수 있게 해 줍니다. Apple은 대부분의 앱이 이걸 건너뛰어야 한다고 분명히 말합니다. “런치 스크린이 하나만 필요하다면 UILaunchScreen을 대신 사용하세요.”⁶

실무에서의 판단은 질문 하나로 줄어듭니다. 런치 스크린이 스토리보드라면 UILaunchStoryboardName을 선언하세요. 아니라면 UILaunchScreen을 선언하세요. 복수형 키는 왜 필요한지 이미 알고 있을 때만 손을 대면 됩니다.

실제로 걸리는 앱들

현재 Xcode 템플릿으로 만든 앱은 아무도 손대지 않아도 통과합니다. 이 규칙을 대수롭지 않게 넘기기 쉬운 이유이자, 동시에 방심하다 걸리기 쉬운 이유이기도 합니다. 위험군에는 공통점이 하나 있습니다. 팀의 누구도 최근에 Info.plist를 손으로 쓴 적이 없다는 것입니다.

가장 큰 부류는 생성된 프로퍼티 리스트이고, 가장 큰 생성기는 Xcode 자신입니다. Xcode 13이 기본값을 바꿨습니다. 여러 템플릿으로 만든 프로젝트는 “엔타이틀먼트나 Info.plist 같은 구성 파일을 더 이상 필요로 하지 않으며”, 해당 항목들은 타깃의 Info 탭과 빌드 설정 편집기에서 구성합니다.⁹ 여기에 크로스 플랫폼 툴체인, 래퍼 프레임워크, 패키징 시점에 plist를 합성하는 빌드 스크립트가 두 번째 층을 얹는데, 이들의 템플릿은 UILaunchScreen보다 오래됐을 수도 있습니다. 빌드 시스템이 써 주는 파일은 아무도 들여다보지 않습니다.

두 번째 부류는 항목이 지워진 plist입니다. 런치 스토리보드는 용량 최적화 과정에서, Interface Builder를 걷어내는 마이그레이션 과정에서, 또는 프로젝트의 마지막 스토리보드를 정리하다가 런치 스크린까지 함께 딸려 나가면서 사라집니다. 지운 뒤에도 빌드가 계속됐으니 안전해 보였던 것입니다.

세 번째는 물려받은 프로젝트인데, 이 집단은 대부분의 기사가 가정하는 것보다 훨씬 좁습니다. UILaunchStoryboardName은 iOS 9에 나왔으므로, 2015년부터 이어져 온 프로젝트라면 이미 조건을 만족하는 키를 갖고 있습니다.⁵ 네 개 중 아무것도 없는 앱은 그보다 더 오래된 쪽입니다. 즉 아직도 UILaunchImages로 실행 화면 이미지를 선언하는 앱들이죠. iOS 7.0에 도입된 이 키를 Apple은 iOS 13.0에서 한 줄짜리 안내와 함께 폐기했습니다. “UILaunchImages는 폐기되었습니다. 대신 Xcode 런치 스토리보드를 사용하세요.”¹⁰ UILaunchImages 배열은 Apple이 제시한 네 개의 목록에 없으므로, 여전히 여기에 의존하면서 스토리보드 참조를 도입한 적이 없는 프로젝트에는 요구사항이 인정할 만한 것이 하나도 없는 셈입니다. 10년치 Xcode 업그레이드를 거쳐도 키가 생겼을 리 없습니다. 빌드에서 아무것도 실패한 적이 없었으니까요.

빌드 시스템이 써 주는 Info.plist 점검하기

파일이 아예 없을 수도 있다는 사실을 받아들이는 데서 시작하세요. GENERATE_INFOPLIST_FILE은 자동 생성을 켜고, INFOPLIST_KEY_* 빌드 설정 하나하나가 빌드 산출물 plist에 키를 하나씩 씁니다.⁸ 런치 스크린에 해당하는 설정은 둘입니다. 빈 UILaunchScreen 딕셔너리를 써 넣는 INFOPLIST_KEY_UILaunchScreen_Generation, 그리고 스토리보드 이름을 써 넣는 INFOPLIST_KEY_UILaunchStoryboardName입니다.⁸ 어느 쪽도 텍스트 검색으로 찾을 만한 흔적을 남기지 않습니다. 현재 Xcode의 iOS SwiftUI App 템플릿은 공유 설정에 INFOPLIST_KEY_UILaunchScreen_Generation = YES를 넣어 배포하므로, 그렇게 만든 프로젝트는 저장소 어디에도 런치 스크린 관련 텍스트가 없는 상태로 규칙을 충족하는 타깃을 갖게 됩니다.¹¹

파일 시스템 대신 빌드 시스템에 물어보세요.

xcodebuild -showBuildSettings \
  -project YourApp.xcodeproj -target YourApp \
  -configuration Release -sdk iphoneos 2>/dev/null \
  | grep -E "^ +(GENERATE_INFOPLIST_FILE|INFOPLIST_FILE|INFOPLIST_KEY_UILaunch)"

제 컴퓨터의 Ace Citizenship 프로젝트에 대해 실행하면 세 줄이 돌아옵니다.¹¹

    GENERATE_INFOPLIST_FILE = YES
    INFOPLIST_FILE = Ace-Citizenship-Info.plist
    INFOPLIST_KEY_UILaunchScreen_Generation = YES

세 번째 줄이 규정 준수 여부에 대한 답 전부이고, 저장소의 어떤 파일에도 그 문자열은 없습니다. 출력은 이 순서로 읽으세요. GENERATE_INFOPLIST_FILE = YES에 더해 INFOPLIST_KEY_UILaunch 줄이 YES로 설정돼 있다면, 빌드 시스템이 키를 대신 써 준다는 뜻입니다. Apple은 모든 INFOPLIST_KEY_* 설정이 생성 기능 활성화를 전제로 동작하도록 해 두었으므로, GENERATE_INFOPLIST_FILE = NO인 상태에서는 같은 줄이 아무 효력이 없고, 값이 NO라면 어느 쪽이든 아무것도 쓰이지 않습니다.⁸ 생성이 꺼져 있다면 런치 스크린 키가 있어야 할 곳은 INFOPLIST_FILE 경로이므로, 그 파일을 열어 넷 중 하나가 있는지 확인하세요. 생성이 켜져 있고 파일 경로도 있다면 빌드 시스템이 둘을 병합하며, 어느 쪽에 있든 요구사항은 충족됩니다.⁸

두 플래그 모두 제 몫을 합니다. -configuration Release가 중요한 이유는 App Store 심사가 보는 것이 Release 산출물이기 때문입니다. -sdk iphoneos가 중요한 이유는 멀티플랫폼 타깃에서 Xcode가 이 설정들을 SDK별로 나눠 쓰기 때문입니다. Reps 프로젝트는 INFOPLIST_KEY_UILaunchScreen_Generation을 [sdk=iphoneos*], [sdk=iphonesimulator*], [sdk=appletv*]에 하나씩 총 세 번 선언하고, Banana List는 앞의 둘을 선언합니다. -sdk iphoneos를 빼면 그중 어느 것도 해석되지 않아 출력에서 키가 사라지고, 규칙을 충족하는 타깃이 위반 상태로 보이게 됩니다.¹¹

그다음에는 실제로 제출하는 산출물을 확인하세요. plutil -p 출력에서 앞쪽 공백 두 칸은 최상위 키를 뜻합니다.

plutil -p YourApp.xcarchive/Products/Applications/*.app/Info.plist \
  | grep -E '^  "UILaunch'

4월에 배포용으로 빌드한 Return 아카이브에 대해 실행하면 한 줄이 돌아오고, 런치 스크린이 없는 번들에 같은 명령을 실행하면 아무것도 출력하지 않은 채 1로 종료합니다.¹¹

  "UILaunchScreen" => {

여기서는 PlistBuddy가 아니라 plutil을 쓰세요. 존재하지 않는 경로를 주면 PlistBuddy -c "Print"는 표준 출력에 “File Doesn’t Exist, Will Create:”와 빈 Dict { }를 찍고 0으로 종료합니다. 이걸 런치 스크린 키를 찾는 grep에 그대로 넘기면 실수를 드러내는 유일한 줄이 삼켜지고, 남는 건 키가 없을 때와 똑같이 보이는 빈 출력뿐입니다. plutil은 열지 못한 파일 이름을 알려 주고 1로 종료합니다.¹¹

저장소 전체를 훑는 작업에도 여전히 역할은 있지만, 보이는 것보다 훨씬 작은 역할입니다. 읽어 볼 가치가 있는, 손으로 관리되는 plist를 찾아내는 일이죠.

find . -name "Info.plist" \
  -not -path "*/build/*" -not -path "*/DerivedData/*" \
  -not -path "*/.build/*" -not -path "*/Carthage/*" -not -path "*/Pods/*" \
  -print0 | xargs -0 grep -L -E "UILaunchScreen|UILaunchStoryboard"

여기서 출력되는 경로는 전부 빌드 설정과 대조해 볼 후보이지, 제출에서 실패할 타깃이 아닙니다. Banana List에서는 정확히 한 줄, ./Banana List/Info.plist가 돌아오는데, 그 타깃도 결국 런치 스크린을 갖고 있습니다. 빌드 설정에 INFOPLIST_KEY_UILaunchScreen_Generation이 들어 있고, 아카이브된 번들에는 UILaunchScreen이 있습니다. 제외 조건을 빼면 같은 명령이 그 저장소에서 25줄을 돌려주는데, 그중 24개는 build/ 안의 빌드 산출물이고 테스트 러너 번들, XCTest.framework, .xcresult 로그, 워치 앱까지 섞여 있습니다.¹¹

키를 손으로 추가하는 일은 텍스트 편집이 아니라 몇 단계짜리 작업입니다. Apple이 안내하는 순서는 이렇습니다. 타깃 설정에서 Info 탭을 선택하고, Custom iOS Target Properties 섹션에서 Launch Screen 키를 펼친 다음, Add 버튼을 눌러 UILaunchScreen을 입력하고 Return 키를 누릅니다. 그런 다음 UILaunchScreen 키를 선택하고 Add를 다시 눌러 원하는 외형 옵션에 해당하는 하위 키를 추가합니다.² Xcode가 생성하는 plist라면, 타깃 빌드 설정에서 INFOPLIST_KEY_UILaunchScreen_Generation을 YES로 두는 것이 같은 역할을 하고 다음 빌드에서도 살아남습니다.⁸ Xcode가 아닌 다른 도구가 생성하는 plist라면 그 생성기의 템플릿을 고치세요. 산출물을 아무리 편집해도 다음 빌드가 지워 버립니다.

규칙이 말하지 않은 것

Apple은 구체적인 날짜를 발표하지 않았습니다. 시점은 “App Store가 27.0 SDK 빌드를 받기 시작하는 시점”이라는 표현으로만 제시되어 있고, 전례상 가을 OS 출시 즈음이긴 하지만 이번 주기에 대해 Apple이 문서로 못 박은 바는 없습니다.¹ 어디선가 특정 날짜를 봤다면 추정으로 취급하세요.

Apple은 기존 앱이 동작을 멈춘다거나, TestFlight 빌드가 영향을 받는다거나, 요구사항이 iOS와 iPadOS를 넘어 확장된다고도 말하지 않았습니다. 이 노트가 다루는 것은 새 빌드의 제출이며, 그 외에는 아무것도 없습니다.

수정 자체는 워낙 작아서, 정작 흥미로운 질문은 어떻게 준수하느냐가 아니라 이미 준수하고 있느냐입니다. 손으로 관리해 온 프로젝트라면 답은 거의 확실히 “그렇다”입니다. plist가 생성되는 프로젝트라면, 스토어가 리젝을 내기 시작하기 전에 빌드 시스템에 물어 확인해 둘 값어치가 있습니다.

자주 묻는 질문

현재 Xcode 템플릿으로 만든 앱은 이미 요구사항을 충족하나요?

거의 확실히 충족하며, 그 근거는 파일이 아니라 빌드 설정에 있습니다. Xcode의 iOS SwiftUI App 템플릿은 공유 설정에 INFOPLIST_KEY_UILaunchScreen_Generation = YES를 지정하고, 이 설정이 빌드 시스템이 만들어 내는 Info.plist에 빈 UILaunchScreen 딕셔너리를 써 넣습니다.⁸¹¹ -sdk iphoneos와 함께 Release 구성으로 xcodebuild -showBuildSettings를 실행해 INFOPLIST_KEY_UILaunch 줄이 있는지 보면 확인할 수 있습니다.

저장소에서 UILaunchScreen을 grep해도 아무것도 안 나오는 이유는 뭔가요?

Xcode 13 이후 여러 템플릿으로 만든 프로젝트에는 디스크상에 Info.plist가 없기 때문입니다. Apple이 해당 항목들을 타깃의 Info 탭과 빌드 설정 편집기로 옮겼습니다.⁹ 런치 스크린은 빌드 시점에 INFOPLIST_KEY_UILaunchScreen_Generation 또는 INFOPLIST_KEY_UILaunchStoryboardName에서 만들어집니다.⁸ 소스 파일을 대상으로 한 텍스트 검색은 둘 중 어느 설정도 볼 수 없고, 그렇게 해서 걸리는 Info.plist 파일들은 대개 빌드 시스템이 병합하는 부분 조각이거나 build/와 DerivedData/ 아래의 빌드 산출물입니다.

정말로 하나도 없다면 어떤 키를 추가해야 하나요?

LaunchScreen.storyboard를 함께 배포한다면 UILaunchStoryboardName, 그렇지 않다면 UILaunchScreen입니다.⁴⁵ 단색 배경으로 실행되는 앱이라면 빈 UILaunchScreen 딕셔너리로 충분하고, Xcode가 기본으로 생성하는 것도 바로 그것입니다.⁸ URL 스킴마다 서로 다른 실행 화면을 보여 주는 경우가 아니라면 UILaunchScreens와 UILaunchStoryboards는 건너뛰세요. Apple의 안내도 “런치 스크린이 하나만 필요하다면 UILaunchScreen을 대신 사용하세요”입니다.⁶

이 요구사항이 TestFlight 빌드에도 적용되나요?

Apple의 노트는 그 부분을 말하지 않습니다. 명시된 결과는 “App Store가 27.0 SDK 빌드를 받기 시작하는 시점”의 리젝 하나뿐이고, TestFlight 배포는 어디에도 등장하지 않습니다.¹ TestFlight 빌드도 App Store Connect와 베타 심사를 거치므로, 요구사항을 충족하지 못한 빌드는 심사를 만나는 모든 지점에서 실패한다고 보는 편이 안전하지만, Apple이 그렇게 적어 둔 적은 없습니다. 이 답에 의존해야 하는 상황이라면, 침묵을 어느 쪽으로든 해석하기보다 27.0 SDK 빌드를 실제로 업로드해서 확인하세요.

핵심 정리

iOS 개발자에게: - 파일을 grep하기 전에 빌드 설정을 조회하세요. xcodebuild -showBuildSettings -configuration Release -sdk iphoneos를 실행하고 INFOPLIST_KEY_UILaunchScreen_Generation 또는 INFOPLIST_KEY_UILaunchStoryboardName을 찾으세요.⁸ 저장소 텍스트 검색으로는 둘 다 보이지 않습니다. - 런치 스토리보드를 배포한다면 UILaunchStoryboardName을, 아니라면 UILaunchScreen을 선택하세요. URL 스킴별로 다른 실행 화면을 제공하는 경우가 아니면 복수형 키는 건너뛰세요.

크로스 플랫폼 툴체인으로 배포하는 팀에게: - 소스 관리에 들어 있는 파일이 아니라 아카이브된 .app 번들을 plutil -p로 점검하세요. 심사가 보는 것은 생성기의 산출물이고, 잘못된 경로가 주어졌을 때 PlistBuddy는 빈 딕셔너리를 찍고 0으로 종료하는 반면 plutil은 오류를 분명히 알리며 실패합니다. - 생성된 파일이 아니라 빌드 구성에 있는 plist 템플릿을 고치세요. 그러지 않으면 다음 빌드가 수정을 지워 버립니다.

릴리스 담당자에게: - 실패는 실행 시점이 아니라 App Store 제출 시점에 드러나므로, 대가는 운영 장애가 아니라 심사 한 번입니다. 점검은 리젝을 받은 뒤가 아니라 첫 27.0 SDK 제출 전에 잡아 두세요. - 이 점검은 씬 생명주기 마이그레이션과 함께 묶어서 하세요. 촉발 조건은 같고 대가는 더 가혹합니다.

27 주기는 권고 사항을 강제 규정으로 계속 바꿔 나가고 있습니다. ImageCreator는 동작을 멈추고, 씬 생명주기는 실행 요건이 되며, 런치 스크린은 제출 관문이 됩니다. 같은 SDK에 함께 들어오는 나머지 변화는 iOS 27 SwiftUI의 새로운 기능에서 확인하세요. 시리즈 전체는 Apple 생태계 시리즈에 모여 있습니다.

참고 문헌