올해 초 Ionic 으로 패키징한 장비 관리 앱을 App Store 에 올렸다가 반려됐던 일을 다음 앱 준비 앞에서 다시 정리했다. 그때는 기능 문제일 것으로 보고 코드를 봤는데 회신 내용은 코드와 무관했다.
Table of contents
Open Table of contents
원인 — 코드와 무관하던 반려 사유
권한 요청 이유가 설명되지 않았다는 것과 심사자가 기능을 확인할 방법이 없다는 것과 스크린샷이 실제 화면과 다르다는 것 셋이었다. 셋 다 앱이 무엇을 하느냐가 아니라 그것을 어떻게 설명하고 확인시키느냐의 문제였다.
기능을 잘 만드는 것과 심사를 통과하는 것이 다른 축이었다. 그 축을 준비 항목에 넣지 않은 것이 반려의 원인이었다.
조치 — 권한 설명에 넣을 두 가지
주변 장비 검색에 위치 권한이 필요한 것은 기술적 이유인데 사용자에게는 왜 위치를 요구하는지로 읽힌다. 원래 NSLocationWhenInUseUsageDescription 에는 위치 정보를 사용한다는 문장만 있었다.
Info.plist 에 필요한 이유와 수집하지 않는다는 사실을 함께 적으니 통과했다. 뒤의 것이 특히 중요했는데 사용자와 심사자가 모두 그것을 궁금해하기 때문이다.
판단 기준 — 심사자가 확인할 수 없으면 반려된다
이 앱은 실제 장비와 연결돼야 동작하는데 심사자에게는 장비가 없었다. 로그인도 필요한데 계정을 안 줬다. App Store 심사 지침 공식 문서의 2.1 항목은 로그인이 있으면 데모 계정을 넣고 확인에 필요한 하드웨어나 자료도 함께 제공하라고 적고 있다.
만든 사람에게는 당연한 실행 조건이 확인하는 쪽에는 없다는 것이 이 반려의 핵심이었다. 두 가지 방법이 있었다. 심사자에게 장비를 보내는 것과, 장비 없이 화면을 볼 수 있는 시연 모드를 넣는 것이다. 뒤쪽을 골랐다. 이유는 장비 발송은 갱신판마다 반복할 수 없어서다. 대신 시연 모드가 일반 계정으로는 진입할 수 없게 격리하는 코드가 늘어나는 것을 감수했고 심사용 계정은 제출 노트에 적었다.
배포 경로와 빌드 번호
심사를 거치면서 배포 경로를 TestFlight 내부 테스트와 외부 테스트와 정식 배포로 나눴다. 개발 중에는 내부로 돌리고 고객 확인은 외부로 하니 매번 심사를 기다리지 않아도 됐다.
한 번 올린 CFBundleVersion 은 재사용할 수 없고 버전이 내려가서도 안 된다는 제약이 있었다. 사람이 관리하면 반드시 실수하므로 기능 단위 CFBundleShortVersionString 은 사람이 정하고 빌드 번호는 Jenkins 빌드 번호로 자동으로 올라가게 했다.
반려를 전제한 일정
가장 실질적인 것은 심사에 며칠이 걸리고 반려되면 다시 며칠이 걸린다는 사실이었다. 공개 날짜만 잡고 그 앞을 안 두면 일정이 그대로 밀린다.
그래서 기능 완료와 제출과 심사 결과와 공개를 날짜로 나눠 적고 반려를 전제한 여유를 넣었다. App Store Connect 스크린샷 촬영도 빌드가 확정된 뒤에 하도록 배포 절차의 마지막에 넣었다.
정리
- 반려 사유는 대개 기능이 아니라 설명과 확인 가능성이다
- 기능을 만드는 것과 심사를 통과하는 것은 다른 축이다
NSLocationWhenInUseUsageDescription에 왜 필요한지와 무엇을 수집하지 않는지를 함께 적는다- 만든 사람의 실행 조건이 확인하는 쪽에는 없다
- 심사용 계정과 시연 방법을 제출 노트에 준비하되 시연 모드를 격리한다
- 배포 경로를
TestFlight내부와 외부와 정식으로 나눈다 CFBundleVersion은 재사용이 안 되므로 자동으로 올린다- 일정에 심사 기간과 반려 여유를 함께 넣는다