빌드는 심사를 통과했고 코드도 멀쩡한데 — 리젝 메일의 원인이 스크린샷입니다. 릴리스에서 며칠을 날리는 가장 짜증나는 방식 중 하나죠. 스크린샷 리젝은 거의 항상 피할 수 있는데, 이유가 명확히 설명되는 일은 거의 없기 때문입니다.
스크린샷은 서로 다른 두 관문에서 실패하고, 해결법은 어디에 걸렸느냐에 따라 다릅니다:
- App Store Connect가 업로드를 거부 — 심사가 시작되기도 전의 기술적 검증 실패.
- App Review가 제출을 리젝 — 사람 심사자가 메타데이터를 문제 삼으며, 보통 2.3.3 같은 가이드라인 번호를 인용합니다.
이 가이드는 두 관문 모두를 리젝 사유별로, 가이드라인 참조와 함께 "In Review"로 가장 빨리 돌아가는 길을 다룹니다.
관문 1: App Store Connect가 파일을 받지 않을 때 #
이건 심사 리젝이 아닙니다 — 업로드가 그냥 실패하거나 슬롯이 빨간색으로 남습니다. 거의 모든 경우가 세 가지 원인입니다:
잘못된 픽셀 크기 #
모든 기기 슬롯은 정확한 크기만 받습니다. 1320 × 2868을 기대하는 슬롯에 1290 × 2796 이미지를 넣으면 조용히 실패하거나 모호한 오류가 납니다. 제출하는 날 밤 가장 흔한 차단 요인입니다 — 파일을 스크린샷 크기 완벽 레퍼런스와 대조하거나, 무료 스크린샷 검사기에 끌어다 놓으면 각 이미지가 어느 슬롯에 맞는지(또는 안 맞는지) 즉시 알려줍니다.
잘못된 형식이나 색상 프로파일 #
스크린샷은 PNG 또는 고품질 JPEG, RGB여야 합니다(Display P3와 sRGB 모두 가능). JPEG에 알파 투명도 불가, 디자인 도구의 CMYK 내보내기도 불가입니다.
잘못된 개수 #
기기 크기마다 언어별 1–10장을 받습니다. 필수 슬롯이 0장이면 제출 자체가 막힙니다 — watchOS나 visionOS 지원을 추가하고 나서 그 플랫폼들은 전용 세트가 필요하다는 걸 발견하는 고전적인 서프라이즈입니다.
해결: 요구되는 정확한 크기로 다시 생성하세요. 디자인 도구에서 손으로 내보내고 있다면, 하나의 디자인에서 모든 슬롯의 정확한 치수를 내보내는 스크린샷 생성기로 이 관문 전체가 사라집니다.
관문 2: App Review 리젝, 가이드라인별 #
가이드라인 2.3.3 — 스크린샷이 사용 중인 앱을 보여주지 않음 #
가장 큰 사유입니다. Apple의 규칙: 스크린샷은 사용 중인 앱을 보여줘야 합니다 — 타이틀 아트, 로그인 페이지, 스플래시 화면만으로는 안 됩니다.
전형적인 트리거:
- 로고, 태그라인, 마케팅 아트워크 위주에 UI는 거의 안 보이는 세트
- 로그인/온보딩 화면이 메인인 스크린샷
- 출시된 앱과 전혀 닮지 않은 기능 컨셉 목업
- 다른 플랫폼 UI(웹 앱, Android 버전)의 스크린샷
해결: 실제 화면 중심으로 세트를 다시 만드세요. 좋은 소식: 심사를 통과하는 레이아웃 — 디바이스 프레임 속 실제 UI와 짧은 캡션 — 이 전환도 가장 잘 되는 레이아웃입니다. 캡션 오버레이와 디바이스 프레임은 명시적으로 허용됩니다. 걸리는 건 조작된 UI입니다.
가이드라인 2.3.1 — 존재하지 않는 기능을 보여줌 #
심사자가 제출된 빌드에서 찾을 수 없는 기능을 스크린샷이 보여주면 리젝을 각오하세요(반복되면 더 나쁜 결과도). 순진하게 벌어지는 경우가 많습니다: 잘려 나간 기능이 들어 있던 베타 빌드로 만든 마케팅 스크린샷.
해결: 실제로 제출하는 빌드와 스크린샷 하나하나를 대조하세요. 현재 버전이 못 하는 것을 약속하는 캡션은 수정을.
가이드라인 2.3.8 — 메타데이터가 전체 이용가에 부적합 #
스크린샷과 미리보기는 앱의 연령 등급과 무관하게 4+ 시청자에게 적합해야 합니다. 둘러보는 누구에게나 보이기 때문입니다. 17+ 앱 안에서는 괜찮은 폭력·성인 테마·욕설도 제품 페이지에서는 안 됩니다.
해결: 더 무난한 화면을 고르거나 문제 부분을 자르거나 흐리게 처리하세요. 성인 테마 게임은 보통 노골적인 게임플레이 순간보다 분위기 샷으로 통과합니다.
가이드라인 2.3.10 — 다른 플랫폼 언급 #
Android 기기 프레임, Google Play 배지, "Android에서도 만나보세요!" 캡션이 있는 스크린샷은 리젝됩니다. 두 스토어에 마케팅 이미지 한 세트를 돌려쓰는 팀이 자주 물립니다.
해결: 스토어별 에셋을 분리해서 관리하세요. 두 스토어를 모두 운영한다면 App Store와 Google Play 세트를 나란히 관리하는 도구가 섞일 일을 없애줍니다.
가이드라인 5.2 / 2.3.7 — 타인의 지적 재산 #
제3자 로고, 유명인 사진, 경쟁 앱 이름, 상표 등록된 캐릭터, 다른 개발자의 제품 샷이 스크린샷에 있으면 리젝은 물론 분쟁까지 부를 수 있습니다.
해결: 권리가 있는 콘텐츠만 보여주세요. UI에 보이는 실제 제3자 콘텐츠(앨범 아트, 동영상, 브랜드 피드)는 캡처 전에 라이선스된 것이나 일반적인 대체물로 바꾸세요.
플레이스홀더와 성의 없는 콘텐츠 #
"Lorem ipsum", "테스트 테스트", 데이터 없는 빈 화면, 눈에 띄게 깨진 레이아웃은 미완성 앱으로 읽힙니다. 심사자는 제출물 전체의 완성도를 스크린샷에서도 판단합니다.
해결: 현실적인 데모 데이터로 캡처하세요 — 채워진 목록, 그럴듯한 이름, 믿을 만한 숫자. (현실적이되 실제는 아니어야 합니다: 실제 사용자 데이터를 스크린샷에 절대 담지 마세요.)
낡아 버릴 주장: 가격, 프로모션, 순위 #
"이번 주 50% 할인", "생산성 1위 앱", 캡션에 박아 넣은 가격은 상황이 바뀌는 순간 부정확해집니다 — 심사자도 그걸 압니다. 기간 한정 문구는 미리보기에서 명시적으로 비권장이며 스크린샷에서도 위험합니다.
해결: 캡션은 앱이 하는 일에 대해서만 쓰세요. 프로모션은 (심사 없이 언제든 수정 가능한) 프로모션 텍스트에.
승인으로 빨리 돌아가기 #
스크린샷 리젝에 새 빌드는 필요 없습니다:
- Resolution Center 메시지를 꼼꼼히 읽으세요 — 가이드라인을 명시하고 보통 문제된 스크린샷을 첨부합니다.
- 같은 버전에서 App Store Connect의 문제 이미지를 교체하세요. 리젝된 버전의 미디어·메타데이터 수정에는 새 바이너리가 필요 없습니다.
- Resolution Center에 무엇을 바꿨는지 답장하고 재제출하세요. 메타데이터만의 재심사는 보통 빠릅니다.
- 리젝이 잘못됐다고 생각하면 이의 제기도 가능하지만, 스크린샷은 다투는 것보다 에셋을 바꾸는 쪽이 거의 항상 빠릅니다.
의외로 모르는 프로세스 참고 사항: 리젝 상황이 아니면 스크린샷은 새 앱 버전을 제출해야만 바꿀 수 있습니다. 심사자들이 단속을 강화한 가이드라인을 세트가 위반하고 있으면, 사소한 버그 수정 릴리스까지 막힐 수 있습니다 — 세트를 한 번에 제대로 만들어야 할 이유가 하나 더 늘었습니다.
제출 전 체크리스트 #
새 스크린샷이 포함된 제출 전에 매번 확인하세요:
- 모든 슬롯의 정확한 픽셀 크기 — 여기서 검증
- 모든 스크린샷이 실제 현행 앱 UI를 표시 (2.3.3)
- 빌드가 못 하는 것을 보여주지 않음 (2.3.1)
- 4+에 적합한 콘텐츠 (2.3.8)
- Android/타 플랫폼 프레임·배지·언급 없음 (2.3.10)
- 권리 없는 제3자 상표·로고·인물 없음 (5.2)
- 현실적인 데모 데이터, 플레이스홀더 없음
- 이미지에 박힌 가격·할인·순위 주장 없음
- 필요한 모든 기기 크기 커버, Watch/Vision Pro에 출시한다면 포함
- 미리보기 동영상은 별도의 동영상 사양 확인
공식 원문은 Apple의 App Review 가이드라인 섹션 2.3과 스크린샷 사양에 있습니다.
이런 리젝을 아예 불가능하게 만들기 #
이 목록의 절반 — 크기, 커버리지, 언어 간 일관성 — 은 기계적인 문제이고, 기계적인 문제야말로 도구의 몫입니다. Screenshot Studio는 실제 UI를 최신 디바이스 프레임에 담아 캡처하고(설계상 2.3.3 친화적), 필요한 모든 크기를 정확히 내보내고(크기 리젝 없음), 현지화된 세트를 동기화하고, 모든 파일이 올바른 슬롯에 들어간 채 App Store Connect에 업로드합니다.
판단이 필요한 부분 — 무엇을 보여주고 무엇을 주장할지 — 은 여러분 몫입니다. 파일 문제에서 오는 리젝은 없앨 수 있습니다.
Screenshot Studio를 무료로 다운로드하고, 다음 업데이트는 숨죽이지 않고 제출하세요.