iOS 27 시작 화면 누락: 2026년 App Store 제출은 어떻게 수정하나요?

판단 기준은 최소 배포 버전이 아닙니다. 이번 검증의 직접 조건은 앱을 iOS 27 SDK 이상으로 빌드했는지입니다. IPHONEOS_DEPLOYMENT_TARGET이 iOS 26 이하인지 여부만으로 영향을 판단하면 안 됩니다.

Xcode 26 정식 출시 경로에서 iOS 26 SDK로 만든 생산 보관 파일은 기존 절차를 유지할 수 있습니다. 반면 Xcode 27 Beta 5에서 iOS 27 SDK로 만든 빌드는 시작 화면 선언을 먼저 확인해야 합니다. Apple은 Xcode 27 Beta 5 빌드를 TestFlight에 업로드할 수 있다고 안내하지만, 베타 빌드 업로드 가능성을 정식 App Store 생산 제출 승인과 동일하게 보면 안 됩니다.

Apple이 Xcode 27 정식 버전의 출시일이나 App Store가 iOS 27 SDK 빌드를 생산용으로 받기 시작하는 구체적인 날짜를 공식 확정한 자료는 여기서 확인하지 않습니다. 따라서 “가을부터 무조건 제출 불가”처럼 날짜를 정해 작업하면 안 됩니다.

최종 앱의 Info.plist에는 Apple이 인정하는 시작 화면 키가 하나 이상 있어야 합니다. 대표적인 방식은 UILaunchScreen 선언과 LaunchScreen.storyboard 연결입니다. Apple의 UILaunchScreen 설명은 이 키가 앱의 시작 화면 구성을 나타내는 위치를 설명합니다.

선택은 프로젝트 상태에 따라 나눕니다.

iOS 27 시작 화면에는 UILaunchScreen과 LaunchScreen.storyboard 중 무엇을 선택해야 하나요?

둘 중 하나를 모든 프로젝트에 강제로 적용할 필요는 없습니다. 새 프로젝트나 단순한 시작 화면은 UILaunchScreen 선언을 검토할 수 있습니다. 기존 UIKit 프로젝트가 이미 LaunchScreen.storyboard를 사용한다면, 유효한 파일과 대상 연결을 유지하는 편이 변경 범위가 작습니다. 중요한 것은 키만 채우는 것이 아니라 실제 리소스와 빌드 설정이 서로 맞는지 확인하는 것입니다. Apple의 시작 화면 구성 문서도 프로젝트 방식에 맞는 구성을 전제로 합니다.

빈 문자열, 존재하지 않는 파일 이름, 대상에서 제외된 스토리보드를 넣어 서버 검사를 통과시키려 하면 안 됩니다. 로컬 설정은 통과해도 실제 앱 화면이 비거나 이전 이미지가 남을 수 있습니다.

SwiftUI 프로젝트에서 자동 생성 Info.plist를 사용해도 오류가 사라진다는 보장은 없습니다. 자동 생성 설정은 대상별로 다를 수 있고, 빌드 스크립트가 보관 단계에서 값을 다시 작성할 수도 있습니다.

UIKit 프로젝트는 수동 plist를 직접 고치는 경우가 많습니다. 그러나 Debug 설정만 바꾸고 Release 설정을 빠뜨리면 개발 실행은 정상인데 제출 파일에서 ITMS-90870이 다시 발생합니다. Apple의 빌드 설정 참고 문서를 기준으로 Scheme, Configuration, 대상별 값을 분리해서 기록해야 합니다.

크로스 플랫폼 프로젝트는 생성 명령 뒤에 iOS 프로젝트가 다시 만들어지는지 확인합니다. 생성 파일을 수정했는데 다음 빌드에서 원래 값으로 돌아간다면, 원인은 plist가 아니라 생성 템플릿이나 빌드 훅일 수 있습니다.

다음 검색 의도도 이 지점에서 해결됩니다. SwiftUI에서 자동 생성 Info.plist인데도 시작 화면 오류가 남는 이유는 “자동 생성”이 최종 바이너리의 값을 보장하지 않기 때문입니다. 반드시 Archive 안의 앱을 기준으로 판단해야 합니다.

소스 파일에 올바른 키가 보여도 최종 앱에 없을 수 있습니다. 보관 단계에서 다른 Configuration을 사용하거나, 스크립트가 plist를 병합하거나, 다른 앱 대상을 선택하면 결과가 달라집니다.

보관 파일 안의 앱에 시작 화면 설정이 포함됐는지 확인하는 방법

1. Xcode 27에서 생산과 동일한 Scheme을 선택합니다.
2. Configuration을 Release로 고정합니다.
3. 새 Archive를 만들고 Organizer에서 보관 파일을 엽니다.
4. 보관 파일 안의 실제 .app를 찾아 최종 Info.plist를 확인합니다.
5. UILaunchScreen 또는 유효한 스토리보드 관련 설정이 있는지 확인합니다.
6. 시작 화면 리소스가 앱 대상에 실제로 포함됐는지 확인합니다.
7. 번들 식별자와 대상 이름을 소스 프로젝트의 값과 대조합니다.
8. 검증한 보관 파일을 TestFlight에 업로드하고 서버 결과를 기록합니다.

보관 파일을 확인할 때는 소스 plist의 화면 캡처만 남기지 마십시오. 탈식별한 빌드 설정, 산출물 경로, 최종 plist의 관련 항목, 업로드 로그를 함께 보관해야 합니다. Apple의 앱 업로드 안내와 빌드 상태 설명을 기준으로 서버 상태도 기록합니다.

주의: DerivedData 삭제나 Xcode 재설치는 기본 수정 방법이 아닙니다. 먼저 Release Archive의 최종 plist가 소스와 다른지 확인하십시오. 값이 다르면 캐시보다 대상 설정, 생성 스크립트, 보관 스크립트를 먼저 추적해야 합니다.

서버 검증이 통과해도 사용자 화면이 올바르다는 뜻은 아닙니다. Apple의 시작 화면 설정은 시스템이 앱을 실행하기 전에 사용할 구성을 정의합니다. 따라서 삭제하지 않은 기존 앱으로만 확인하면 캐시 때문에 잘못된 결론을 낼 수 있습니다.

1. 기기에서 기존 앱을 삭제합니다.
2. Xcode에서 다시 설치하고 첫 실행을 확인합니다.
3. 빈 화면, 이전 이미지 잔류, 이미지 잘림을 각각 기록합니다.
4. 세로와 가로 방향이 필요한 앱은 방향별 안전 영역을 확인합니다.
5. 시뮬레이터에서 빠르게 반복한 뒤 실제 기기에서도 확인합니다.

시작 화면이 빨리 보인다는 인상을 성능 수치로 표현하면 안 됩니다. 이 글에서는 별도 실측 자료가 없으므로 시작 속도에 관한 성능 결론을 제시하지 않습니다. 확인 대상은 표시 결과와 리소스 배치입니다.

ITMS-90870이 사라졌는지 확인하려면 수정한 소스가 아니라 새로 만든 보관 파일을 업로드해야 합니다. 같은 보관 파일을 재사용하면 수정 전 결과를 다시 제출할 수 있습니다.

이번 주 제출 전에는 다음 목록을 완료하십시오.

• [ ] iOS 27 SDK 이상으로 빌드하는 Scheme을 식별했습니다.
• [ ] 최소 배포 버전과 SDK 조건을 서로 혼동하지 않았습니다.
• [ ] 실제 제출 대상의 Info.plist에 유효한 시작 화면 선언이 있습니다.
• [ ] UILaunchScreen 값 또는 스토리보드 파일이 비어 있지 않습니다.
• [ ] 시작 화면 리소스가 해당 앱 대상에 포함되어 있습니다.
• [ ] Release Configuration과 Archive Scheme을 확인했습니다.
• [ ] 다른 대상과 확장 프로그램의 plist 생성 방식을 따로 점검했습니다.
• [ ] 빌드 스크립트가 보관 단계에서 plist를 덮어쓰지 않는지 확인했습니다.
• [ ] Archive 안 최종 .app의 plist와 리소스를 확인했습니다.
• [ ] 기존 앱을 삭제한 뒤 시뮬레이터와 실제 기기에서 첫 화면을 확인했습니다.
• [ ] 새 보관 파일을 TestFlight에 업로드했습니다.
• [ ] ITMS-90870 결과와 사용한 Xcode, Scheme, Configuration을 기록했습니다.
• [ ] 정식 생산 전환 전 회귀용 보관 파일과 되돌림 경로를 남겼습니다.

원격 맥이나 자동화 서버를 사용하는 팀은 같은 절차를 서버에서도 반복해야 합니다. 로컬에서 Xcode 27을 사용해 통과했더라도 서버의 Xcode 경로, Scheme, 인증서, 환경 변수, 생성 스크립트가 다르면 최종 plist가 달라질 수 있습니다. Xcode 시스템 요구 사항을 기준으로 생산 환경의 설치 가능 여부도 확인하십시오.

현재 생산 방식이 오래된 로컬 맥 한 대에 의존하면 두 가지 문제가 남습니다. 새 Xcode를 시험하는 동안 기존 서명 환경을 건드리기 쉽고, 다른 팀원이 같은 보관 절차를 재현하기 어렵습니다. 자동화 서버만 쓰는 경우에도 환경 차이, 인증서 접근 권한, 로그 보존, 실패한 Archive의 회수가 추가 부담이 됩니다.

기존 장비를 계속 유지할지 새 장비를 마련할지 비용을 따져야 한다면, 맥 미니 렌탈 가격과 운영 조건을 먼저 확인해 보십시오. 단순 구매가와 비교하기보다 Xcode 설치 가능 여부, 보관 파일 보존, 원격 접속 방식, 사용 기간을 함께 계산해야 합니다.

그래서 수정 직후에는 기존 생산 장비를 바로 교체하기보다, 독립된 macOS 환경에서 Xcode 27 Archive와 TestFlight 업로드를 한 번 더 실행하는 구성이 적합합니다. 현재 장비가 필요한 Xcode를 설치하지 못하거나, 단기간 호환성 검증만 필요하다면 MESHLAUNCH의 원격 맥 환경을 임시 검증 장비로 사용할 수 있습니다. 장기간 고정 부하나 물리적인 기기 연결이 필요한 경우에는 자체 장비가 더 적합합니다. 반대로 베타 검증, 보관 파일 재현, 업로드 확인처럼 기간이 정해진 작업이라면 맥 미니를 즉시 구매하지 않고 원격 맥을 먼저 쓰는 편이 운영 리스크를 줄일 수 있습니다.

핵심은 시작 화면 키를 추가하는 데서 끝나지 않습니다. iOS 27 SDK 빌드 조건을 확인하고, 대상별 선언을 고친 뒤, Release Archive의 최종 Info.plist, 첫 실행 화면, TestFlight 서버 결과를 같은 기록 안에서 연결해야 합니다.