iOS 앱을 수년간 만들어왔지만 아직도 Review 후 거절당하는 경우가 꽤 많다. 대부분 첫 번째 출시 버전에서 발생하는 거절 사유이고, 첫 번째 등록이 성공적으로 진행된다면 이후의 업데이트는 무난히 진행되곤 한다. 그래도 예상치 못했던 ‘거절’이 발생했기 때문에 이에 대해 정리해보았다.

1. 애플의 iOS 리뷰 가이드라인 준수

애플은 자사의 가이드라인을 매우 중시한다. iOS Review Guideline라는 문서를 한 번 정도는 정독할 필요가 있다. 이 가이드라인에 위배되는 사항이 있다면 당연히 승인 거절될 수 있다. 사실 한글로 정리된 블로그 문서들도 많다. 모두 다 읽기 어렵다면 간단한 방향성만 알아두자.

2. 앱의 완성도

애플의 앱스토어 담당자와 대화를 나눠본 결과, 이들은 ‘아이폰을 사야할만큼 좋은 사용자 경험’을 제공할 수 있는 앱을 원한다. 앱을 사용하는 사람이 불편함을 느끼는 수준의 앱이라면 승인 거절 사유가 될 수 있다. 대략적인 내용은 다음과 같다.

• 버그가 있는 경우 승인이 거절된다.
• 모든 버튼은 동작해야 한다. 개발 중인 앱은 심사를 받을 수 없다. (예를 들어, 개발이 완료되지 않은 기능을 눌렀을 때 ‘준비 중입니다’ 등의 문구를 보여주거나, 앱에 Beta, Test 등의 문구가 들어가면 안된다.)
• 앱이 단순 웹페이지 링크를 연결하거나 웹 페이지를 단순히 App으로 패키징하는 등 ‘앱으로서 가치가 없다고 판단되는’ 서비스이면 안된다.
• 정상적으로 동작하지만, 앱이 지나치게 느린 경우 거절될 수 있다. 이번 케이스는 하이브리드앱으로 특정 고객사 내부에서 사용하는 앱으로 만들었다. 내부 ERP에 있는 기능을 모바일/타블렛으로 옮겨오는 작업이라 클라이언트 DB를 어마어마하게 검색해야하는 앱인데, 이게 매우 느리다. 국내 또는 클라이언트 내부망에서는 ‘어느정도’ 정상 속도가 나오지만, 앱스토어 리뷰어가 경험하는 속도는 이보다 훨씬 느렸던 것 같다.

3. 사용자 어뷰징

조금 정책적인 부분인데, 즉각적인 리워드를 통해 앱 설치를 유도한다면 이는 거절 사유가 된다. 예를 들어 앱을 설치하는 목적이 금전적인 리워드를 주요 목적으로 하는 앱이라면 다운로드 수가 앱의 가치에 비해 지나치게 높아질 수 있고, 이는 사용자의 앱스토어 경험에 좋지 않은 영향을 준다는 의미다. 다만 앱스토어에는 이미 많은 리워드 앱들이 있기 때문에 무조건 안된다기 보다는 리뷰어와의 대화를 통해 어떤 지점이 문제가 되는지를 잘 판단해야 된다. 다만 리뷰를 받는 시점은 서비스의 컨셉, 기능, 디자인, B/M이 확정된 상태일거라 심사 결과에 따라 많은 부분이 변경되어야할 수 있다. 가급적이면 B/M 등을 검증할 수 있는 MVP 앱으로 심사를 받아놓는게 좋다. 내가 경험한 사례는 다음과 같다.

• 앱 설치 후 매장을 방문하여 체크인을 하거나, x분 동안 머무르는 경우 포인트 리워드 제공. 그리고 랜덤 게임 등을 통해 리워드 제공. 광고성 컨텐츠 시청 후 리워드 제공 등을 주요 기능으로 하는 서비스였는데, iOS는 오랜시간의 커뮤니케이션을 통해서도 승인되지 않았다.

4. 특정 사용자만 이용하는 서비스

앱을 출시할 때 1) 공개용 Appstore를 사용할 것인지, 2) ABM(Apple Business Manager)를 통한 인터널 배포를 할 것인지 정할 수 있다. 회사 내부에서만 사용할 목적으로 회원가입 없이 임직원 대상으로 부여된 ID/PW로 로그인하는 구조의 서비스인 경우 거절된다.

• 로그인 인증 절차가 있는 앱인데, 회원 가입 절차가 없는 ‘내부 사용 목적의 앱’인 경우 승인이 거절된다.
• 글로벌 출시한 앱인데, 실제 동작은 한국에서만 가능한 앱 역시 비슷한 사유로 승인이 거절된다.

5. 메타 정보의 적절성

스크린샷에 있는 이미지에 안드로이드 Status Bar가 포함되는 등 iOS에 맞지 않는 정보가 포함되면 안된다. 앱의 이름, 소개글, 검색 키워드 역시 적절해야 한다.

• 메타 정보에 베타 / 알파 / 테스트 버젼 같은 문구는 들어갈 수 없다.
• 메타 데이터의 설명 문구, 스크린샷, 기타 정보와 실제 앱이 다르면 안된다.
• 관련 없는 서비스명 (예: 카카오톡)을 검색 최적화의 목적으로 삽입해서는 안된다.
• 경우 배포 국가를 ‘글로벌’로 지정해놓은 경우, 거절 사유가 된다. 현재 국가를 ‘한국’으로 변경하고 다시 신청 절차에 들어갔다. (결과는 나와봐야 알것 같다.)

6. iOS 기본 UX와 충돌하는 경우

일반화해서 언급하기는 어렵지만, iOS에서 추구하는 기본 UX와 다른 방식으로 동작하는 경우에도 거절될 수 있다. 예를 하나 들자면, 앱스토어에 신규 버전이 등록되면 앱에서 강제 업데이트를 안내하는 팝업을 띄워주는 기능이 있었는데, 이 역시 거절 사유가 되었다. (구현 방식 : 앱스토어 버젼과 현재 버젼을 비교해서 서로 다르면 (또는 앱스토어 버젼보다 현재 버젼이 낮다면) 팝업을 띄우고 업데이트를 유도함. 단, 취소 시 강제하지 않음)

7. 테스트 가능성

담당자가 테스트할 수 있도록 테스트 ID를 정확하게 전달한다. 스토어에 심사를 요청해놓고, 미리 작성해놓은 테스트 ID가 동작하지 않아 (개발 DB를 변경하면서 발생) Reject을 당했던 적이 있다. 앱의 UX가 지나치게 어렵거나, 테스트 가능하지 않다고 판단해도 거절될 수 있다.

• 테스트 아이디, 패스워드가 동작하는지 확인해야 한다.
• 아이디 / 패스워드 방식이 아니라 페이스북, 카카오톡 등 소셜 로그인만 진행하는 경우에는 리뷰어가 테스트를 진행할 수 없다. 이 경우에도 중요한 Reject 사유가 된다. 따라서 Review Note 하단에 있는 파일 첨부란에 앱 사용 동영상을 첨부하는게 좋다. 앱 사용 동영상은 반드시 ‘아이폰’으로 구동하는 모습을 보여줘야 한다. 에뮬레이터나 아이폰을 연결해서 퀵타임으로 찍는 방식은 피한다. (대충 찍어도 된다. 하지만 아이폰이 있고, 손가락을 움직여서 직접 사용하는 것을 보여주는게 좋다.)

8. HealthKit, GPS, Bluetooth 등의 기능 사용시 주의

애플은 하나의 앱이 다른 앱 사용을 통제하거나, 아이폰이 제공하는 리소스에 접근하는 상황을 매우 주의깊게 관찰한다. 특히, 하나의 앱이 아이폰 리소스를 과도하게 사용하거나, HealthKit 처럼 개인 정보를 다루는 경우라면 더욱 그렇다.

• Apple Healthkit을 사용한다면 메타데이터에 사용을 ‘반드시’ 명시하고, 앱 내에는 데이터 사용에 대한 문구가 반드시 약관과 함께 들어가야 한다. 특히, Healthkit을 연동하는 버튼이 있다면 버튼 근처에 Healthkit의 정보를 어떻게 사용한다는 사실을 문구로 명시해야 한다.
• Background GPS 기능을 사용하거나, Geo-fence와 같이 베터리를 소모하게될 기능들은 세부 항목들을 꼼꼼히 살펴야한다. 잘 모르겠다면 해당 기능을 구현한 후에 한 번 정도 미리 심사를 받아보는 것도 좋다. (아마 한두번은 어떤 이유에서든 거절될 가능성이 있다.)
• 혹시라도 외부 디바이스와 직접 연결되는 앱이라면 디바이스를 애플 본사에 보내야 할 수 있다. 예를 들어 웨어러블 디바이스와 연동되는 앱이라면 당연히 해당 디바이스를 미국 애플 본사로 보내야 한다. (우리는 배송하다가 UPS의 배송 사고가 발생해서 거의 한 달이 걸리기도 했다. 물론 다른 앱에서는 보내지 않고 앱 사용 동영상으로 대체한 경우도 있다.)

9. 3rd Party 웹 페이지 접근 (feat. 저작권 이슈)

예를 들어 내가 만든 앱에 네이버 메인 화면이 노출되는 페이지가 있다면 두 가지 부분에서 문제가 된다. 1) 하나는 단순 스크래핑 / 웹 링크만 붙이는 앱은 ‘웹’과 다를 바 없으니 굳이 앱으로 만들 필요가 없다며 거절하는 것이고, 2) 두 번째는 그렇게 노출되는 웹의 접근성에 대해 계약서 등으로 권한을 갖고 있는지를 묻는다.

• 커머스 앱 개발 시 다른 판매자의 스마트스토어 등을 웹뷰로 바로 접근해서는 안된다.
• 앱에서 웹이 사용되는 비중은 문제되지 않지만, 웹 그 자체여서는 안된다.

10. 신고 기능 누락

채팅 앱을 만들어 심사에 들어갔고, ‘부적절한 컨텐츠에 대한 리포팅 기능’이 없다는 이유로 거절 되었다. 정확히는 바이너리 테스트 이전에 이루어지는 메타데이터 확인 단계에서 거절된 것으로 보인다. 일단은 별도의 수정 없이, 왜 리포팅 기능이 없어도 되는지를 설명하는 것으로 진행하였고, 결과적으로 이슈 없이 승인되었다.

• 사용자가 글, 사진을 작성하는 기능이 있다면 반드시 ‘신고’ 및 ‘컨텐츠 차단’ 기능이 있어야 한다.
• 소셜 같은 서비스가 아니라 사용자가 문의를 남기거나, 상품에 대해 리뷰를 쓰는 기능도 모두 포함된다.

11. 백그라운드 동작

기본적으로 백그라운드로 앱을 동작시키려면 애플이 정해놓은 몇 가지 카테고리에 포함되는 앱이어야 한다. 전화, 네비게이션, 음악 등 백그라운드 동작을 할 수 있어야만하는 앱만 백그라운드 동작이 허용된다. 백그라운드에서 위치를 추적한다거나, 서버와 백그라운드에서 지속적으로 동기화하는 기능을 가진 앱들은 거절된다.

정리하자면,

이 외에도 무수히 많은 사유로 심사 거절될 수 있기 때문에 iOS 앱을 처음 런칭하는 경우 여유있게 ‘미리미리’ 심사를 받아놓는게 좋다. 예를 들어 1월 1일에 런칭하려는 앱이 있다면 12월초부터 심사 > 리뷰 > 통과 > 배포 취소 > 심사를 반복하는게 좋다. 한번 통과된 앱은 다음에도 통과될 가능성이 매우 높기 때문에 초기 버전의 앱을 지속적으로 제출해서 심사 거절되는 사유가 발생하는지 확인하는게 안전하다.

심사 거절을 오랜시간 겪으면서 느낀점이 있다면, 애플은 앱스토어에 올라오는 앱의 완성도가 곧 아이폰에 대한 사용자 경험이라고 생각하는 것 같다. 그만큼 자신들이 만들어놓은 높은 기준치에 도달한 앱이 사용자와 만나기를 바란다는 인상이 강하다. 왜 안드로이드는 되는데, iOS는 안되냐고 물을 필요는 없을 것 같다. 어차피 우린 애플이 만들어놓은 앱스토어 생태계에 자발적으로 참여하고 있는 것이니 말이다.