이번 편의 목표: 거절 메일의 사유를 고치고, 같은 1.0.0 버전에 새 빌드만 올려 다시 제출합니다.

거절은 앱 레코드를 지우고 처음부터 만들라는 뜻이 아닙니다. Resolution Center의 문장이 수정 범위입니다. 예제로 자주 만나는 사유는 세 가지입니다.

첫째, 실행 직후 죽습니다. 심사 맥에서 샌드박스 때문에 집 폴더를 읽다가 죽는 경우가 있습니다. 개발 맥에서는 권한이 열려 있어 살아 있고, 스토어 서명 빌드에서만 죽습니다. 아카이브를 내 맥에 설치해 열기 패널 없이 실행해 봅니다. 죽으면 그 파일 접근을 컨테이너 안으로 옮깁니다.

둘째, 설명과 앱이 다릅니다. 설명에 클라우드 동기화를 적었는데 앱에 없으면 기능을 만들거나 문장을 지웁니다. 문장만 고치면 되는 경우에도 이미 제출된 버전은 심사가 끝난 뒤에 고칩니다. 심사 중인 메타데이터 수정이 잠겨 있으면 결과를 기다립니다.

셋째, 스크린샷이 규격이 아닙니다. 16:10이 아니거나 알파 채널이 있으면 그 이미지만 교체합니다. 2880×1800으로 다시 자릅니다.

코드를 고쳤으면 마케팅 버전은 1.0.0으로 유지하고 Build만 2로 올립니다.

XML
<key>CFBundleShortVersionString</key>
<string>1.0.0</string>
<key>CFBundleVersion</key>
<string>2</string>

05편과 같이 아카이브하고 업로드합니다. 처리가 끝나면 버전 페이지의 빌드를 1에서 2로 바꿉니다. Resolution Center의 답장에는 고친 내용을 사유 번호에 맞춰 짧게 적습니다.

예문입니다.

지침 2.1의 실행 종료를 수정했습니다. 집 폴더 접근을 제거했고, 빌드 2는 샌드박스 안에서 창을 연 뒤 3일 연체료 단추만 동작합니다. 네트워크 기능은 여전히 없습니다.

답장만 보내고 빌드를 바꾸지 않으면 애플은 거절된 바이너리를 다시 봅니다. 코드가 원인인 거절은 반드시 새 빌드를 연결합니다. 문장만 원인인 거절은 빌드를 유지한 채 메타데이터를 고치고 다시 제출할 수 있습니다. 메시지가 어느 쪽인지 문장의 대상이 바이너리인지 스크린샷인지로 나눕니다.

다시 제출하면 상태는 Waiting for Review로 돌아갑니다.

직접 해 보기

거절 문장에서 고쳐야 하는 파일 또는 입력 칸을 한 줄로 적으세요. 그 한 줄이 코드라면 빌드 번호를 올리고, 문장이라면 해당 칸만 고칩니다.

해설

두 종류를 한 번에 고칠 수도 있습니다. 코드를 건드렸다면 빌드 번호는 항상 올라갑니다. 이전 빌드 번호로 업로드하면 서버가 거절합니다.