스토어 심사에 제출하기 전에 확인할 다섯 가지

첫째, 제출할 빌드로 핵심 흐름을 확인합니다

개발 환경에서 한 번 실행된 것과 제출할 앱이 정상 동작하는 것은 다릅니다. 제출할 버전의 설치부터 로그인, 주요 기능, 오류 후 복귀까지 확인하고 테스트한 기기와 환경을 남깁니다. 서버 주소나 기능 설정이 개발용으로 남아 있지 않은지도 확인해야 합니다.

검토용 체크리스트에는 절차와 기대 결과를 짝지어 적습니다. “예약 확인”보다 “테스트 계정으로 예약을 만들고 목록에 표시되는지 확인”처럼 직접 재현할 수 있는 표현이 좋습니다. 특정 기기나 외부 장치가 필요한 기능은 그 준비 방법도 기록합니다.

Apple의 제출 전 안내에는 충돌과 오류 점검, 완전한 앱 정보, 심사 중 접근 가능한 서비스가 포함됩니다. 제출할 때 해당 스토어의 최신 안내를 다시 확인하세요.

둘째와 셋째, 접근 방법과 소개 자료를 맞춥니다

둘째는 심사자가 기능에 접근할 수 있는지입니다. 로그인이 필요한 기능은 실제로 사용할 수 있는 접근 방법과 따라 할 절차를 준비합니다. 추가 인증이나 특정 데이터가 필요한 경우에는 검토를 막지 않도록 설명을 보완합니다. 제출 직전에 새 환경에서 그 절차를 다시 따라가 보세요.

셋째는 소개 자료가 앱과 맞는지입니다. 설명, 화면 이미지, 지원 주소가 제출한 버전과 일치하는지 확인합니다. 아직 제공하지 않는 기능을 현재 사용할 수 있는 것처럼 보이게 하지 않고, 접근 조건이 있는 기능은 그 조건을 명확하게 설명합니다.

Google Play의 앱 검토 준비 안내에서도 앱 접근과 콘텐츠 관련 제출 정보를 다룹니다. 프로젝트별 준비 문서는 계정, 절차, 필요한 데이터, 확인 날짜를 한곳에서 찾을 수 있게 구성하면 편리합니다.

넷째와 다섯째, 데이터 처리와 상품 흐름을 대조합니다

넷째는 앱의 데이터 처리와 제출 정보가 맞는지입니다. 앱 자체뿐 아니라 포함한 SDK가 어떤 데이터를 다루는지 확인하고, 권한 요청의 설명과 스토어에 제출하는 정보를 대조합니다. 사용자가 허용하지 않았을 때 앱이 어떤 기능을 제공하는지도 직접 확인합니다.

다섯째는 판매하는 상품과 앱의 구매 흐름이 맞는지입니다. 결제 방식은 상품 종류, 제공 지역, 배포 조건에 따라 검토해야 합니다. 성공 화면뿐 아니라 취소, 복원, 처리 지연 시 사용자에게 어떤 상태를 보여 줄지도 확인합니다. 모든 앱에 같은 결제 방식을 적용할 수 있다고 가정하지 않습니다.

세부 적용은 Apple 심사 가이드라인과 해당 스토어의 현재 정책을 기준으로 확인합니다. 이 글의 다섯 항목은 준비를 돕는 점검 틀이며, 승인 결과나 반려 빈도를 뜻하지 않습니다.

보완 요청은 제출 버전과 연결해 남깁니다

보완 요청을 받으면 어떤 버전에서 어떤 절차로 문제가 발생했는지 먼저 정리합니다. 재현 결과, 수정 내용, 제출할 설명을 나누어 기록하면 앱 변경이 필요한 문제와 안내가 부족했던 문제를 구분하기 쉽습니다.

응답에는 검토자가 따라 할 수 있는 단계와 확인할 화면을 제시합니다. 변경한 빌드를 다시 제출한다면 이전 버전과 무엇이 달라졌는지도 함께 정리하세요. 같은 문구를 반복해서 보내기보다 요청한 항목이 해결됐다는 근거를 보여 주는 것이 목적입니다.

일정표에는 제출일과 출시 희망일을 별도로 두고, 보완 작업과 재검토가 필요한 상황을 고려합니다. 심사 준비 담당자와 문의를 받을 사람을 정해 두면 개발 완료 뒤에도 필요한 작업이 빠지지 않습니다.