iPhone 18 Pro App Store 스크린샷은 새 규격이 생겼다는 이유만으로 전부 다시 만들 필요가 없습니다. 기존 고해상도 자료가 App Store Connect의 제출 조건을 통과하고 확대된 화면에서도 배치와 문구가 자연스럽다면 그대로 사용하면 됩니다. 새 화면에서 레이아웃, 줄바꿈, 기기 전용 기능 또는 마케팅 구성이 달라질 때만 해당 화면을 다시 촬영하고 원본은 되돌림용으로 보관합니다.

이 글은 이미 출시한 iPhone 앱의 자료를 관리하는 독립 개발자, 여러 언어의 출시 화면을 운영하는 소규모 팀, 원격 맥에서 반복 가능한 촬영 과정을 만들려는 출시 담당자를 위한 안내서입니다.

제출 자격 확인

2026년 9월 14일 기준으로 Apple은 App Store Connect에 iPhone 18 Pro와 iPhone 18 Pro Max의 스크린샷 표시 규격을 추가했다고 안내했습니다. 그러나 새 업로드 대상이 생겼다는 사실은 기존 스크린샷 전체가 즉시 거부된다는 뜻이 아닙니다. App Store Connect 출시 기록에서 현재 적용된 변경 내용을 먼저 확인해야 합니다.

실제 제출에 필요한 자료는 앱의 플랫폼, 지원 버전, 선택한 언어와 표시 대상에 따라 달라질 수 있습니다. 따라서 다음 순서로 확인합니다.

  • [ ] 앱의 편집 화면에서 필요한 표시 대상이 누락되었는지 확인합니다.
  • [ ] 업로드 뒤 표시되는 처리 상태와 오류 메시지를 기록합니다.
  • [ ] 단순한 미리 보기 문제인지, 필수 자료 누락인지 구분합니다.
  • [ ] 테스트 앱 또는 편집 가능한 출시 자료에서 같은 파일을 다시 처리합니다.
  • [ ] 승인된 자료와 오류가 난 자료를 계정 정보가 드러나지 않는 이름으로 보관합니다.

Apple의 스크린샷 규격 안내는 표시 크기와 파일 조건을 판단하는 기준입니다. 커뮤니티의 경험이나 기기 판매 전망은 제출 자격의 근거로 사용하지 않는 편이 안전합니다.

iPhone 18 Pro App Store 스크린샷 판정

새 표시 크기에 기존 자료를 적용할 수 있는지는 파일이 업로드되는지보다 처리된 결과가 정확한지로 판단해야 합니다. 자료 업로드 안내에서 처리 결과를 확인하고, 원본과 변환된 미리 보기를 나누어 비교합니다.

판정 확인 조건 권장 조치
직접 유지 파일 조건을 통과하고 확대 뒤에도 화면, 문구, 안전 영역이 자연스럽습니다. 기존 자료를 유지하고 핵심 화면만 표본 확인합니다.
확대 후 재검토 업로드는 되지만 글자, 버튼, 여백 또는 기기 장식이 어색합니다. 확대된 결과를 기준으로 해당 언어와 화면만 보완합니다.
반드시 재촬영 기기 전용 기능, 큰 배치 변화, 잘린 조작 요소 또는 부정확한 마케팅 구성이 있습니다. iPhone 18 Pro 환경에서 해당 화면을 다시 만들고 기존 원본을 보관합니다.

파일 방향, 투명 영역, 화면 비율, 실제 표시 크기는 함께 확인해야 합니다. 원본 이미지의 픽셀이 충분해도 투명한 여백이 지나치게 크거나 화면 안의 글자가 작으면 결과물의 설득력이 떨어질 수 있습니다. App Store Connect API의 스크린샷 자료도 자동 업로드 상태를 확인할 때 참고할 수 있습니다.

화면 진실성 점검

스크린샷은 이미지 파일이 아니라 앱의 현재 동작을 보여주는 출시 자료입니다. 다음 요소가 새 표시 크기에서 실제 앱과 맞는지 확인합니다.

  • 상단 탐색 영역과 하단 조작 영역이 안전 영역 안에 남아 있는지 확인합니다.
  • 팝업, 키보드, 알림, 동적 아일랜드 주변 화면이 잘리거나 겹치지 않는지 봅니다.
  • 기기 테두리, 홍보 문구, 배경을 합성한 자료는 원본 화면과 별도로 검수합니다.
  • 기기 전용 기능을 강조한 화면은 해당 환경에서 다시 생성합니다.
  • App Preview 동영상과 정적 스크린샷을 같은 자료로 취급하지 않습니다.

시뮬레이터에서 화면을 만들 때는 Xcode 기기 실행 안내의 실행 조건을 확인합니다. 시뮬레이터에서 보인 화면과 App Store Connect가 처리한 결과는 다를 수 있으므로 둘 다 저장해야 합니다.

주의: 계정 이름, 앱 이름, 번들 식별자, 테스트 사용자, 기기 식별자와 파일 경로는 캡처 전부터 가린 값으로 바꾸는 것이 좋습니다. 출시 자료에 실제 개인정보가 들어간 뒤에는 이미지 수정만으로 모든 노출 경로를 되돌리기 어렵습니다.

다국어 보완 범위

여러 언어를 모두 같은 날 다시 생성하는 방식은 효율적이지 않습니다. 먼저 다운로드와 매출에 중요한 시장, 첫 화면의 전환 기여도가 큰 페이지, 번역 길이가 크게 변하는 언어를 확인합니다.

독일어, 프랑스어, 러시아어처럼 문장이 길어질 수 있는 언어는 다음 항목을 우선 확인합니다.

  • 버튼 문구가 한 줄 안에 남아 있는지 확인합니다.
  • 제목과 설명의 줄바꿈이 핵심 이미지나 기기 장식과 겹치지 않는지 봅니다.
  • 번역된 기능 설명이 현재 앱 버전의 실제 동작과 일치하는지 확인합니다.
  • 한 언어에서 수정한 마케팅 배경이나 장식을 다른 언어에 잘못 복사하지 않았는지 봅니다.

핵심 시장의 첫 화면에서 문제가 발견되면 해당 언어의 주요 페이지만 다시 촬영합니다. 여러 언어에서 같은 구조 문제가 반복되거나 전체 마케팅 디자인을 바꾼 경우에만 전체 업데이트를 검토합니다. Apple의 플랫폼 버전 정보도 각 출시 대상의 지원 상태를 확인할 때 함께 살펴보는 편이 좋습니다.

재현 가능한 촬영 기록

Xcode 27과 iOS Simulator를 사용해 한 번 정상적으로 만든 자료라도 다음 촬영에서 같은 결과가 나온다는 보장은 없습니다. 다음 정보를 촬영 기록에 남깁니다.

  • Xcode 버전과 시뮬레이터 런타임
  • 기기 종류와 화면 방향
  • 언어, 지역, 시간대
  • 테스트 계정과 고정된 앱 데이터
  • 화면 생성 방식과 파일 저장 위치
  • 원본, 합성본, App Store Connect 처리본의 구분

수동 촬영은 화면 구성을 빠르게 확인할 때 적합합니다. UI 테스트 기반 촬영은 같은 상태의 화면을 반복해서 만들 때 유리합니다. 다만 이 글의 목적은 자동화 도구 설치 과정을 설명하는 것이 아니므로, 어떤 방식을 선택하든 결과 파일과 실행 조건을 함께 보관하는 데 초점을 둡니다.

원격 맥을 사용할 때는 그래픽 세션이 실제로 유지되는지, 연결이 끊긴 뒤 다시 화면을 열 수 있는지, 생성한 파일을 안전하게 내려받을 수 있는지 확인해야 합니다. 테스트 계정과 민감한 데이터도 작업 종료 뒤 삭제합니다. 시뮬레이터 상호작용 안내를 참고하면 입력 상태와 화면 재현 조건을 정리하는 데 도움이 됩니다.

최종 결정 조건

다음 조건에 따라 유지, 부분 촬영, 전체 업데이트를 나눌 수 있습니다.

  • 파일 조건을 통과하고 확대 결과가 자연스러우면 기존 자료를 유지합니다. 핵심 화면은 표본으로 다시 확인합니다.
  • 특정 언어에서 줄바꿈이나 버튼 잘림이 발견되면 해당 언어와 화면만 다시 촬영합니다.
  • 기기 전용 기능이나 안전 영역 변화가 화면의 의미를 바꾸면 iPhone 18 Pro 환경에서 해당 화면을 다시 만듭니다.
  • 마케팅 배경과 장식이 새 화면 비율에서 어색하면 원본 앱 화면과 합성본을 분리해 부분적으로 수정합니다.
  • 전체 시각 디자인을 변경했거나 여러 화면의 구조가 달라졌다면 전체 업데이트를 검토합니다.
  • App Store Connect 처리 상태, 페이지 미리 보기, 재생성 기록 중 하나라도 남지 않으면 출시 자료를 최종 승인하지 않습니다.

따라서 가장 안전한 기본값은 “먼저 유지하고 표본 검수, 문제가 확인된 화면만 보완”입니다. 새 규격만 보고 모든 자료를 폐기하는 것은 필수 조치가 아닙니다.

자주 확인하는 항목

FAQ에서 설명한 것처럼 자동 확대는 제출 작업을 줄일 수 있지만, 레이아웃 검수를 대신하지는 않습니다. 특히 여러 언어와 장식이 들어간 자료는 원본 화면, 합성 이미지, 처리 결과를 각각 비교해야 합니다.

현재 방식이 개인 맥 한 대에 의존하면 촬영 시점마다 런타임과 테스트 데이터가 달라질 수 있고, 장시간 작업 중 화면 세션이 끊기거나 파일이 로컬 저장 공간에만 남는 문제가 생길 수 있습니다. 반대로 원격 맥은 고정된 개발 환경과 그래픽 세션을 운영하는 데 적합하지만, 물리 기기 센서나 직접 연결한 주변 장치가 필요한 검증까지 대신하지는 못합니다.

여러 언어의 자료를 다시 만들어야 한다면 먼저 RUVCLOUD의 한국어 맥 이용 안내에서 원격 작업 방식을 확인하고, 반복적인 촬영 기간과 필요한 환경을 요금 안내와 비교하는 방법이 현실적입니다.

현재의 로컬 맥만 사용하는 방식은 저장 공간 부족, 장시간 촬영 중 환경 변경, 담당자가 바뀔 때의 재현 실패라는 단점이 있습니다. 공유된 일반 서버는 macOS 전용 도구와 그래픽 세션을 안정적으로 유지하기 어렵고, 단기간에 여러 언어 자료를 만들어야 할 때 환경을 다시 구성하는 비용도 생깁니다. 이런 작업이 특정 출시 기간에 집중된다면, RUVCLOUD에서 원격 맥을 임대해 Xcode와 iOS Simulator 환경을 고정하고, 촬영 뒤 파일과 테스트 데이터를 정리하는 편이 더 적합할 수 있습니다. 다만 장기간 매일 무거운 빌드를 실행하거나 실제 물리 센서와 연결해야 한다면 자체 맥을 함께 검토해야 합니다.

최종 판단의 기준은 새 기기 이름이 아니라 세 가지 증거입니다. App Store Connect 처리가 성공했는지, 페이지 미리 보기가 정확한지, 같은 조건에서 자료를 다시 만들 수 있는지 확인한 뒤 출시를 진행합니다.