AcceptMyApp

AcceptMyApp은 App Store의 보편적 요구 사항과 앱의 기능, 권한, 비즈니스 모델에 맞춘 항목을 섞은 맞춤형 체크리스트를 만든다. 스크린샷, 메타데이터, 연령 등급, 개인정보 보호 선언을 다루고, 진행하며 체크할 앱별 항목을 더한다. 요점은 단순하다. 알아채지 못한 빈틈을 안고 제출하는 것을 막는다.

Apple 자체 심사보다 먼저 돌아가는 iOS 앱 심사 검사기라고 생각하면 된다. 위험 분석은 제출 전에 가이드라인 문제를 드러내며, 조용히 거부를 유발하는 수익화, 권한, 메타데이터 문제에 집중한다. 지적된 영역마다 점수가 붙고, 도구는 '제출 가능' 판정으로 마무리한다. 구체적인 예도 보인다. 페이월 전에는 보이지 않는 구독 조건(가이드라인 3.1.2)이나 키워드에 숨어 있는 경쟁사 이름(가이드라인 2.3.7) 같은 것이다.

GitHub 저장소에 일회성 읽기 권한을 부여하면 Code Checker가 심사 함정이 없는지 소스를 스캔한다. Info.plist, 개인정보 보호 매니페스트, entitlements를 살피고, 이를테면 이유를 설명하지 않고 "We need access"라고만 쓴 카메라 용도 문자열을 짚어 낸다. 이런 모호한 문자열은 가이드라인 5.1.1에서 흔한 거부 사유다. 직접 쓴 문자열이면 놓치기도 쉽다.

이 도구는 제목, 부제, 키워드를 다시 써서 명확하게 읽히고 Apple의 글자 수 제한에 맞춘다. 현재 문구와 제안을 나란히 보여 주므로 무엇이 바뀌었는지 정확히 알 수 있다. 키워드 남용과 무관한 브랜드 용어는 가이드라인 2.3에 해당하므로, 메타데이터를 한 번 깔끔하게 정리하면 메타데이터성 거부를 통째로 한 부류 없앨 수 있다. 작은 편집. 통과 확률에는 큰 효과다.

Apple의 거부 문구를 붙여 넣으면 AcceptMyApp이 근본 원인을 쉬운 말로 알려 주고, 수정할지 이의를 제기할지 지침을 주며, Resolution Center로 바로 보낼 답변 초안 두 개를 제공한다. 초안은 피드백을 인정하고 가한 변경 사항을 명시한다. 심사 담당자가 기대하는 구조다. 편집은 여전히 직접 한다. 다만 빈 페이지에서 시작하지는 않는다.

지침은 Apple의 공식 가이드라인에 대조해 작성됐으며, 도구는 그 갱신을 따라간다. 이 점이 중요하다. 규칙은 일 년 내내 바뀌고, 지난 시즌 가이드라인에 근거한 조언은 당신을 엉뚱한 방향으로 이끌 수 있다. 결과물을 강력한 출발점으로 삼고, 의존하기 전에 구체적인 부분은 확인하길 바란다.