erberkk/리뷰-준비

리뷰 준비

목적

한 번 제출하고 통과하세요. 대부분의 거절은 앱의 아이디어 때문이 아니라, 리뷰어가 로그인할 수 없거나, 구매할 수 없거나, 플레이스홀더를 보았거나, 메타데이터와 앱 간의 불일치를 발견했기 때문입니다.

전제 조건

• 제출할 정확한 빌드가 TestFlight / Play 테스트 트랙에 있습니다.
• subscriptions-and-payments 체크포인트 통과 (실제 구매로 두 플랫폼에서 프리미엄이 잠금 해제됨).
• privacy-and-declarations 완료; listing-and-aso 검증기 깔끔함; 스크린샷 업로드 완료.

제로 지식 리뷰어처럼 생각하기

리뷰어가 깨끗한 빌드를 귀하가 테스트하지 않은 기기(iPhone 전용 앱이 iPad 호환성 모드에서 리뷰될 수 있음)에 설치하고, 새로운 스토어 계정을 사용하며, 시간이 제한되어 있다고 가정하세요. 리뷰어는 귀하의 노트를 읽고, 로그인을 시도하고, 구매를 찾고, 스크린샷과 앱을 비교합니다. 단일 거절은 여러 계층(계정 상태, 백엔드 동작 및 메타데이터)을 결합할 수 있습니다.

절차

1. 데모 계정

• 자격 증명은 App Store Connect › App Review Information("Sign-in required")과 Play › App content › App access에 입력합니다. 리포지토리에는 절대 입력하지 마세요.
• 계정은 이메일 + 비밀번호로 로그인합니다. 일반 로그인이 이메일 일회용 코드나 매직 링크인 경우 리뷰어가 받을 수 없습니다. 리뷰 주소에 대해서만 비밀번호 경로를 추가하거나(서버 측 허용 목록), 해당 주소에서만 작동하는 고정 테스트 코드를 사용하세요.
• 데이터로 채워짐: 프로필이 완전하고, 며칠의 기록이 있으며, 모든 주요 화면이 채워져 있습니다. 빈 계정은 기능을 숨기고 "기능 X를 찾을 수 없습니다"라는 답변을 유발합니다.
• 프리미엄이 잠금 해제됨: 서버 측 수동 권한 부여를 통해(리뷰 중에 만료되지 않음) 리뷰어가 구매하지 않고 유료 기능을 볼 수 있습니다.
• 별도로, 새 사용자가 페이월에 도달하고 리뷰어의 샌드박스 계정으로 구매할 수 있는지 확인하세요(리뷰어도 구매를 테스트합니다).
• 리뷰가 진행 중인 동안 이 계정을 변경, 삭제 또는 재시드하지 마세요.

2. 구매 (2.1(b) 및 3.1.x)

• 첫 버전 구독은 App Store Connect의 "In-App Purchases and Subscriptions" 섹션에서 버전에 연결되며 리뷰 스크린샷과 노트가 있습니다. 최신 App Store Connect UI에서는 버전 페이지에 해당 섹션이 없을 수 있습니다. 구독 그룹과 각 구독을 열고 Add for Review → Draft Submission을 사용하세요. 버전 자체는 해당 페이지에서 추가됩니다. 초안에는 버전, 그룹 및 모든 구독이 "Submit for Review"를 누르기 전에 나열되어야 합니다.
• 각 구독에는 표시 이름 + 설명 지역화와 리뷰 스크린샷이 하나 이상 필요합니다. 이것들이 없으면 "Add for Review"가 실패합니다("You must add at least one subscription localization / a Review Information screenshot").
• 리뷰 스크린샷은 실제 가격과 올바른 스토어 문구가 포함된 실제 페이월을 보여주어야 합니다. 위젯/UI 테스트에서 렌더링하는 경우 iOS 플랫폼을 강제로 설정하고(그렇지 않으면 "Google Play"라고 표시됨) 현실적인 스토어 가격을 제공하세요. "prices unavailable" 상태는 허용되지 않습니다.
• App Store 버전 문자열은 빌드의 마케팅 버전(CFBundleShortVersionString)과 동일해야 합니다. 1.0이라는 버전은 1.0.0으로 업로드된 빌드를 제공하지 않습니다. Build 섹션에 "Upload your builds"만 표시되고 Add Build 버튼이 없습니다. 버전 이름을 일치하도록 변경하세요.
• 새 샌드박스 Apple 계정(앱 계정과 연결되지 않은)으로 TestFlight에서: 제품 로드, 구매 작동, 복원 작동.
• 페이월 오류 상태는 재시도를 표시하고 비활성화된 "Coming soon"을 표시하지 않습니다.
• 특정 지역에만 해당하는 등 앱 내에서 IAP에 도달할 수 없는 경우 리뷰 노트에 그 이유를 설명하세요.
• 구매 복원, 이용약관 및 개인정보 보호 링크, 구독 관리 링크가 있어야 합니다.

3. 기기 및 빌드

• 네트워크 없음, 느린 네트워크 및 비행기 모드 전환으로 콜드 스타트: 충돌 없음, 무한 스피너 없음.
• iPad: iPhone 전용 앱도 iPad에서 호환성 모드로 실행되며 거기서 리뷰될 수 있습니다. iPad 시뮬레이터에서 전체 흐름을 실행하세요: 로그인(Apple로 로그인 포함), 페이월 스크롤, 구매 시트, 양식 위의 키보드, 권한 프롬프트, 회전. HealthKit 또는 다른 API를 사용할 수 없는 경우 충돌 대신 정중한 메시지를 표시하세요.
• 지원되는 가장 작은 전화기와 가장 큰 텍스트 크기: 페이월 또는 동의 화면에서 잘린 버튼이 없음.
• 릴리스 빌드, 디버그 아님: 디버그 배너 없음, 테스트 메뉴 없음, 프로덕션 구성에서 분석/충돌 보고 활성화.
• 제출하는 정확한 빌드로 물리적 기기에서 전체 계정 수명 주기를 실행하세요: 설치, 가입, 주요 기능, 샌드박스 구매, 계정 삭제 및 삭제 후 앱이 표시하는 내용.

4. 콘텐츠 및 메타데이터

• 앱의 문자열 및 목록에서 다음을 검색하세요: TODO, lorem, coming soon, beta, test, [PRICE], 플레이스홀더 이미지. 어떤 것도 렌더링되지 않아야 합니다.
• iOS 빌드 및 메타데이터에는 Android / Google Play 문구가 없어야 합니다. Play에는 Apple 전용 문구가 없어야 합니다(2.3.10). "Cancel in App Store or Google Play"와 같은 앱 내 문자열은 런타임에 플랫폼의 텍스트를 선택하세요.
• 모든 스크린샷이 현재 UI와 일치해야 합니다. 설명의 모든 숫자가 앱과 일치해야 합니다.
• 개인정보 처리방침, 이용약관, 지원 및 계정 삭제 URL이 로그인 없이 로드되고, 앱을 언급하며, 개인정보 양식과 일치해야 합니다.
• 연령 등급이 이용약관과 일치해야 합니다.

5. 백엔드

• 백엔드가 가동 중이며 리뷰 중에 한도에 도달하지 않을 요금제에 있어야 합니다(일시 중지 또는 제한하는 무료 티어 = 거절).
• 리뷰 중에 주요 변경 사항을 배포하지 마세요. 리뷰 중인 빌드에 대해 이전 버전과 호환되는 API를 유지하세요.
• 알림이 설정되어 있어야 합니다(post-launch-ops) 리뷰 중에 중단을 인지할 수 있도록.

6. 리뷰 노트

templates/review-notes.md를 작성하세요. 사실적으로 유지하세요: 기능의 위치, 로그인 방법, 구매 테스트 방법, AI 및 건강 데이터 처리 방법, 계정 삭제 위치.

Apple은 리뷰 대신 **가이드라인 2.1 "Information Needed"**로 응답할 수 있습니다. 한 관찰된 사례에서는 아래 6가지 항목을 요청했습니다. 첫 번째 제출에서 미리 답변하면 왕복을 피할 수 있습니다:

1. 최신 OS를 실행하는 물리적 기기에서 앱 실행부터 시작하여 일반적인 흐름(등록, 로그인, 계정 삭제, 사용자 생성 콘텐츠의 신고/차단, 유료 콘텐츠 액세스)을 보여주는 화면 녹화. 제출된 빌드로 녹화하고, 파일을 제출 메시지의 답변에 첨부하거나(또는 링크) Notes에서 언급하세요. 삭제 부분에는 데모 리뷰 계정을 사용하지 마세요. 녹화에서 새 계정을 만드세요.
2. 앱의 목적과 대상: 해결하는 문제와 그 가치.
3. 주요 기능에 대한 설정 및 액세스 지침(데모 자격 증명 및 메뉴 경로 포함).
4. 핵심 기능 뒤에 있는 모든 외부 서비스: 인증/데이터베이스, 결제(StoreKit + 모든 래퍼), AI 제공자, 데이터 소스(예: 지도 API), 이메일, 건강 프레임워크.
5. 지역별 차이점 또는 모든 곳에서 기능이 동일하다는 진술.
6. 규제 영역 또는 타사 보호 콘텐츠의 경우: 해당 사항이 없다는 문서 또는 진술(예: "일반 웰빙, 의료 기기 아님").

7. Go/No-Go 보고서

templates/go-no-go-report.md를 각 항목에 대한 증거(스크린샷, 빌드 번호, 명령 출력)와 함께 작성하세요. 차단 항목에 No가 있으면 제출하지 마세요.

8. 제출 (승인)

계정 소유자에게 보고서를 첨부하여 명시적 승인을 요청하세요. iOS에서는 수동 릴리스를 선택하여 승인이 즉시 게시되지 않도록 하세요. Play에서는 프로덕션 액세스(새 개인 계정)에 완료된 14일 비공개 테스트와 프로덕션 액세스 신청이 먼저 필요합니다.

거절 후

references/rejection-playbook.md를 참조하세요: 정확한 가이드라인을 읽고, 재현하고, 근본 원인(종종 둘 이상의 계층)을 수정하고, Resolution Center에서 구체적으로 답변하고, 재제출하세요. 리뷰어가 증명할 수 있는 사실을 잘못 읽은 경우에만 항소하세요.

인간 승인이 필요한 결정 사항

제출, 릴리스 방법 선택, 거절에 대한 답변(어조 및 약속), 항소 제기, 리뷰 계정에 프리미엄 부여.

검증

Go/No-Go 보고서가 증거와 함께 완전하고, 기능을 구축하지 않은 사람이 깨끗한 기기에서 리뷰 노트를 따라 성공했습니다.

일반적인 함정

• 데모 계정이 리뷰어가 읽을 수 없는 이메일 코드에 의존함.
• 데모 계정이 비어 있거나, 정지되었거나, 정리 작업에 의해 삭제됨.
• "Missing Metadata"(리뷰 스크린샷 없음) 상태의 제품으로 인해 리뷰에서 로드되지 않음.
• 리뷰에서 버전 제거("Developer Rejected") 시 구독도 초안에서 삭제됨. 재제출 전에 그룹과 각 구독을 다시 추가하지 않으면 버전만 단독으로 제출됨.
• 버전이 "Waiting for Review" 상태인 동안 제품 페이지 에셋이 잠김(예: 최신 Header 에셋). 제출 전에 모든 것을 추가하세요. 그렇지 않으면 버전을 리뷰에서 제거하고, 편집하고, 재제출해야 함(대기열 순서가 손실됨).
• Apple의 "Add for Review" 확인 통과가 선택적 에셋이 설정되었음을 의미하지는 않음: 빈 Header 에셋이 허용되므로 제출 전에 결정하세요.
• 리뷰어의 새 Apple 계정이 복원/전송 규칙과 충돌하여 구매가 "실패"함.
• 비활성 후 일시 중지되거나 리뷰어를 제한하는 요금제의 백엔드.
• 빌드 어딘가에 "Coming soon"이 있음.
• 다른 스토어를 언급하는 앱 내 텍스트.
• 데모 로그인만 설명하는 리뷰 노트(녹화, 목적, 서비스 또는 지역 없음).