스토어 심사가 실제로 보는 것

앱을 스토어에 올렸다가 반려됐다. 기능 문제일 것으로 보고 코드를 봤는데 회신 내용은 코드와 무관했다.

Open Table of contents

코드와 무관하던 반려 사유

권한 요청 이유가 설명되지 않았다는 것과 심사자가 기능을 확인할 방법이 없다는 것과 스크린샷이 실제 화면과 다르다는 것 셋이었다. 셋 다 앱이 무엇을 하느냐가 아니라 그것을 어떻게 설명하고 확인시키느냐의 문제였다.

기능을 잘 만드는 것과 심사를 통과하는 것이 다른 축이었다. 그 축을 준비 항목에 넣지 않은 것이 반려의 원인이었다.

무선 검색에 위치 권한이 필요한 것은 기술적 이유인데 사용자에게는 왜 위치를 요구하는지로 읽힌다. 원래 설명에는 위치 정보를 사용한다는 문장만 있었다.

필요한 이유와 수집하지 않는다는 사실을 함께 적으니 통과했다. 뒤의 것이 특히 중요했는데 사용자와 심사자가 모두 그것을 궁금해하기 때문이다.

이 앱은 실제 장치와 연결돼야 동작하는데 심사자에게는 장치가 없었다. 로그인도 필요한데 계정을 안 줬다.

만든 사람에게는 당연한 실행 조건이 확인하는 쪽에는 없다는 것이 이 반려의 핵심이었다. 심사용 계정을 제출 노트에 적고 장치 없이 화면을 볼 수 있는 시연 모드를 넣되 일반 계정으로는 진입할 수 없게 격리했다.

심사를 거치면서 배포 경로를 내부 테스트와 외부 테스트와 정식 배포로 나눴다. 개발 중에는 내부로 돌리고 고객 확인은 외부로 하니 매번 심사를 기다리지 않아도 됐다.

한 번 올린 빌드 번호는 재사용할 수 없고 버전이 내려가서도 안 된다는 제약이 있었다. 사람이 관리하면 반드시 실수하므로 기능 단위 버전은 사람이 정하고 빌드 번호는 자동으로 올라가게 했다.

가장 실질적인 것은 심사에 며칠이 걸리고 반려되면 다시 며칠이 걸린다는 사실이었다. 공개 날짜만 잡고 그 앞을 안 두면 일정이 그대로 밀린다.

그래서 기능 완료와 제출과 심사 결과와 공개를 날짜로 나눠 적고 반려를 전제한 여유를 넣었다. 스크린샷 촬영도 빌드가 확정된 뒤에 하도록 배포 절차의 마지막에 넣었다.