App Store 심사가 팀에 실제로 드는 비용

총 99개의 스토리를 보여줍니다.

1. 

   4.3(a) 스팸 iOS 가이드라인 4.3

   포트폴리오 전체가 한꺼번에 플래그된 상황

   무슨 일이 있었나

   동일한 스타터 프로젝트로 여러 앱을 만든 개발자는 모든 앱에서 똑같은 4.3 통지를 받았습니다. 앱들이 바이너리, 메타데이터, 콘셉트가 약간만 다를 뿐 유사했기 때문입니다. 개발자는 앱을 하나씩 처리해 나가기로 했습니다.

   해결

   게시 시점 기준 아직 진행 중입니다.

   교훈

   4.3(a)는 본인 앱들 간의 중복도 다룹니다. 여러 앱이 하나의 템플릿에서 나왔다면, 새 아이콘과 이름만으로는 부족하며 각 앱에 진짜로 구별되는 핵심이 있어야 합니다.

2. 

   4.3(a) 스팸 iOS 가이드라인 4.3

   일주일 만에 같은 거절 메일을 두 번

   무슨 일이 있었나

   작은 단일 목적 사진 도우미 앱이 한밤중에 4.3(a) 사유로 거절됐습니다. 이전 빌드에서 정확히 같은 거절 문구를 받은 지 일주일 만이었죠.

   해결

   명시되지 않음

   교훈

   겉만 바꿔 재제출해도 4.3 결정은 거의 바뀌지 않습니다. 컨셉을 바꾸거나, 리뷰 노트에 앱이 무엇이 다른지 명확히 설명하세요.

3. 

   4.3 디자인 / 스팸 iOS 가이드라인 4.3

   포화된 카테고리에서 앱 개발하기

   무슨 일이 있었나

   매일 빌드 챌린지를 기록하던 1인 개발자가 4일 차에 4.3 Design / Spam 거절을 받았습니다. 그는 포화된 카테고리를 선택한 게 실수였는지 의문을 품기 시작했습니다.

   해결

   명시되지 않음

   교훈

   Apple이 포화 상태로 분류한 카테고리는 심사가 더 까다롭습니다. 심사 후가 아니라 빌드 전에 앱의 차별점을 검증하세요.

5. 

   2.1 필요한 정보 iOS 가이드라인 2.1

   신규 계정을 위한 7가지 질문

   무슨 일이 있었나

   한 팀의 첫 제출이 2.1 Information Needed로 반려되었습니다. 7가지 질문과 화면 녹화 영상, 데모 계정 요청이 있었죠. 솔직하게 답변하자 놓쳤던 4가지가 드러났습니다.

   해결

   문제를 해결하고 답변했습니다.

   교훈

   신규 개발자 계정이라면 이 상황을 예상해야 합니다. 제출 전에 데모 계정, 녹화 영상, 명확한 심사 노트를 준비하세요.

6. 

   2.1 앱 완성도 iOS 가이드라인 2.1

   리뷰어가 앱 사용법을 이해하지 못함

   무슨 일이 있었나

   처음 앱을 출시하려는 개발자가 두 번이나 거절당했습니다. 첫 번째 거절 사유(2.1 항목)는 리뷰어가 앱의 사용 방식을 이해하지 못했기 때문이었습니다.

   해결

   실제 기기에서 녹화한 데모 영상과 단계별 리뷰 노트를 추가한 후 승인되었습니다.

   교훈

   리뷰어에게는 맥락 없이 몇 분만 주어집니다. 무엇을 탭하고 무엇이 보여야 하는지 정확히 알려주세요.

7. 

   메타데이터 및 인앱 구매 설정 iOS 메타데이터와 IAP

   알고 있던 체크박스 때문에 두 번 거절

   무슨 일이 있었나

   한 인디 개발자는 이미 알고 있던 것들 때문에 두 번 거절당했습니다. 처음에는 인앱 구매가 연결되지 않은 채 빌드가 올라갔고, 설명에 이용 약관 링크가 없었습니다. 몇 주 후에는 스크린샷에 앱이 무료라고 적혀 있었습니다.

   해결

   매번 수정해서 다시 제출했습니다.

   교훈

   메타데이터, 구독, 법적 링크에 대한 제출 전 체크리스트를 관리하세요. 대부분의 메타데이터 거절은 피할 수 있습니다.

8. 

   심사 대기 시간 iOS 끝없는 심사

   9일 대기 후 8일간 심사

   무슨 일이 있었나

   한 개발자는 상태가 Waiting for Review에서 In Review로 바뀌기까지 9일을 기다린 뒤, 별다른 업데이트 없이 8일 더 심사 중 상태로 머물렀습니다.

   해결

   게시 당시 기준 없음.

   교훈

   심사 기간은 보장되지 않습니다. 출시일이나 언론 홍보, 크리에이터 캠페인 일정을 예상 승인일에 절대 맞추지 마세요.

9. 

   심사 대기 시간 iOS 끝없는 심사

   거절, 수정, 대기의 20일간의 굴레

   무슨 일이 있었나

   한 개발자가 거절과 수정, 심사 대기, 다시 거절과 수정의 과정을 20일 넘게 반복하며 글을 쓰는 순간까지도 여전히 기다리고 있었습니다.

   해결

   심사 대기 중

   교훈

   반복되는 심사 과정은 며칠씩 소요될 수 있습니다. 거절 사유를 모아 한 번에 수정하고 단일 빌드로 제출하세요.

10. 

    계정 해지 iOS 계정 해지

    첫 리뷰 전 거절

    무슨 일이 있었나

    10년 차 개발자가 구체적인 사유도 모른 채 사기 혐의로 계정이 해지되었습니다. 언어 학습 게임은 첫 리뷰를 기다리던 중이었고, 기존 앱들은 모두 사라졌으며 고객들은 이유를 묻기 시작했습니다.

    해결

    보고된 사례 없음

    교훈

    계정이 해지되면 모든 앱이 한꺼번에 삭제됩니다. 스토어 접속이 불가능해질 상황을 대비해 사용자 채널(이메일, 웹사이트 등)을 별도로 확보해 두세요.

11. 

    계정 해지 경고 iOS 계정 해지

    거절된 버전이 너무 많음

    무슨 일이 있었나

    활발하게 활동하던 한 인디 개발자가 10일 뒤 계정이 해지된다는 통보를 받았습니다. Apple은 거절된 버전 수가 그 이유 중 하나라고 밝혔습니다. 대중의 관심과 이의 제기 끝에 계정은 해지되지 않았습니다.

    해결

    이의 제기 후 계정 유지.

    교훈

    거절은 쌓이기 마련입니다. 단어 하나만 바꾼 채 당일에 재제출하거나, 자신의 앱을 거의 똑같이 복제해 다시 올리는 일은 피하세요.

12. 

    로그인 요구 사항 (가이드라인 번호 미기재) iOS 로그인 요구 사항

    회원가입 필수: 당신 앱은 그만큼 큰 앱이 아닙니다

    무슨 일이 있었나

    한 개발자의 소셜 앱이 홈 피드에 들어가기 전 계정 생성을 요구한다는 이유로 거절되었습니다. 개발자는 앱이 작동하려면 모든 사용자에게 핸들이 필요하다고 설명하며, 동일한 방식을 사용하는 대형 사진 공유 네트워크를 예로 들었습니다. 하지만 리뷰어는 사실상 해당 앱이 그 네트워크는 아니라는 식으로 답했습니다.

    해결

    명시되지 않음

    교훈

    대형 앱들이 허용받는 사례를 근거로 제시할 수는 없습니다. 가입이 필요하다면 리뷰 노트에 계정 없이는 핵심 기능이 왜 작동할 수 없는지 설명하고, 리뷰어나 게스트가 일부 콘텐츠를 먼저 볼 수 있게 하는 것도 고려하세요.

13. 

    4.3 스팸 iOS 가이드라인 4.3

    리뷰가 전혀 없다가 거의 모두 거절되기까지

    무슨 일이 있었나

    한 개발자는 며칠 동안 자신의 앱이 하나도 리뷰되지 않는 상황을 겪었습니다. 약 일주일 동안 기다리면서 제출 건을 더 만들었습니다. 심사가 마침내 진행됐을 때, 거의 모두가 가이드라인 4.3 스팸으로 거절됐습니다.

    해결

    명시되지 않음

    교훈

    심사 대기열이 정체됐다고 더 제출하라는 신호는 아닙니다. 심사가 진행되지 않는 동안 제출을 쌓아두면, 리뷰어가 마침내 한꺼번에 보게 되면 계정이 스팸 패턴처럼 보일 수 있습니다.

14. 

    4.3 스팸 iOS 가이드라인 4.3

    무관한 앱들이 함께 거절됨

    무슨 일이 있었나

    한 개발자가 수개월에 걸쳐 만든 서로 무관한 앱 여러 개가 동시에 스팸으로 거절됐습니다. 그는 이게 정상인지 공개적으로 물었습니다.

    해결

    명시되지 않음

    교훈

    4.3은 앱별이 아니라 계정 단위로 적용될 수 있습니다. 여러 앱이 한꺼번에 거절됐다면 각각 따로 답변하고, 리뷰 노트에 각 앱이 어떻게 다른지 분명히 적으세요.

15. 

    심사 대기 시간 iOS 끝없는 심사

    한 번의 거절, 그리고 두 달간의 침묵

    무슨 일이 있었나

    한 번 거절된 뒤 개발자의 앱은 약 두 달 동안 심사에 묶여 있었고, 각 심사 주기는 대략 한 달씩 걸렸습니다. 개발자는 긴 심사 주기가 신규 앱을 막는 수단이 된 게 아닐까 의심했습니다.

    해결

    게시 시점에도 여전히 심사 중

    교훈

    거절된 뒤에는 다음 심사 주기가 첫 번째보다 훨씬 느려질 수 있습니다. 재제출은 빈틈없이 준비하고 문서도 충실히 갖춰, 두 번째 심사에 또 한 달을 허비하지 않도록 하세요.

16. 

    부적절한 콘텐츠 iOS 부적절한 콘텐츠

    수정 없이 재제출하여 거절됨

    무슨 일이 있었나

    한 AI 사진 편집 앱이 Apple이 지적한 '부적절한 콘텐츠' 문제를 해결하지 않은 채 여러 번 재제출했다가 거절되었습니다.

    해결

    거절됨.

    교훈

    검토자가 바뀌길 바라며 동일한 빌드를 재제출하는 것은 불리하게 작용할 수 있습니다. 재제출 전, 지적된 문제를 수정하거나 Resolution Center를 통해 명확한 설명을 요청하세요. 생성형 AI 기능의 경우, Apple이 부적절하다고 판단하는 콘텐츠에 대한 필터를 추가하세요.

17. 

    4.3 스팸 iOS 가이드라인 4.3

    심사 시작과 동시에 거절됨

    무슨 일이 있었나

    한 개발자가 몇 주를 들여 앱을 만들었는데, 심사가 시작된 바로 그 1분 만에 4.3 스팸으로 거절됐습니다. 개발자는 리뷰어가 앱이 아니라 니치를 보고 판단했다고 생각했습니다.

    해결

    명시되지 않음

    교훈

    경쟁이 치열한 니치에서는 자세히 검토되기도 전에 4.3 거절이 나올 수 있습니다. 리뷰 노트 맨 앞에 앱만의 차별점을 적고 리뷰어가 바로 확인하게 하세요.

18. 

    4.2.6 템플릿 iOS 가이드라인 4.2.6

    사용한 적 없는 템플릿 때문에 플래그됨

    무슨 일이 있었나

    한 팀이 가이드라인 4.2.6 위반으로 거절되었습니다. 이 가이드라인은 상용화된 템플릿이나 앱 생성 서비스로 만든 앱을 대상으로 하지만, 해당 팀은 템플릿이나 생성 서비스를 전혀 사용하지 않았습니다.

    해결

    명시되지 않음

    교훈

    4.2.6은 오탐(false positive)일 수 있습니다. Resolution Center에서 앱이 커스텀 빌드되었으며 누가 개발했는지 분명히 밝히고, 소스나 개발 이력을 보여주겠다고 답변하세요.

19. 

    3.1.2 구독 iOS 가이드라인 3.1.2

    월간 가격이 실제 청구 금액보다 크게 표시됨

    무슨 일이 있었나

    한 개발자의 paywall이 거절되었습니다. 장기 구독의 월 환산 금액을 실제 청구 금액보다 더 눈에 띄게 표시했기 때문입니다. 같은 paywall이 이전 리뷰에서는 아무 지적 없이 통과된 적이 있었습니다. 개발자는 규칙에는 동의했지만 이제서야 지적된 점에 답답함을 느꼈고, 실제 청구 금액을 가장 앞세우도록 paywall을 재설계했습니다.

    해결

    새 디자인으로 재제출 완료.

    교훈

    이전에 통과된 paywall이라도 나중에 거절될 수 있습니다. 항상 실제 청구 금액과 결제 주기를 가장 눈에 띄게 표시하세요. 월 환산 금액은 더 작게, 보조 정보로 표시해야 합니다.

20. 

    프로그램 등록 (App Review 가이드라인 아님) Apple Developer Program 등록 및 계정

    두 달, 그리고 이유 없는 거절

    무슨 일이 있었나

    한 개발자는 등록을 위해 두 달 넘게 여러 차례 고객 지원 전화와 이메일을 주고받고, 본인 인증과 기기 정보, 심지어 영상 증거까지 제출했습니다. 하지만 Apple은 구체적인 이유를 밝히지 않은 채 등록을 거절했습니다.

    해결

    게시 당시 기준 없음.

    교훈

    등록 과정은 앱을 빌드하는 것보다 훨씬 오래 걸릴 수 있습니다. 출시 계획이 등록에 좌우되기 전에 미리 등록을 시작하고, 모든 지원 상담 내역을 기록해 두세요.

21. 

    5.1.2 데이터 사용 및 공유 iOS 가이드라인 5.1.2

    스타트업을 위협한 App Tracking Transparency 거절 사례

    무슨 일이 있었나

    빠르게 출시하고 사용자 피드백도 강했던 한 스타트업의 앱이 늦가을에 App Tracking Transparency 문제로 거절되었습니다. App Tracking Transparency는 앱과 웹사이트를 넘나드는 추적 전에 사용자 권한을 요구하는 iOS 개인정보 보호 규칙입니다. 창업자는 나중에 이 거절이 회사 전체를 위험에 빠뜨린 사건이었다고 말했습니다.

    해결

    게시글에 명시되지 않음.

    교훈

    제출 전 앱 내 모든 SDK에서 추적 여부를 점검하세요. 사용자 데이터를 다른 회사 데이터와 연결하는 요소가 있다면, 서드파티 라이브러리에서 비롯된 추적이더라도 추적 권한 prompt와 이에 맞는 개인정보 보호 라벨이 필요합니다.

22. 

    로그인 (가이드라인 번호 미기재) iOS 로그인

    리뷰어가 Apple 또는 Google로 로그인할 수 없음

    무슨 일이 있었나

    봇 가입을 막으려고 개발자가 이메일·비밀번호 로그인을 없애고 Sign in with Apple과 Google 로그인만 남겼습니다. 개발자 본인의 iPhone과 iPad에서도, 다른 이유로 앱을 거절했던 이전 리뷰어에게도 잘 작동했습니다. 하지만 다음 리뷰어는 로그인할 수 없다며 앱을 거절했습니다.

    해결

    명시되지 않음

    교훈

    앱이 소셜 로그인만 제공하면 리뷰어가 여전히 막힐 수 있습니다. 리뷰 노트에 데모 계정이나 리뷰 전용 로그인 같은 로그인 방법을 안내하고, 제출할 때마다 새 기기와 새 계정에서 로그인을 테스트하세요.

23. 

    모의 도박 (가이드라인 번호 미기재) iOS 모의 도박

    개인 계정의 인게임 스테이킹 기능

    무슨 일이 있었나

    한 게임이 모의 도박을 포함해 거절되었습니다. 플레이어들이 게임 아이템을 걸고 서로 대결할 수 있었는데, 이는 클래식 온라인 RPG에서 흔한 방식입니다. 개발자가 법인이 아닌 개인 계정으로 출시했기 때문에 당분간 이 기능을 제거하기로 했습니다.

    해결

    기능을 제거하고 다시 제출합니다.

    교훈

    실제 돈이 오가지 않아도 도박 스타일 메커니즘은 추가 심사를 받습니다. Apple이 허용하는 범위 중 일부는 계정 유형과 문서에 따라 달라집니다. 스테이킹, 전리품, 베팅 기능을 만들기 전에 도박 관련 규정을 확인하고, 그에 맞춰 개발자 계정 유형을 계획하세요.

24. 

    위조 문서 (가이드라인 번호 미기재) iOS 위조 문서

    사용자가 할 수 있는 일 때문에 문제가 된 PDF 에디터

    무슨 일이 있었나

    한 PDF 에디터 앱이 위조 신분증이나 문서를 만들 수 있다는 이유로 Apple로부터 리젝을 받았습니다. 개발자는 같은 논리라면 악의적인 사용자가 앱을 어떻게 활용할지에 따라 모든 뱅킹이나 메시징 앱도 리젝될 수 있다고 반박했습니다.

    해결

    명시되지 않음

    교훈

    범용 도구는 최악의 사용 사례를 기준으로 판단될 수 있습니다. 공식 신분증이나 증명서처럼 보이는 템플릿 또는 마케팅 문구는 피하고, 리뷰 노트에 앱의 목적과 지원하지 않는 기능을 명확히 설명하세요.

25. 

    AI 데이터 공유 (가이드라인 번호 미기재) iOS AI 데이터 공유

    제3자 AI 데이터 공유 동의 화면 없음

    무슨 일이 있었나

    한 팀이 사용자 데이터를 제3자 AI 제공업체와 공유한 것 때문에 첫 리젝을 받았습니다. Apple은 사용자로부터 명시적 동의를 받고, 어떤 데이터가 어떤 AI 제공업체로 전송되는지 명확히 공개하도록 요구했습니다. 팀의 고민은 전환율을 떨어뜨리지 않으면서 심사를 통과할 동의 화면을 만드는 것이었습니다.

    해결

    진행 중.

    교훈

    앱이 사용자 콘텐츠를 외부 AI 서비스로 전송한다면, 첫 요청 전에 동의를 받고 제공업체와 관련 데이터를 명시하세요. 리젝 후가 아니라 제출 전에 해당 화면을 구현해 두세요.

26. 

    Family Controls entitlement (가이드라인 번호 미표기) iOS 메타데이터와 IAP

    체크박스 하나 때문에 겪은 5번의 리젝

    무슨 일이 있었나

    스크린 타임 스타일의 앱을 출시하려던 한 개발자가 5번이나 리젝을 당했습니다. 모호한 리뷰 피드백 때문에 개발자는 디자인 자체에 문제가 있다고 생각했죠. 하지만 진짜 원인은 개발자 설정에서 Family Controls 항목을 체크하지 않았기 때문이었습니다. 설정을 활성화하자마자 앱은 승인되었습니다.

    해결

    Family Controls 설정을 활성화하고 재제출하여 승인 완료.

    교훈

    리젝 사유가 모호하다면 제품을 재설계하기 전에 entitlements와 인증서를 먼저 점검하세요. Screen Time 및 Family Controls 앱은 Xcode뿐만 아니라 개발자 포털에서도 관련 capability를 활성화해야 합니다.

27. 

    가이드라인 5.1.1(v) iOS 가이드라인 5.1.1 로그인 요구 사항

    기기에서 실행되는 유료 기능에 계정 필요

    무슨 일이 있었나

    웹 앱에서 넘어온 개발자가 guideline 5.1.1(v) 위반으로 거절된 사례입니다. 웹에서는 항상 구매를 계정에 연결했습니다. 하지만 iOS에서는 Apple이 구매를 관리하므로 사용자가 가입 없이도 결제할 수 있습니다. 이 앱의 유료 티어는 휴대폰에서만 실행되는 필터를 잠금 해제해 주는데, 티어 잠금 해제와 구매 복원(Restore purchases) 모두 계정 생성을 먼저 강제했습니다.

    해결

    계정 없이 구매하더라도 나중에 선택적으로 가입했을 때 구매 내역을 찾을 수 있도록 구조를 재설계 중입니다. 게시 시점 기준으로 작업이 진행 중이었습니다.

    교훈

    기기에서 실행되는 유료 기능이 서버 신원 정보를 필요로 하지 않는다면, 계정 없이도 구매와 복원이 가능하게 하세요. 계정 가입은 클라우드 백업처럼 정말로 계정이 필요한 기능에만 남겨두세요.

28. 

    Guideline 1.4.2 신체적 상해 iOS 가이드라인 1.4.2

    규제 강화로 이미 출시된 용량 계산기 앱들 퇴출

    무슨 일이 있었나

    한 개발자가 아침에 일어나 보니, 심사 중인 항목이 하나도 없는데도 두 앱이 Guideline 1.4.2 위반으로 플래그가 지정돼 있었습니다. 둘 다 이미 출시된 앱이었습니다. 하나는 독립형 펩타이드 용량 계산기였고, 다른 하나는 같은 계산기가 내장된 트래커였는데, 두 앱은 이 개발자에게 첫 실질적인 수익 성공이었습니다. 같은 분야의 다른 개발자들도 동시에 같은 통지를 받았다고 보고했습니다. 통지에는 펩타이드 용량과 재구성(reconstitution)을 포함해 약물 복용량을 계산하는 앱은 제약사나 병원, 보험사, 약국, 대학 같은 공인된 기관이 게시해야 한다고 적혀 있었습니다.

    해결

    없음. 개발자는 안전 우려를 이해한다고 밝혔고, 두 앱은 이대로 끝이라고 받아들였습니다.

    교훈

    승인은 영구적이지 않습니다. Apple은 규정을 강화하면 이미 출시된 앱도 다시 심사할 수 있습니다. 앱이 복용량을 계산하거나 누군가에게 해가 될 수 있는 건강 가이드를 제공한다면, 빌드 전에 Guideline 1.4를 읽어보고 자격을 갖춘 기관을 통해 게시하거나 계산 기능을 빼는 계획을 세우세요.

29. 

    Guideline 4.3 Spam 및 4.2.6 App Generation Services iOS 가이드라인 4.3 가이드라인 4.2.6

    또다시 스팸 취급받은 오프라인 티켓팅 앱

    무슨 일이 있었나

    한 개발자가 스프레드시트를 티켓팅 및 체크인 시스템으로 바꿔주는 작은 앱을 만들었습니다. 계정도 구독도 없이 완전 오프라인으로 작동하는 앱이었죠. 지난여름 수백 명이 참석한 지역 행사에서 이미 입장 처리를 해냈습니다. 하지만 Apple은 4.3과 4.2.6을 함께 언급한 통지로 또다시 거절했습니다. 스토어에 이미 있는 앱과 중복되거나, 이미 붐비는 카테고리에 편승한 변형 앱이거나, 템플릿 또는 앱 생성 서비스를 사용했을 가능성이 있다는 이유였습니다. 개발자는 같은 기능을 하는 다른 앱을 알지 못한다고 했고, Android 버전은 약 일주일 전부터 출시되어 있었다고 밝혔습니다.

    해결

    게시 시점에도 여전히 거절 상태입니다. 개발자는 어차피 App Store로 수익을 낼 생각은 없었다고 말했습니다.

    교훈

    4.3 검토자는 실제 사용자를 보지 않고, 앱 등록 정보와 몇 분간의 앱 화면만 보고 판단합니다. 앱이 정말 다르다면 리뷰 노트와 첫 스크린샷에서 어떻게 다른지 구체적으로 설명하세요. 실제 사용 사례를 언급하고, 템플릿이나 앱 생성기를 쓰지 않았다고 분명히 밝히세요.

30. 

    가이드라인 5.6.4 앱 품질 Apple Developer Program 가이드라인 5.6.4

    환불률 상승으로 정산 동결

    무슨 일이 있었나

    빠르게 성장 중인 구독형 앱을 운영하던 개발자는 Apple로부터 가이드라인 5.6.4(앱 품질)에 따라 개발자 Code of Conduct를 위반했다는 경고를 받고 잠에서 깼습니다. 통지서는 과도한 환불 요청과 고객 불만을 지적하며, 계정이 해지될 수 있다고 경고했고, 모든 수익금 지급이 중단되고 앱 이전이 비활성화됐다고 밝혔습니다. 환불률은 지난 두 달 동안 거의 두 배로 늘어난 상태였습니다. 개발자가 데이터를 들여다보니 대부분의 환불 요청은 '의도하지 않은 구매'로 분류됐고, 주로 3일 무료 체험이 연간 플랜으로 전환되는 것을 잊은 사용자에게서 나온 것으로 보였습니다. 이 경고는 앱의 대규모 리디자인이 이미 테스트 중일 때 도착했습니다.

    해결

    이 글을 작성할 당시에도 여전히 미해결이었습니다. 개발자는 체험 기간 중 알림을 더 추가하고, 곧 결제될 금액을 더 명확히 표시했으며, 앱 내에서 구독을 관리하고 취소할 수 있는 기능을 추가했습니다. 또한 더 많은 테스트를 거쳐 리디자인을 마무리했고, 그동안 모든 유료 크리에이터 마케팅을 중단했습니다.

    교훈

    Apple은 바이너리만 보는 게 아니라 환불률과 고객 불만도 봅니다. 조용히 연간 결제로 전환되는 무료 체험은 규모가 커지면 '의도하지 않은 구매' 문제로 번질 수 있습니다. 체험 종료 전에 사용자에게 알리고, 실제 가격을 명확히 표시하고, 취소를 쉽게 만드세요. 환불률이 오르고 있다면 Apple이 그러기 훨씬 전에 계정 리스크로 보고 대응해야 합니다.

31. 

    메타데이터 및 인앱 구매 설정 iOS 메타데이터와 IAP

    콘솔에서 삭제되지 않는 이미지 때문에 세 번 리젝됨

    무슨 일이 있었나

    한 개발자가 App Store Connect의 구독에 프로모션 이미지를 추가했다가 실수로 같은 이미지가 두 번 등록되게 했습니다. 그 후로는 이미지를 삭제하거나 교체할 수 없었고, 시도할 때마다 '나중에 다시 시도해 주세요'라는 일반적인 에러만 났습니다. 이 구독 설정 때문에 앱이 세 번 리젝됐습니다. 개발자는 매번 삭제 시도와 에러가 담긴 화면 녹화본을 첨부해 답변했지만, 리뷰어가 무시하는 것처럼 느껴졌습니다. 개발자는 근본 원인이 App Store Connect 자체의 버그라고 생각했습니다.

    해결

    글을 올리는 시점에도 Apple의 수정 없이 여전히 막혀 있습니다.

    교훈

    App Store Connect 자체가 수정을 막는 경우, 거절 스레드의 답변이 문제를 해결할 수 있는 담당자에게 전달되지 않을 수 있습니다. 구독 이미지는 신중하게 한 번만 업로드하고, 콘솔에 문제가 생기면 App Review에 답변하면서 Apple 개발자 지원에도 해당 버그를 별도로 문의하세요.

32. 

    가이드라인 4.3 스팸 iOS 가이드라인 4.3

    체육관 하나를 운영하려 만든 앱이 세 번 거절당한 사례

    무슨 일이 있었나

    한 개발자가 본인의 체육관을 운영하기 위해 iOS 앱을 개발했고, 약 176개의 커밋을 쌓았습니다. Apple은 9월 29일에 앱을 거절했고, 10월 7일에 다시 거절했으며, 10월 13일에는 가이드라인 4.3 스팸 항목으로 거절했습니다. 같은 날 App Review가 보낸 9개의 질문에 모두 답변을 마쳤지만, 6일 뒤인 10월 19일까지 아무 소식도 듣지 못했습니다. App Store Connect 앱 목록에는 같은 계정의 다른 앱 여러 개도 iOS와 macOS 모두에서 동시에 거절 상태로 남아 있었습니다.

    해결

    게시 당시에도 미해결 상태였고, 답변을 보낸 뒤 App Review로부터 회신이 없었습니다.

    교훈

    4.3은 노력이나 커밋 수를 평가하지 않습니다. 특정 비즈니스 전용으로 만든 앱이라면, 검색에는 노출되지 않지만 직접 링크가 있는 사람은 누구나 접근할 수 있는 unlisted 앱으로 배포할 수 있습니다. Custom App 배포는 지정된 조직만 앱을 사용할 수 있도록 제한합니다. 필요한 접근 제어에 맞는 옵션을 선택하세요. 공개 등록을 원한다면 첫 화면, 스크린샷, 심사 메모에서 기존 앱과 무엇이 다른지 분명히 보여주세요.

33. 

    가이드라인 5.6 Developer Code of Conduct 및 2.5.19 숨겨진 기능 iOS Guideline 5.6 개발자 Code 강령 Guideline 2.5.19 숨겨진 기능

    테스트용 스위치를 남겨둔 탓에 사기로 거절

    무슨 일이 있었나

    2026년 9월, 한 개발자가 가이드라인 5.6 Developer Code of Conduct 위반으로 iOS 앱 심사에서 거절당했습니다. Apple은 리뷰 중 의도적으로 숨긴 것으로 보이는 기능 등 사기와 연관된 행동 패턴을 발견했다고 밝혔습니다. 개발자가 추적해 보니 원인은 릴리스 빌드에 남겨둔 세 가지 테스트용 스위치였습니다. 스토어 스크린샷 촬영 모드, 느린 entitlement 확인을 시뮬레이션하는 스위치, 모의 구매를 활성화하는 스위치였습니다. 일반 App Store 버전 사용자는 어느 것도 접근할 수 없었습니다. Apple은 10월 16일 App Review Guidelines 업데이트에서 숨겨졌거나 휴면 상태이거나 문서화되지 않은 기능을 별도 가이드라인 2.5.19로 만들었고, 이를 위반하면 개발자 계정 전체가 위험해질 수 있다고 밝혔습니다.

    해결

    이제 해당 개발자는 업로드 전 모든 릴리스 아카이브 내부의 문자열을 검사합니다. 해당 빌드가 나중에 승인되었는지 여부는 밝혀지지 않았습니다.

    교훈

    런타임 체크로 막는 대신 예를 들어 DEBUG 플래그를 사용해, 컴파일 시점에 테스트 전용 code를 릴리스 빌드에서 제외하세요. 아카이브된 바이너리에 실제로 포함되는 항목을 확인하고, App Review 노트에 남길 스위치가 있으면 나열하세요.

34. 

    2.1 필요한 정보 iOS 가이드라인 2.1

    Apple이 앱의 대상 사용자를 파악할 때까지 심사 일시 중단

    무슨 일이 있었나

    한 개발자가 iPad 앱 1.0 버전을 제출했지만 가이드라인 2.1 Information Needed 사유로 심사가 중단되었습니다. 크래시 리포트도, 기능 오류도, 바이너리 수정 요청도 없었습니다. Apple은 심사를 재개하기 전에 단 하나의 질문에 대한 상세한 답변만 요구했습니다. 바로 '누가 이 앱을 사용할 것인가'였습니다.

    해결

    Apple은 심사를 계속하기 전에 타겟 사용자에 대한 설명을 요구했습니다.

    교훈

    타겟 오디언스와 유즈케이스를 나중에 채울 마케팅 문구가 아니라 심사 입력값으로 취급하세요. 첫 버전을 제출하기 전에 타겟 사용자에 대한 명확한 답변을 작성하세요.

35. 

    4.3 디자인 / 스팸 iOS 가이드라인 4.3

    포화된 사운드 앱 카테고리에서 차별성이 부족함

    무슨 일이 있었나

    한 엔터테인먼트 사운드 앱이 Guideline 4.3(b)로 거절됐습니다. 팀은 추가 기능으로 차별화된다고 봤지만, Apple은 스토어에 이미 유사 앱이 충분하다며 포화된 카테고리의 중복 콘텐츠로 처리했습니다.

    해결

    포화된 카테고리에서 차별성 부족으로 4.3(b) 거절

    교훈

    Apple이 포화 상태라고 부르는 카테고리에서는 심사 첫 1분 안에 참신함이 분명히 드러나야 합니다. 리뷰어가 이미 여러 번 본 기믹이 아니라, 무엇이 독특한지를 앞세우세요.

36. 

    메타데이터 및 스토어 등록 정보 문구 iOS 메타데이터와 IAP 끝없는 심사

    출시 주간을 잡아먹은 메타데이터 루프

    무슨 일이 있었나

    소비자용 생산성 팀은 문제없는 빌드를 배포한 뒤 메타데이터 지적 사항에 대응하느라 9일 넘게 씨름했습니다. 재제출할 때마다 이전 지적은 해결했지만, 다음 답변은 또 다른 문구나 스크린샷, 설명을 문제 삼았습니다. 출시, 보도, 유료 유입 계획이 심사 중인 문구를 기다리는 동안 code는 전혀 바뀌지 않았습니다.

    해결

    바이너리 변경 없이 스크린샷, 부제, 심사 메모만 다시 작성한 끝에 승인되었습니다.

    교훈

    출시일을 정하기 전에 스토어 등록 문구, 스크린샷, 심사 메모를 한 번에 확정하세요. 바이너리가 그대로여도 메타데이터 거절은 쌓일 수 있습니다.

37. 

    수출 규정 준수(App Store Connect) iOS 메타데이터와 IAP

    승인 후 또 하나의 규정 준수 질문으로 막힘

    무슨 일이 있었나

    B2B 대시보드 컴패니언 빌드가 승인되었지만, 수출 규제 관련 질문에 모두 답했다고 생각한 팀 앞에 다시 컴플라이언스 프롬프트가 나타나며 출시가 막혔습니다. 출시 담당자는 롤아웃을 중단하고 법무 검토 문구를 준비하여 App Store Connect의 답변을 업데이트했습니다. 고객들은 앱 출시 전 공지사항을 먼저 보게 되었고, 담당자는 다음 리뷰 패스를 기다려야 했습니다.

    해결

    수출 규제 관련 질문에 다시 답변하고 다음 리뷰 패스를 거친 후 출시되었습니다.

    교훈

    수출 규제 준수를 일회성 체크박스가 아닌 출시 게이트로 취급하세요. 출시일을 공지하기 전에 App Store Connect가 출시 가능한 상태인지 반드시 확인해야 합니다.

38. 

    Google Play 권한 및 정책 리뷰 Google Play 메타데이터와 IAP 끝없는 심사

    권한 정책 검토로 인한 시간 낭비

    무슨 일이 있었나

    현장 운영용 Android 앱에서 한 화면에만 쓰인 제한적인 권한 때문에 광범위한 정책 검토가 시작됐습니다. 팀은 기능을 문서화하고 검토자용 안내를 추가하고 데모 경로까지 녹화했지만, 결국 13일 만에 고객이 막히지 않도록 메인 릴리스에서 해당 권한을 제거해야 했습니다.

    해결

    권한을 제거하고 새 데모를 녹화한 뒤 스토어 선언을 다시 작성한 끝에 승인되었습니다.

    교훈

    민감한 권한은 우선 배포할 수 있는 최소 범위로 한정하세요. 권한 하나만으로도 Google Play의 전체 정책 검토로 이어질 수 있습니다.

39. 

    Google Play 심사 대기열 타이밍 Google Play 끝없는 심사

    정책 대기열에 갇힌 핫픽스

    무슨 일이 있었나

    한 이커머스 팀은 결제 버그를 빠르게 고칠 모바일 수정이 필요했지만, 스토어 출시 버전이 최악의 타이밍에 6일 동안 심사에 묶여 있었습니다. 상태는 계속 대기 중인데 지원 티켓은 쌓여만 갔습니다. 팀은 먼저 서버 측에서 완화 조치를 했고, 긴급 상황이 주말을 다 태운 뒤에야 바이너리 승인이 도착하는 걸 지켜봐야 했습니다.

    해결

    팀이 이미 다른 방식으로 문제를 해결한 뒤에야 네이티브 스토어 수정안이 승인되었습니다.

    교훈

    스토어 리뷰는 장애 대응 채널이 아닙니다. 바이너리가 심사 대기 중일 때를 대비해 긴급 프로덕션 버그를 해결할 별도의 대응 경로를 확보하세요.

40. 

    가이드라인 3.1.1 인앱 결제 및 3.1.3(f) 무료 단독 앱 iOS 가이드라인 3.1.1 가이드라인 3.1.3

    체험판 종료로 거절된 컴패니언 앱

    무슨 일이 있었나

    한 개발자가 유료 웹 기반 이메일 서비스를 위한 무료 iOS 컴패니언 앱을 출시했습니다. 앱 안에서는 아무것도 판매하지 않았습니다. 개발자는 App Review에 무료 독립형 컴패니언 앱에 대한 3.1.3(f) 예외를 근거로 제시했지만, 앱은 네 번 거절되었습니다. 이의를 제기했으나 App Review Board는 거절 결정을 유지했습니다. 그 이유는 서비스가 14일 무료 체험을 제공하므로 iOS 사용자에게는 14일 후 앱이 더 이상 유용하지 않아 진정한 독립형 경험이 아니라는 것이었습니다. Apple은 두 가지 해결책을 제시했습니다. 앱에 자체적으로 설 수 있을 만큼 충분한 무료 콘텐츠와 기능을 제공하거나, App Store 고객이 In-App Purchase로 서비스를 구매할 수 있게 하는 것입니다. 개발자는 잘 알려진 이메일 앱도 14일 제한을 두고 비슷하게 운영하는 것 같다고 지적했습니다.

    해결

    이 글을 작성할 당시에도 문제는 해결되지 않았습니다. 이의 신청은 기각되었고, 개발자는 최소한의 무료 티어를 제공할지 아니면 In-App Purchase를 추가할지 고민 중이었습니다.

    교훈

    3.1.3(f) 컴패니언 예외는 좁게 해석됩니다. 웹 서비스에 기간 한정 체험판이 있다면, Apple은 체험판이 끝난 뒤 앱을 위장된 페이월로 볼 수 있습니다. 제출 전에 체험판 종료 후에도 사용자가 앱에서 무료로 할 수 있는 일이 무엇인지 정하거나, In-App Purchase를 계획하세요. 비슷하게 하는 것처럼 보이는 다른 앱을 언급하는 것만으로는 이의 신청이 받아들여질 가능성은 거의 없습니다.

41. 

    가이드라인 3.1.1 In-App Purchase iOS 가이드라인 3.1.1

    App Store 외부 결제로 간주되는 API 키 직접 입력 방식

    무슨 일이 있었나

    iPhone용 AI 어시스턴트를 개발하던 한 1인 개발자는 사용자가 대규모 클라우드 모델을 실행할 수 있도록 제3자 모델 애그리게이터의 API 키를 직접 입력하는 기능을 구현했습니다. 하지만 네 번째 리뷰 단계에서 App Review는 해당 기능을 App Store 외부에서 기능을 결제하는 수단으로 간주하여 가이드라인 3.1.1 위반으로 앱을 거절했습니다. 개발자도 거절 사유를 이해했습니다. 외부에서 구매한 키가 앱 내 유료 기능을 활성화하려면 해당 판매자가 자체 iOS 앱에서 In-App Purchase를 제공해야 하는데, 이 업체는 iOS 앱이 없었기 때문입니다. 개발자는 이의 신청을 하지 않았습니다.

    해결

    개발자는 키 직접 입력 기능을 완전히 제거하고, 모델을 기기 내에서만 실행하도록 다음 버전을 다시 빌드했습니다. 그리고 나중에 클라우드 모델을 In-App Purchase로 판매하는 인앱 크레딧 방식으로 다시 도입할 계획을 세웠습니다. 이 재심사 결과는 이 글을 쓰는 시점에서는 알 수 없습니다.

    교훈

    앱의 유료 기능이 외부에서 구매한 인증 정보로 활성화되는 구조라면, 빌드하기 전에 해당 판매자가 자체 iOS 앱에서 In-App Purchase를 제공하는지 확인하세요. 그렇지 않다면 자체적인 In-App Purchase 경로를 설계하거나, 결제 없이도 작동하는 모드를 계획해야 합니다.

42. 

    가이드라인 1.2 iOS 가이드라인 1.2

    승자를 가린다는 이유로 거절된 코디 비교 앱

    무슨 일이 있었나

    1인 개발자가 두 가지 코디를 비교하는 AI 앱을 출시했습니다. 비교 후 앱은 한쪽 코디가 이겼다고 표시했죠. 하지만 App Review는 이 결과를 옷이 아니라 사람의 순위를 매기는 것으로 해석해 가이드라인 1.2에 따라 거절했습니다. 개발자도 이 우려에 동의했습니다.

    해결

    개발자는 '승자' 문구와 승자 배지, 어느 쪽 옵션이든 더 높은 점수나 강조 색상을 모두 제거했습니다. 이제 두 코디는 시각적 비중이 같고, 각자 피드백을 받으며, 사용자가 직접 판단합니다. 수정된 빌드의 승인 여부는 공유되지 않았습니다.

    교훈

    Apple은 화면의 기능뿐 아니라 느낌까지 심사합니다. 앱이 사람의 외모와 관련된 항목에 점수를 매긴다면, 순위 없이 피드백을 제시하고 가장 엄격한 해석을 전제하세요.

43. 

    Kids 카테고리, 가이드라인 3.1.2, 개인정보 보호 질문 iOS 키즈 카테고리 가이드라인 3.1.2 끝없는 심사

    한 달 넘게 거절당하고 여전히 기다리는 어린이 동화 앱

    무슨 일이 있었나

    1인 개발자가 4~10세 아이들을 위해 이야기를 듣다가 궁금한 점이 생기면 일시 정지하고 질문할 수 있는 스토리 앱을 만들었습니다. 이미 Android에서는 몇 주 동안 서비스 중이었죠. 2026년 9월 19일 App Store에 앱을 제출했지만, 여러 차례 거절과 재제출을 반복했음에도 한 달이 지난 지금까지 승인이 나지 않았습니다. 최근 심사에서 Apple은 두 가지를 요구했습니다. 첫째, 앱에서 주간, 월간, 연간 구독을 판매하므로 App Store 페이지에 정상 작동하는 이용 약관(Terms of Use) 링크가 있어야 한다는 것이었습니다. 둘째, 앱이 Kids 카테고리에 해당하므로 제3자 분석 도구, 제3자 광고 사용 여부, 데이터의 제3자 공유 및 저장 위치, 그리고 기타 사용자 또는 기기 데이터의 수집 여부와 목적에 관한 네 가지 질문에 답변하기 전까지는 심사를 진행할 수 없다는 것이었습니다.

    해결

    개발자는 두 가지 문제를 모두 해결하고 다시 제출했습니다. 이 글을 쓰는 시점에도 결과는 아직 대기 중입니다.

    교훈

    키즈, 건강, 금융 또는 교육 앱을 개발한다면, 현지 개인정보 보호법과 스토어에서 무엇을 요구할지 미리 파악해야 합니다. 예를 들어 아동 데이터를 수집하기 전 부모의 동의가 필요한지 확인하고, 첫 제출 전에 이용 약관 링크와 데이터 관련 답변을 문서로 준비해 두세요.

44. 

    가이드라인 5.1.1(v) 및 3.1.2 iOS 가이드라인 5.1.1 가이드라인 3.1.2

    로그인, 결제, 계정 삭제 프로세스 문제로 버전 1.0 거절

    무슨 일이 있었나

    한 개발자의 버전 1.0이 세 가지 문제로 동시에 거절되었습니다. 앱의 아이디어 자체와는 무관한 문제들이었죠. Sign in with Apple을 사용했음에도 앱이 사용자에게 이미 제공된 이름을 다시 요구했고, 계정 삭제는 앱 내부에서 시작할 수 있어야 했습니다. 또한 구독 및 지원 화면에는 가격, 갱신 조건, 이용 약관 링크가 표시되어야 했습니다. 개발자는 이 세 가지 문제가 모두 로그인, 구매, 삭제와 직결되어 있다는 점을 깨달았습니다.

    해결

    명시되지 않음

    교훈

    첫 제출 전, 리뷰어의 관점에서 로그인, 결제, 계정 삭제 프로세스를 직접 점검하세요. 이 세 가지 흐름이 첫 심사 거절의 가장 흔한 원인입니다.

45. 

    Guideline 5.2.3 오디오/비디오 다운로드 iOS Guideline 5.2.3 오디오/비디오 다운로드

    제3자 오디오 권리 문제로 중단된 빈티지 인터넷 라디오

    무슨 일이 있었나

    빈티지 스타일의 1인 개발자 인터넷 라디오 앱(5번째 빌드, v1.0)이 가이드라인 5.2.3에 따라 거절되었습니다. 이 가이드라인은 제3자 소스에서 오디오나 비디오를 재생 또는 다운로드하는 앱에 적용되며, 개발자가 해당 콘텐츠에 대한 권리를 보유하고 있다는 증명을 요구합니다. 개발자는 다음 날 Resolution Center를 통해 콘텐츠 권리에 대한 소명 자료를 제출했습니다.

    해결

    게시 시점 기준으로 결과는 아직 알 수 없음.

    교훈

    소유하지 않은 스테이션이나 미디어를 스트리밍하는 앱이라면, 권한 증명서를 확보하거나 앱 내 재생을 명시적으로 허용하는 소스를 사용하세요. 그리고 제출 전 리뷰 노트에 관련 문서를 첨부해야 합니다.

46. 

    가이드라인 4.3 (스팸) iOS 가이드라인 4.3

    6번의 거절, 4.3 스팸 판정, 그리고 통화를 위한 2주간의 기다림

    무슨 일이 있었나

    한 1인 개발자가 사교 모임에서 대화 주제로 쓰기 좋은 첫 앱을 만드는 데 수개월을 보냈습니다. 하지만 앱은 6번이나 거절당했고, 마지막에는 이미 스토어에 있는 유사 앱들보다 더 많은 가치를 제공한다고 생각했음에도 불구하고 가이드라인 4.3(스팸) 사유로 거절되었습니다. 개발자는 App Review 측에 1:1 통화를 요청했습니다. 일주일이 지나도록 답장이 없다가, 4.3 거절 후 약 2주가 지나서야 마침내 통화가 이루어졌습니다. 개발자는 통화 후, 현재 4.3 가이드라인이 정성이 부족하거나 AI로 생성된 클론 앱들을 걸러내는 용도로 사용되고 있다는 인상을 받았으며, 본인의 앱은 결코 그렇지 않다고 강조했습니다.

    해결

    개발자는 항소를 제기했습니다. 이 글을 쓰는 시점에도 항소는 검토 중입니다.

    교훈

    경쟁이 치열한 카테고리에서는 리뷰어가 스크린샷, 설명, 그리고 첫 세션을 보고 판단합니다. 기존 앱들과의 차별점을 명확히 보여주고, App Review 통화 요청은 미리 하세요. 통화 일정을 잡는 데 일주일 이상 걸릴 수 있기 때문입니다.

47. 

    계약 미수락 (가이드라인 미표기) iOS 등록 및 계정

    대기열에서 일주일, 미서명 계약 때문에 거절, 그리고 또 일주일

    무슨 일이 있었나

    앱이 리뷰를 위해 약 일주일을 기다린 뒤, 앱 내부 문제와는 무관한 이유로 거절되었습니다. 계정이 App Store Connect에 새로 게시된 계약을 아직 수락하지 않은 것이 원인이었습니다. 개발자가 계약을 수락하고 다시 제출하자, 제출 건은 다시 대기열로 들어가 약 일주일이 더 걸렸습니다. 개발자 지원팀은 모든 게 순조롭게 진행 중이라는 답변만 했습니다.

    해결

    이 글을 쓰는 시점에도 여전히 리뷰 대기 중입니다.

    교훈

    제출할 때마다 App Store Connect에서 수락 대기 중인 계약이 있는지 확인하세요. 클릭 한 번 놓치면 리뷰 대기열을 처음부터 다시 거쳐야 할 수 있습니다.

48. 

    심사 중 크래시 발생 (가이드라인 미명시) macOS가 가이드라인 2.1

    개발자가 설치하지 않은 macOS 버전에서의 크래시로 거절됨

    무슨 일이 있었나

    개발자가 아직 사용하지 않고 메인 기기에 설치하고 싶지도 않았던 macOS 27 버전에서 크래시가 발생해 Mac 앱이 거절되었습니다. 크래시 재현 방법을 찾던 중, Apple의 Virtualization framework를 사용하면 Apple silicon에서 macOS 가상 머신을 무료로 실행할 수 있다는 것을 발견하고, 새 버전을 테스트하기 위해 가상 머신을 세팅했습니다.

    해결

    가상 머신에서 크래시를 재현하는 것 외에는 명시된 내용 없음.

    교훈

    App Review는 최신 OS에서 테스트를 진행합니다. 메인 기기를 업그레이드하지 않고도 심사 중 발생하는 크래시를 재현할 수 있도록 최신 macOS 가상 머신을 준비해 두세요.

49. 

    심사 지연 (가이드라인 미제시) iOS 끝없는 심사

    심사 재촉 요청 2회 후에도 12일째 심사 대기 중

    무슨 일이 있었나

    이미 스토어에서 앱을 승인받은 적이 있는 개발자가 구독 5개로 구성된 구독 그룹과 함께 신규 앱의 버전 1.0을 제출했습니다. 보통 48시간 이내라는 예상과 달리 12일이 지나도 여전히 Waiting for Review 상태였습니다. expedite 심사를 두 번 요청하고 고객 지원에 문의했지만 답변을 받지 못했으며, App Review 예약도 시도했지만 거절당했습니다.

    해결

    이 글을 쓰는 시점에도 여전히 대기 중입니다.

    교훈

    평균 48시간이라는 수치를 믿고 출시일을 잡지 마세요. 구독이 포함된 첫 버전이라면 몇 주의 여유를 두고, expedite 요청과 예약은 보장이 아니라 가능성일 뿐이라고 생각하세요.

50. 

    권한 prompt + 스크린샷 메타데이터 (흔히 5.1.1과 2.3.7로 인용되는 규칙) iOS 가이드라인 5.1.1 가이드라인 2.3.7

    출시 주간: 커스텀 Allow 화면과 스크린샷 속 가격

    무슨 일이 있었나

    출시 주간에 앱이 두 번 거절되었습니다. 첫 번째는 시스템 권한 prompt 바로 직전에 자체 Allow 버튼이 있는 화면을 보여준 것이었는데, Apple은 이를 허용하지 않습니다. 이를 수정한 뒤 두 번째 거절 사유는 App Store 스크린샷에 가격이 노출된 것이었습니다. 두 수정 모두 사소했지만, 다시 제출할 때마다 리뷰 대기열에서 약 하루가 걸렸습니다.

    해결

    개발자는 두 문제를 모두 해결했고, 이제는 재발하지 않도록 두 규칙을 프로젝트에 적어 두고 있습니다.

    교훈

    pre-permission 화면으로 접근 권한이 필요한 이유를 설명할 수는 있지만, Allow 선택은 시스템 prompt에만 맡기세요. 스크린샷에는 가격을 넣지 말고, 매 제출 전에 짧은 체크리스트를 점검하세요.

51. 

    심사 지연 (가이드라인 미제시) iOS 끝없는 심사

    심사에서 10일간 정체되다가, 재제출 후 30분 만에 승인됨

    무슨 일이 있었나

    앱이 아무런 변화 없이 10일 넘게 심사 상태에 머물러 있었습니다. 개발자가 앱을 재제출했습니다.

    해결

    재제출 후 약 30분 만에 승인되었습니다.

    교훈

    심사가 지연된다고 해서 반드시 앱에 문제가 있는 것은 아닙니다. 평소보다 심사가 너무 길어진다면 재제출이나 빠른 심사(expedited review) 요청을 시도해 볼 가치가 있지만, 두 방법 모두 확실한 해결책은 아닙니다.

52. 

    4.3(a) 스팸 iOS 가이드라인 4.3

    같은 1분에 템플릿 앱 7개가 4.3으로 거절됨

    무슨 일이 있었나

    한 소규모 팀이 동일한 템플릿으로 빌드한 앱 7개를 같은 주에 심사에 제출했습니다. 그러자 이전에 한 번도 거절된 적 없던 앱 2개를 포함해 7개 모두 같은 1분에 똑같은 4.3(a) 스팸 거절을 받았습니다. 팀은 Apple이 각 앱이 아니라 배치 전체를 기준으로 판단했다고 결론 내렸습니다.

    해결

    이제 팀은 앱을 한 번에 하나씩 제출합니다.

    교훈

    codebase를 공유하는 앱들이 한꺼번에 제출되면 스팸 패턴으로 보일 수 있습니다. 제출 간격을 두고 각 앱이 기능, 디자인, 메타데이터에서 확실히 구분되게 하세요.

53. 

    가이드라인 2.3.6 iOS 가이드라인 2.3.6

    Connect 설정이 이미 일치했는데도 발생한 연령 등급 거절

    무슨 일이 있었나

    한 앱이 연령 등급 때문에 거절됐습니다. 개발자가 App Store Connect에서 연령 등급 설문지를 열어 보니, 모든 답변이 이미 거절 메시지에서 요구한 내용과 일치했습니다.

    해결

    개발자는 Connect에서 아무것도 바꾸지 않고, 설정이 이미 일치한다고 리뷰어에게 답변한 뒤 다시 제출했습니다. 앱은 몇 시간 뒤 승인됐습니다.

    교훈

    2.3.6 관련 메모가 현재 설정에 대해 잘못된 내용일 수 있습니다. 설정을 변경하기 전에 App Store Connect를 확인하고, 이미 일치한다면 수정 방법을 짐작하지 말고 답변에서 분명히 밝히세요.

54. 

    Guideline 2.1 정보 필요 iOS 가이드라인 2.1

    심사 이력 부족: 기기 녹화 및 유료 기능 시연

    무슨 일이 있었나

    Google Play 심사를 이미 통과한 앱이 Guideline 2.1 정보 필요 사유로 반려됐습니다. Apple은 개발자 계정의 심사 이력이 부족하다며 실제 기기 화면 녹화, 유료 기능 시연, 앱이 하는 일과 의존하는 외부 서비스에 대한 서면 설명을 요구했습니다.

    해결

    해당 개발자는 게시 시점에 녹화 영상과 답변을 준비 중이었으며, 최종 결과는 알 수 없습니다.

    교훈

    Google Play 심사 통과는 Apple 심사와 아무 관련이 없습니다. 개발자 계정이 신규이거나 제출 이력이 적다면, 제출 전에 실제 기기 녹화, 유료 기능 시연, 서드파티 서비스 목록을 준비하세요.

55. 

    가이드라인 2.1, 2.3.2, 5.2.3 iOS 가이드라인 2.1 가이드라인 2.3.2 Guideline 5.2.3 오디오/비디오 다운로드 끝없는 심사

    첫 제출: 한 달에 걸쳐 2.1 → 2.3.2 → 5.2.3

    무슨 일이 있었나

    한 개발자의 첫 앱 제출은 6일을 기다린 끝에 2.1 가이드라인으로 거절되었습니다. 당일 바로 답변을 보냈지만, 12일 후 이번에는 2.3.2 가이드라인으로 다시 거절되었습니다. 재제출 후 9일이 지나자 5.2.3 가이드라인으로 또 거절되었습니다. 다시 당일 답변을 보냈지만, 이틀이 지난 지금까지도 계속 기다리는 중입니다. 매번 이전과는 다른 가이드라인이 거절 사유로 나왔습니다.

    해결

    첫 제출 후 한 달이 넘도록 여전히 심사 대기 중입니다.

    교훈

    매 심사 라운드마다 새로운 가이드라인이 드러날 수 있고, 그때마다 일주일 이상이 걸릴 수 있습니다. 첫 제출 전에는 완성도 규칙(2.1)만이 아니라 메타데이터 규칙(2.3)과 해당되는 콘텐츠 권리 규칙(5.2)까지 읽고, 한 번의 빌드에서 찾을 수 있는 모든 문제를 수정하세요.

56. 

    가이드라인 4.2 최소 기능 요건 iOS 가이드라인 4.2

    4.2 항목에 따라 주로 '도서'로 분류되어 반려된 기도 앱

    무슨 일이 있었나

    한 종교적인 기도·묵상 앱이 주로 책이라는 이유로 4.2에 따라 반려되었습니다. 개발자는 캘린더, 기도 횟수 트래커, 명상 타이머, 공유 가능한 컬렉션, Home Screen 위젯, 음성 검색 등 인터랙티브 기능을 포함한다고 설명했습니다.

    해결

    명시되지 않음

    교훈

    리뷰어가 앱을 정적 콘텐츠로만 보면, 리뷰 첫 몇 분 동안 인터랙티브 기능이 보이지 않을 수 있습니다. 첫 화면과 스크린샷에 해당 기능을 보여주고, 리뷰 노트에 각 기능에 접근하는 단계를 적어 두세요.

57. 

    가이드라인 2.3.10 iOS 가이드라인 2.3.10

    대기 13일, Android 관련 이슈로 7분 만에 거절

    무슨 일이 있었나

    한 개발자는 리뷰 대기열에서 13일을 기다리며 매일 App Store Connect와 이메일을 확인하고 지원 요청을 두 번 제출했습니다. 리뷰가 시작된 직후, App Store 설명에 제품이 iPhone 또는 Android의 모든 브라우저에서 작동한다고 적혀 있다는 이유로 약 7분 만에 거절됐습니다.

    해결

    다른 플랫폼 언급을 한 줄만 수정해 다시 제출했습니다. 결과는 아직 보고되지 않았습니다.

    교훈

    Apple은 다른 모바일 플랫폼을 언급하는 메타데이터를 거절합니다. 제출 전 설명, 스크린샷, 홍보 문구에 경쟁 플랫폼 이름이 있는지 확인하세요. 사소한 문구 하나 때문에 대기 기간을 통째로 날릴 수 있습니다.

58. 

    가이드라인 5 (Legal) iOS Guideline 5 법적 사항

    중국 스토어 메타데이터의 OpenAI 언급으로 인한 가이드라인 5 거절

    무슨 일이 있었나

    한 AI 앱이 메타데이터에 OpenAI를 언급했다는 이유로 가이드라인 5(Legal)에서 거절되었습니다. Apple은 중국에서 생성형 AI와 딥 합성(deep synthesis) 서비스에는 정부 라이선스가 필요하고, ChatGPT에는 그 허가가 없다고 설명했습니다. 개발자는 중국 스토어프런트에서 AI 기능을 제거하고 이름, 부제, 홍보 문구, 설명, 스크린샷에서 OpenAI 또는 ChatGPT 언급을 모두 삭제하거나, 중국 본토 배포를 중단해야 합니다.

    해결

    개발자는 해당 서비스를 명시한 앱을 제출하기 전에 Availability에서 중국 본토 스토어프런트를 선택 해제할 것을 권장합니다. 이렇게 하면 리뷰 사이클을 한 번 줄일 수 있습니다.

    교훈

    생성형 AI 제공업체를 기반으로 앱을 만든다면 중국 출시 여부를 미리 정하세요. 거절은 code만의 문제가 아니라 스토어프런트와 메타데이터 때문입니다.

59. 

    가이드라인 3.1.2 iOS 가이드라인 3.1.2

    앱 내에는 이용약관 링크가 있지만 설명에는 누락됨

    무슨 일이 있었나

    구독 앱의 첫 버전이 제출 이틀 후 거절됐습니다. App Store 설명에 이용약관 링크가 없었기 때문입니다. 앱 내 페이월과 설정에는 이미 있었지만, 해당 메타데이터 필드에만 없었습니다.

    해결

    수정은 5분이면 끝났지만, 다시 제출한 빌드는 10일 넘게 '심사 대기 중' 상태로 아무 응답 없이 머물렀습니다. 아직 보고된 사례는 없습니다.

    교훈

    자동 갱신 구독의 경우, 간단한 수정이라도 두 번째 심사에서 오래 기다릴 수 있으므로 첫 제출 전에 App Store 메타데이터와 앱 안 모두에 이용약관(EULA) 및 개인정보 처리방침 링크를 넣으세요.

60. 

    계정 해지 iOS 계정 해지

    3.2(f) 조항에 따른 계정 해지, 미지급 수익금 미정산

    무슨 일이 있었나

    한 개발자의 Apple Developer 계정이 Developer Program License Agreement의 3.2(f) 조항에 따라 해지됐습니다. 거의 3개월이 지나도록 미지급 수익금은 여전히 지급되지 않았고, 해당 개발자는 다른 개발자들에게 계정 해지 후 보류된 수익금을 받아본 적이 있는지 묻고 있었습니다.

    해결

    보고된 사례 없음.

    교훈

    계정 해지는 미래 매출뿐 아니라 이미 벌어들인 수익까지 동결시킬 수 있습니다. 현금 런웨이와 정산 기록을 유지하고, 사용자에게 직접 닿는 자체 채널을 확보해 계정 결정 하나로 비즈니스가 끝나지 않게 하세요.

61. 

    가이드라인 2.1 및 5.1.2 iOS 가이드라인 2.1 가이드라인 5.1.2 끝없는 심사

    25일 심사 후, 2.1과 5.1.2 동시 지적

    무슨 일이 있었나

    한 인디 개발자가 iOS 앱의 첫 버전인 1.0을 제출했습니다. 약 17일이 지나도 빌드는 여전히 심사 중이었고, 총 25일 정도가 흐른 뒤 App Review는 가이드라인 2.1(App Completeness) 및 5.1.2(Data Use and Sharing) 위반으로 앱을 거절했습니다. 이후 App Store Connect은 거절된 버전이 수정될 때까지 제출된 다른 모든 항목의 진행을 차단했습니다. 개발자에 따르면 지적된 문제들은 수정하기 쉬웠지만, 정말 고통스러운 점은 재제출 후 다시 2~3주를 기다려야 한다는 사실이었습니다.

    해결

    개발자는 두 문제를 모두 수정하여 재제출했습니다. 하지만 다음 심사 결과는 보고되지 않았습니다.

    교훈

    심사 대기열이 이렇게 길어지면, 거절 한 번에 몇 주가 허비될 수 있습니다. 제출 전, 끊김 없는 플로우, 작동하는 데모 계정, 더 이상 placeholder가 없는 상태로 전체 완성도를 점검하세요. 또한 개인정보 보호 답변과 SDK 데이터 공유 설정이 실제 앱 동작과 일치하는지 반드시 확인해야 합니다.

62. 

    가이드라인 2.3.1(a) iOS 가이드라인 2.3.1 메타데이터와 IAP

    실제 현금 스테이킹이 2.3.1(a)에 따라 숨겨진 항목으로 간주되어 거절됨

    무슨 일이 있었나

    한 개발자가 사용자가 목표를 달성하지 못하면 돈을 잃게 되는 습관 및 규율 트래커를 개발했습니다. 2026년 10월 중순, App Review는 메타데이터에 설명되지 않은 금전적 스테이킹 및 몰수 기능이 포함되어 있다는 이유로 가이드라인 2.3.1(a)에 따라 앱을 거절했습니다. 또한 해당 통지서에는 이러한 문제가 반복될 경우 심사 시간이 길어질 수 있으며, 규칙을 계속 위반하는 계정은 Apple Developer Program에서 삭제될 수 있다는 Extended Review 경고도 포함되었습니다. 이 앱은 총 5번의 거절을 겪었으며, 그중 하나는 iPad 심사 중 발생한 크래시 때문이었습니다. AI 코딩 도구로 앱을 개발했던 이 개발자는 다음과 같은 교훈을 정리했습니다: 가이드라인을 숙지할 것, 메타데이터를 앱과 일치시킬 것, 기능이나 데이터 수집을 절대 숨기지 말 것, 생성된 code를 검토할 것, 그리고 다양한 기기에서 테스트할 것.

    해결

    5번의 거절 후 앱을 재작업했다는 내용 외에는 명시되지 않았습니다. 승인 여부는 보고되지 않았습니다.

    교훈

    스테이킹이나 몰수를 포함하여 실제 돈이 움직이는 모든 기능은 설명 및 App Review 노트에 명확히 기재해야 합니다. 심사위원이 iPad를 사용하므로, iPhone을 타겟으로 하더라도 iPad에서 테스트하세요.

63. 

    가이드라인 4.3(a) iOS 가이드라인 4.3

    새로운 기능, 새로운 스크린샷, 그리고 경고와 함께 3분 만에 겪은 4.3(a) 거절

    무슨 일이 있었나

    앱을 처음부터 구축하는 데 약 두 달을 쓴 개발자는 이미 4.3 스팸으로 거절당한 상태였습니다. 다음 제출을 위해 새 기능을 추가하고, 모든 스크린샷을 교체하고, 더 많은 기기 크기에 맞게 앱을 최적화한 뒤 리뷰 노트와 프리미엄 테스트 계정을 함께 첨부해 다시 제출했습니다. 앱이 리뷰에 들어간 지 3분 만에 다시 Guideline 4.3(a)로 거절됐습니다. 이번에는 메시지 끝에 연장 리뷰 통지가 붙어 있었습니다. 이런 문제가 있는 제출이 반복되면 리뷰 시간이 길어지고, 이런 앱을 계속 제출하는 계정은 Apple Developer Program에서 제거될 수 있다는 내용이었습니다. 또 한 번 재제출했다가 계정 전체를 잃을까 봐 두려워진 개발자는 앱을 포기할지, App Review에 통화를 요청할지 고민하고 있었습니다.

    해결

    게시 시점 기준 미해결 상태입니다.

    교훈

    연장 리뷰 통지가 나오면 성급한 재제출이 가장 위험한 선택입니다. 먼저 App Review에 통화를 요청하고, 무엇을 너무 유사하다고 보는지 확인한 뒤에만 재제출하세요.

64. 

    가이드라인 4.3(b) iOS 가이드라인 4.3

    3분 만에 거절, 이어진 3주간의 어필 무응답

    무슨 일이 있었나

    한 개발자의 앱이 심사 단계에 들어간 지 약 3분 만에 가이드라인 4.3(b) 위반으로 거절되었습니다. 그들은 App Review Board에 이의를 제기했습니다. 하지만 3주가 지나도록 아무런 답변도, 상태 변화도, 메시지도 받지 못했습니다.

    해결

    미해결.

    교훈

    이의 제기는 피드백 없이 몇 주 동안 방치될 수 있습니다. 이의 제기 결과만 기다리며 시간을 허비하지 않도록, 앱이 혼잡한 카테고리 내에서 차별화될 수 있는 요소들을 병행하여 개발하세요.

65. 

    계정 해지 iOS 계정 해지

    어떤 앱은 웹사이트처럼 보였고, 수십 개의 앱이 사라졌습니다

    무슨 일이 있었나

    10년 넘게 80개 이상의 앱을 출시해 온 한 스튜디오의 개발자 계정이 해지 대상으로 지정되었습니다. 스튜디오 측에 따르면, 특정 앱 하나가 기존 웹사이트와 유사하다는 이유였습니다. 사전 경고도 없었으며, 해당 앱만 삭제할 수 있는 옵션도 제공되지 않았습니다. 결국 클라이언트용 라이선스 앱을 포함해 스튜디오의 모든 앱이 App Store에서 내려갔고, 업데이트도 모두 차단되었습니다.

    해결

    해결되지 않은 상태입니다. 해당 스튜디오는 이 결정에 대해 공개적으로 이의를 제기했습니다.

    교훈

    개발자 계정 하나가 무너지면 모든 것이 끝납니다. 클라이언트를 위해 앱을 개발한다면, 클라이언트 본인의 개발자 계정으로 앱을 출시하세요. 그래야 귀하의 앱 하나로 인해 클라이언트의 계정까지 정지되는 불상사를 막을 수 있습니다.

66. 

    제3.2(f)조 (Developer Program 라이선스 계약) iOS 계정 해지

    타이틀 업데이트 후, 3.2(f) 계정 해지 통보

    무슨 일이 있었나

    한 인디 개발자가 앱 하나의 간단한 이름 변경을 제출했다가 3.2(f) 조항에 따라 계정 해지 통보를 받았습니다. 모든 앱이 스토어에서 삭제되었고, 공식 항소를 제기했지만 15일이 지나도록 담당자로부터 아무 답변도 듣지 못했습니다.

    해결

    미해결.

    교훈

    3.2(f) 통보를 촉발한 업데이트가 Apple이 실제로 문제 삼는 대상은 아닐 수 있습니다. 항소하기 전에 각 앱의 소유자와 운영 주체를 입증할 명확한 증거를 확보하세요. 답변은 몇 주 걸릴 수 있습니다.

67. 

    제3.2(f)조 (Developer Program 라이선스 계약) iOS 계정 해지

    페이월 수정 한 번 후, 일주일 만에 3.2(f) 계정 해지 통보

    무슨 일이 있었나

    한 인디 개발자의 앱이 결제 페이지(paywall)의 연간 및 주간 가격 표시 방식 문제로 리젝을 당했습니다. 해당 결제 페이지는 AI 코딩 어시스턴트가 복사해 온 템플릿 기반이었습니다. 개발자는 code에서 문제를 수정하고 새 빌드를 제출한 뒤 일주일 정도 기다렸습니다. 하지만 심사 결과 대신, 그들을 맞이한 것은 3.2(f) 조항에 따른 계정 해지 예고 통지였습니다. 개발자 계정 전체가 플래그 처리되었고, 수년간 구축한 모든 앱이 App Store에서 삭제되었으며, 정산금까지 동결되었습니다. 개발자는 제출 이후 앱에 아무것도 변경하지 않았으며 이를 증명할 로그도 있다고 밝히며, 혹시 계정을 복구한 사례가 있는지 공개적으로 도움을 요청했습니다.

    해결

    게시 시점 기준 미해결 상태입니다.

    교훈

    결제 페이지나 가격 정책 관련 리젝을 단순한 절차로 여기지 말고 경고로 받아들여야 합니다. 첫 제출 전, code에 사용된 템플릿이나 생성된 결제 페이지의 가격 및 무료 체험 조건 표시 방식을 반드시 확인하세요. 또한, 추후 계정 관련 소명이 필요할 때 제출 내역을 정확히 증명할 수 있도록 빌드 및 변경 로그를 철저히 기록해 두어야 합니다.

68. 

    가이드라인 3.1.1 In-App Purchase macOS가 가이드라인 3.1.1

    스트리밍 게임 내 결제 문제로 3.1.1 조항에 따라 리젝된 무료 클라우드 게임 클라이언트

    무슨 일이 있었나

    한 개발자가 주요 콘솔 제조사의 클라우드 게임 서비스를 위한 무료 원격 플레이 앱을 만들어 App Store에 제출했습니다. Mac 버전은 가이드라인 3.1.1에 따라 거절되었습니다. App Review는 스트리밍되는 일부 게임이 사용자를 App Store 외부의 디지털 콘텐츠 구매로 유도할 수 있다고 밝혔습니다. 개발자가 이해하기로는 해당 게임 서비스는 스트리밍 세션 중에 플레이어가 결제를 완료할 수 없습니다. 일부 게임에 구매 옵션이 표시되지만 스트리밍 중에는 결제가 진행될 수 없습니다. 개발자는 이미 스토어에 유사한 스트리밍 앱이 여러 개 있다는 점을 지적하며 이의 신청을 제기했습니다.

    해결

    게시 시점 기준 이의 신청 심사 대기 중.

    교훈

    스트리밍 및 클라이언트 앱의 경우, App Review는 자체 code뿐만 아니라 스트리밍 콘텐츠 안에서 사용자가 보게 되는 내용까지 심사합니다. 이의 신청 때까지 미루지 말고, 첫 제출 전에 스크린샷과 함께 스트리밍 내 결제 동작 방식을 리뷰 노트에 정확히 설명하세요.

69. 

    iPad 로그인 (가이드라인 번호 미기재) iOS 로그인

    백엔드 장애 중 iPad 로그인 실패로 인한 세 번째 거절

    무슨 일이 있었나

    피트니스 앱을 개발하던 소규모 팀이 iOS 앱 심사에서 세 번째 거절을 당했습니다. 리뷰어가 iPad에서 로그인을 할 수 없었기 때문입니다. 원인은 앱 code 자체에 있지 않았습니다. 리뷰어가 시도하던 시점에 호스팅 중인 백엔드 제공업체에 인증 문제가 발생하여 로그인이 실패한 것이었습니다. 팀은 이메일과 비밀번호가 포함된 데모 계정을 제공했지만, 리뷰어는 해당 계정으로 다시 시도하지 않았습니다. 리뷰어는 테스트할 iPad나 Mac도 없었습니다. 백엔드가 정상화된 후 팀은 앱을 다시 제출했습니다. Apple은 거절되더라도 심사가 우선 처리(expedited review) 상태로 유지될 것이라고 했지만, 영업일 기준 3일이 지난 지금까지도 여전히 심사 대기 중입니다.

    해결

    재제출 완료, 게시 시점 기준으로 여전히 심사 대기 중입니다.

    교훈

    리뷰어는 주로 iPad로 테스트하며 보통 로그인을 한 번만 시도합니다. 빌드가 심사 중일 때는 백엔드와 인증 제공업체의 상태를 모니터링하고, 제출 전 iPad 크기의 화면에서 데모 계정을 테스트하세요. 또한 리뷰 노트에 로그인 실패 시 연락할 담당자를 명시하는 것이 좋습니다.

70. 

    가이드라인 5.1.1(i) 및 5.1.2(i) iOS 가이드라인 5.1.1 가이드라인 5.1.2 AI 데이터 공유

    약관에 숨겨진 AI 동의는 5.1.1(i) 및 5.1.2(i) 규정을 충족하기에 부족했습니다

    무슨 일이 있었나

    한 개발자의 저널 앱이 사용자 데이터를 AI 서비스와 공유한다는 내용의 가이드라인 5.1.1(i) 및 5.1.2(i) 위반으로 iOS에서 거절되었습니다. 데이터 처리에 대한 동의는 이미 앱 약관에 포함되어 있었지만, App Review는 이를 인정하지 않았습니다. 개발자는 모델이 단 하나의 엔트리라도 읽기 전에 앱 내에서 가장 먼저 나타나는 명시적인 동의 화면을 구현했습니다. 그다음 엔트리가 모델에 도달하는 모든 code 경로를 매핑하고, 각 경로에 동의 여부를 확인하는 게이트를 설정하여 동의 없이는 요청 자체가 생성되지 않도록 했습니다. 이제 백그라운드 작업은 동의하지 않은 계정은 건너뛰고 실패 대신 대기하며, 동의 화면에 명시되지 않은 AI 호스트를 호출할 경우 릴리스 체크에서 실패하도록 설정했습니다.

    해결

    수정 후 재제출 완료. 게시 시점 기준으로 Apple의 최종 판결은 알 수 없습니다.

    교훈

    약관의 한 줄은 AI 데이터 공유에 대한 동의가 될 수 없습니다. 첫 요청 전 앱 내부에서 제공자와 데이터 종류를 명시하여 동의를 구하고, 사용자 콘텐츠를 전송하는 모든 code 경로가 해당 답변을 확인하도록 만드세요.

71. 

    반복적인 메타데이터 거절 이후 적용된 Section 3.2(f) (Developer Program License Agreement) iOS 계정 해지 메타데이터와 IAP

    라이브러리 하나 추가했을 뿐인데, 8번의 거절과 앱 이름 변경, 그리고 결국 계정 해지 통보까지

    무슨 일이 있었나

    한 인디 개발자는 3년 가까이 운영하며 6자리 수의 매출을 올리고, 낮은 환불률을 유지하며 꾸준히 업데이트를 해온 iOS 앱을 보유하고 있었습니다. 6개월도 더 전에, 이 개발자는 단 하나의 새로운 라이브러리만 추가된 작은 업데이트를 제출했습니다. 하지만 App Review는 무려 8번 넘게 거절했습니다. 거절 사유는 매번 메타데이터였습니다. 1년 넘게 유지해온 키워드, 특정 로컬라이제이션의 부제, 그다음엔 스크린샷, 그러고 나서 또 같은 문제들이 반복되더니, 결국 검색 트래픽의 대부분을 차지하던 앱 이름 자체를 문제 삼았습니다. 개발자는 App Review와의 통화를 요청했고, 리뷰어는 앱 이름이 마지막 남은 문제라고 말했습니다. 결국 앱 이름을 통째로 바꾸고 다시 제출했지만, 3일 뒤 부제와 스크린샷 문제를 이유로 또다시 형식적인 거절이 돌아왔습니다. 개발자는 업데이트가 필요 없다고 판단하고 포기했습니다. 몇 달 후, 예전 리뷰 스레드에 계정 해지 예고 통보가 도착했습니다. 내용은 계정이 리뷰 프로세스를 회피하려 반복적으로 가이드라인을 위반했으며, 이전 메시지의 문제들이 여전히 해결되지 않았다는 것이었습니다. 결국 앱은 스토어에서 삭제되었고, 계정 전체가 삭제 대상으로 분류되었습니다.

    해결

    App Review Board에 항소 제출, 게시 시점 기준 결과 대기 중.

    교훈

    방치된 심사 요청도 계정에 불이익을 줄 수 있습니다. 심사 루프가 반복된다면, 전화 상담에만 의존하지 말고 리뷰 스레드를 통해 남은 모든 이슈를 서면으로 확답받으세요. 만약 업데이트를 포기하기로 했다면, 거절 상태를 그대로 두지 말고 스레드에 의사를 밝힌 뒤 심사 중인 빌드를 제거해야 합니다.

72. 

    가이드라인 1.1 Safety: Objectionable Content, 그리고 Section 3.2(f) iOS 부적절한 콘텐츠 계정 해지

    두 번의 1.1 거절, 이미지 관련 질문 하나, 그리고 계정 해지 통보

    무슨 일이 있었나

    AI 커플 사진을 생성하는 한 개발자의 iOS 앱이 부적절한 콘텐츠를 이유로 가이드라인 1.1에 따라 거절되었습니다. 거절 사유에는 어떤 이미지가 문제인지 명시되어 있지 않았습니다. 개발자는 신체 접촉이나 기대는 동작이 없는 수준으로 샘플 이미지를 수정하여 약 5일 후 다시 제출했습니다. 하지만 4일 뒤 동일한 사유로 또다시 거절되었습니다. 개발자는 새 빌드를 보내는 대신 Apple에 어떤 이미지가 문제인지 문의하는 메일을 보냈습니다. 10일 동안 답변이 없더니 앱은 스토어에서 삭제되었고, 개발자는 계정 해지 예고 통보를 받았습니다. Apple은 반복적인 수정 및 재제출 과정을 심사를 우회하려는 시도로 간주한 것입니다. 정산은 중단되었고 계정 내 모든 앱이 위험에 처했으며, 항소할 수 있는 기간은 30일뿐이었습니다. 동일한 통보를 받은 다른 개발자들의 포럼 글을 찾아보니, 대부분의 항소는 답변 없이 몇 주씩 방치되었고, 유일하게 복구된 사례는 실제 원인을 명시하고 모든 상황을 투명하게 밝힌 두 번째 항소 후에야 가능했습니다.

    해결

    게시 시점 기준 항소 준비 중

    교훈

    이제 동일한 가이드라인으로 두 번 거절당하면 계정이 위험해질 수 있습니다. 콘텐츠 거절 사유가 모호하다면, 재제출하기 전에 App Review 측에 정확한 화면이나 에셋을 지목해 달라고 요청하세요. 모든 변경 사항을 기록으로 남기고, 두 번째 거절을 받았을 때는 다시 시도하기보다 일단 멈추라는 신호로 받아들여야 합니다.

73. 

    가이드라인 2.3.7, 5.2.5 및 4.8 iOS 가이드라인 2.3.7 메타데이터와 IAP 로그인 요구 사항

    Mac에서는 승인되었으나, 동일한 앱의 iPhone 버전이 2.3.7, 5.2.5, 4.8 가이드라인 위반으로 거절됨

    무슨 일이 있었나

    주요 서드파티 캘린더 서비스를 위한 캘린데 클라이언트를 개발 중인 한 개발자가 Mac 버전을 먼저 출시했습니다. Mac 버전은 앱 설명에 해당 캘린더 서비스와 연동된다는 내용을 포함하기 위해 이미 공식 이의 신청을 거쳤으며, App Review 측에 왜 Sign in with Apple이 필요하지 않은지도 이미 설명한 상태였습니다. 하지만 Mac 앱과 동일한 번들 및 App ID를 사용하여 iPhone 버전을 추가하자마자 세 가지 가이드라인 위반으로 한꺼번에 거절되었습니다. 인앱 이벤트에 표시된 가격 문제(2.3.7), 앱이 iPhone, iPad, Mac용이라고 명시한 문구(5.2.5), 그리고 캘린더 서비스 자체 로그인 옆에 Sign in with Apple을 제공하지 않은 점(4.8)이 문제였습니다. 가이드라인 4.8에는 특정 서드파티 서비스의 클라이언트 앱을 위한 예외 조항이 있으며 이 앱이 바로 그 경우에 해당하지만, Mac 버전에서 인정받았던 설명이 그대로 적용되지 않았습니다. 각 플랫폼 타겟은 완전히 처음부터 다시 리뷰되었습니다.

    해결

    게시 당시에는 명시되지 않음.

    교훈

    새로운 플랫폼은 동일한 App ID 내에 있더라도 새로운 리뷰를 의미합니다. 이미 리뷰 노트를 통해 인정받은 모든 설명과 예외 사항을 각 플랫폼별로 다시 복사해 두세요. 또한 제출 전 인앱 이벤트와 앱 설명에 가격 정보나 Apple 기기 이름이 잘못 포함되어 있지 않은지 반드시 확인해야 합니다.

74. 

    Guideline 3.1.2(c), 이어서 Siri 텍스트 내 Apple 상표권(가이드라인 번호 미표기) iOS 가이드라인 3.1.2 끝없는 심사

    9일 대기, 3.1.2(c) 페이월 거절, 그리고 Siri 텍스트 때문에 42초 만에 거절된 바이너리

    무슨 일이 있었나

    신규 계정의 개발자가 글쓰기 습관 앱의 첫 버전을 제출하고 약 9일을 기다린 끝에 In Review 상태가 되었습니다. 하지만 50분 뒤, 가이드라인 3.1.2(c) 위반으로 거절되었습니다. 연간 플랜에서 계산된 월간 가격이 실제 청구되는 연간 가격보다 더 크게 표시되었기 때문입니다. 개발자는 페이월 폰트 크기를 수정해 새 빌드를 업로드했습니다. 그런데 이 빌드는 단 42초 만에 자동으로 거절되었습니다. Siri 단축어의 도움말 텍스트에 Apple 앱의 브랜드명이 언급되었는데, Siri intents 텍스트에는 'Apple'이라는 단어를 사용할 수 없기 때문입니다. 개발자는 이를 일반적인 메모 앱을 지칭하도록 문구를 수정하고 다시 빌드를 업로드했습니다.

    해결

    재제출 완료, 게시 시점 기준 결과 미정.

    교훈

    첫 제출 전, 모든 플랜에서 결제 금액을 가장 눈에 띄게 표시하세요. 또한 Siri, Shortcuts, 위젯 텍스트를 포함하여 사용자에게 노출되는 모든 문구에 Apple 상표가 포함되어 있는지 확인해야 합니다. 자동 검사로 몇 초 만에 찾아낼 수 있지만, 검토를 반복할 때마다 대기 순번이 밀리는 비용을 치러야 합니다.

75. 

    이전 이름 사용으로 인한 거절 사례를 인용한 Section 3.2(f) (Developer Program License Agreement) iOS 계정 해지 메타데이터와 IAP

    이름 거절 문제를 해결하여 승인받았으나, 약 1년 후 사기 행위로 인한 계정 해지 통보를 받은 사례

    무슨 일이 있었나

    소규모 회사 계정을 운영하는 1인 개발자가 약 1년 반 동안 라이브 앱 8개를 만들었습니다. 거의 1년 전, 그중 한 앱이 이름에 포함된 단어 때문에 Apple의 반대로 거절된 적이 있었습니다. 개발자는 이름을 바꿨고, 앱은 재심사를 거쳐 승인됐으며, 이후 업데이트도 승인됐습니다. 공유된 리뷰 이력을 보면 버전 1.0은 이틀 연속 거절됐다가 다음 날 승인됐고, 약 두 달 뒤 업데이트는 첫 시도에 승인됐습니다. 그 후 앱은 약 9개월 동안 손대지 않은 채 남아 있었습니다. 그러던 중 같은 계정의 새 앱이 거절됐고, 곧이어 섹션 3.2(f)의 부정 또는 사기 행위를 사유로 한 해지 예정 통보가 도착했습니다. 제출물이 심사를 회피하려고 가이드라인을 반복 위반했고, 이전 메시지의 문제도 해결되지 않았다는 내용이었습니다. 새로운 문제를 특정하지도 않았고, 사전 경고나 질문도 없었습니다. 문제가 없었던 앱을 포함해 모든 앱의 수익이 중단됐고, 새 계정도 해지될 수 있다는 경고가 붙어 있었습니다. 대응 방법은 2,000자로 제한된 웹 폼뿐이었고, 자동 응답만 온 뒤 아무 소식이 없었습니다. 개발자는 문제가 된 앱들의 삭제를 받아들이고 같은 날 서버를 종료했으며, 모든 제출을 중단하고 첫날 정식 이의 신청을 보냈습니다.

    해결

    첫날 이의 신청을 보냈으며, 작성 시점 기준 자동 응답만 받은 상태입니다.

    교훈

    수정해서 승인받은 거절이라도 몇 달 뒤에 반복 패턴의 근거로 다시 인용될 수 있습니다. 모든 거절 메시지와 적용한 정확한 변경 사항, 그 뒤의 승인 내역을 모두 보관하세요. 그래야 짧은 항소 양식에 전체 히스토리를 보여줄 수 있고, 제출 후에는 일정이 어떻게 될지 기대하지 마세요.

76. 

    가이드라인 4.3 스팸 및 4.2.6 iOS 가이드라인 4.3 가이드라인 4.2.6

    혼자 만든 게임이 스팸과 템플릿 사유로 두 번 거절, 9개 답변 전송 후 무응답

    무슨 일이 있었나

    저녁 시간에 혼자 게임을 만드는 개발자가 독창적인 게임을 제출했지만, 10월 초 4일 간격으로 가이드라인 4.3(스팸)과 4.2.6(상용화된 템플릿이나 앱 생성 서비스로 만든 앱) 사유로 두 번 거절당했습니다. 템플릿은 전혀 쓰지 않았고 모든 코드는 개발자가 직접 작성했습니다. 두 거절 모두 같은 템플릿 문구였고, 어떤 앱과 비슷하다는 언급도 없었습니다. 이어서 Apple이 게임 제작 방식에 관한 질문 9개를 보냈고, 개발자는 두 번째 거절 다음 날 모든 질문에 상세히 답했습니다. 답장은 오지 않았습니다. 약 9일 뒤 App Review Board에 항소했고, 그로부터 일주일이 지나도 여전히 기다리는 중이었습니다. 개발자의 추측은 몇 달 안에 여러 게임을 내놓는 1인 개발자가 리뷰어 입장에서는 앱 공장처럼 보인다는 것이었습니다. 그 사이 개발자는 게임을 웹 브라우저에서 무료로 플레이할 수 있게 해 두었습니다.

    해결

    첫 거절 후 약 3주 뒤, 게시 시점에 계류 중이던 App Review Board 항소.

    교훈

    4.3과 4.2.6은 단일 바이너리가 아니라 계정 전체를 기준으로 판단될 수 있습니다. 짧은 기간에 여러 타이틀을 출시한다면 첫 제출부터 각 타이틀이 왜 독창적인지 보여주세요. 빌드 방식에 대한 리뷰 노트와 짧은 게임플레이 영상을 함께 제시해야 합니다. 거절 문구가 템플릿화되면 상세한 답변은 몇 주 동안 읽히지 않은 채 방치될 수 있습니다.

77. 

    Guideline 2.1 App Completeness, 이어서 Guideline 5 Legal(중국 출시 가능 여부) iOS 가이드라인 2.1 Guideline 5 법적 사항 끝없는 심사

    리뷰어용 무료 라이선스로 페이월을 숨겼지만, 대기열에서 6일을 보낸 끝에 중국 AI 심사에서 거절됐습니다.

    무슨 일이 있었나

    한 개발자가 정기 결제 관리용 개인 금융 앱을 처음으로 iOS에 제출했지만, 가이드라인 2.1 App Completeness 항목으로 거절되었습니다. 원인은 의도치 않은 배려 때문이었습니다. 리뷰어의 이메일에 유료 라이선스를 부여하는 바람에, 리뷰어가 결제창을 건너뛰고 구매 프로세스를 전혀 확인하지 못한 것입니다. 개발자는 스크린샷이 포함된 단계별 PDF 가이드를 작성해 다시 제출했고, 이번에는 iOS와 Mac 버전을 함께 보냈습니다. 새 제출 건은 6일을 기다린 끝에 'In Review' 상태로 넘어갔으나, 앱이 중국 본토에서 서비스 가능하다는 점 때문에 ChatGPT 언급이 문제가 되어 다시 거절되었습니다.

    해결

    이 글을 쓰는 시점에도 여전히 거절 상태이지만, 최신 빌드는 TestFlight를 통해 테스터들에게 제공되고 있습니다.

    교훈

    App Review가 결제창을 포함하여 신규 사용자가 보는 화면을 그대로 볼 수 있게 하세요. 구매 프로세스를 가리는 무료 라이선스 대신, 작동하는 데모나 샌드박스 계정 및 명확한 안내 사항을 제공하는 것이 좋습니다. 또한 앱이나 앱 스토어 설명에 ChatGPT와 같은 AI 제공업체를 언급한다면, 제출 전 중국 본토가 서비스 지역에 포함되어 있는지 확인하세요. 심사 단계가 새로 시작될 때마다 며칠씩 대기 시간이 소요될 수 있기 때문입니다.

78. 

    가이드라인 2.3.10 Accurate Metadata iOS 가이드라인 2.3.10 메타데이터와 IAP 끝없는 심사

    첫 리뷰까지 10일, Google Play 언급, 그리고 다시 2주를 더 기다림

    무슨 일이 있었나

    10월 초, 신규 개발자 계정을 가진 개발자가 새 앱을 제출했습니다. 사용자가 자신의 이미지를 공개적으로 업로드할 수 있는 앱이라 개발자도 콘텐츠 모더레이션 검토가 더 까다로울 것으로 예상했습니다. 첫 리뷰는 10일 후 iPad에서 진행됐고, 가이드라인 2.3.10 정확한 메타데이터 위반으로 거절됐습니다. 앱이나 메타데이터에 제3자 플랫폼이 언급됐다는 이유였고, 다음 단계는 Google Play 관련 언급을 삭제하는 것이었습니다. 개발자는 인앱 결제를 설명하는 문구에서 그 언급을 찾아냈습니다. 수정 후 앱은 다시 대기열에 들어갔고, 2주가 지나도 여전히 리뷰를 기다리고 있었습니다. 첫 제출 후 24일, 아직 출시 전이었습니다.

    해결

    이 글을 쓰는 시점에도 첫 제출 후 24일째 리뷰 대기 중입니다.

    교훈

    첫 제출 전, 인앱 결제 설명을 포함해 제출하는 모든 텍스트 필드에서 다른 스토어나 플랫폼 이름이 있는지 확인하세요. 신규 계정은 반려 후 재제출까지 대기열에서 일주일 이상 걸릴 수 있으므로, 단어 하나의 언급이 출시를 몇 주나 늦출 수 있습니다.

79. 

    가이드라인 2.1 앱 완성도 (정보 필요) iOS 가이드라인 2.1 끝없는 심사

    대기 24일 만에 받은 2.1 거절 사유: 전체 화면 녹화본 제출 요청

    무슨 일이 있었나

    한 개발자가 구독 그룹과 연간/월간 구독 2종을 포함한 새로운 iOS 앱 버전 1.0.0을 제출했습니다. 24일을 기다린 끝에 Apple은 가이드라인 2.1(App Completeness)을 근거로 앱을 거절했고, 개발자는 당혹감을 감추지 못했습니다. 앱 버전이 거절되면서 함께 제출된 구독 항목들도 승인되지 못한 채 'Ready for Review' 상태로 머물렀습니다. 거절 사유는 개발자가 처음 접해본 '2.1 Information Needed' 요청이었습니다. Apple은 최신 OS가 설치된 실제 기기에서 앱 실행부터 회원가입, 로그인, 계정 삭제, 사용자 생성 콘텐츠(UGC)의 신고 및 차단 기능, 유료 콘텐츠 접근까지 이어지는 일반적인 사용자 흐름을 담은 화면 녹화본을 요구했습니다. 또한 서비스 목적과 타겟 사용자 설명, 로그인 정보가 포함된 설정 안내, AI 서비스를 포함하여 앱이 의존하는 외부 서비스 목록, 지역별 차이점, 규제 산업 관련 문서 또는 보호된 제3자 자료에 대한 설명도 요청했습니다. 답변 내용은 향후 제출을 위해 App Store Connect의 심사 정보(review notes)에도 추가해야 했습니다.

    해결

    개발자는 게시 시점에 맞춰 녹화 영상과 답변을 다시 준비하러 떠났습니다. 결과는 알 수 없습니다.

    교훈

    대기열에서 몇 주를 기다린 끝에 'Information Needed' 요청을 받으면 전체 심사 주기를 한 번 더 돌아야 합니다. 새 앱을 제출하기 전에, 특히 구독, 계정, 사용자 콘텐츠가 있는 앱이라면 실제 기기에서 그 워크스루를 녹화하고 답변을 리뷰 노트에 적어 두세요. 거절된 버전은 함께 제출된 모든 항목의 진행도 막기 때문입니다.

80. 

    제3.2(f)조 (Developer Program 라이선스 계약) Apple Developer Program 계정 해지 끝없는 심사

    6회 연속 업데이트 승인 후, 일반 업데이트와 3.2(f) 계정 해지

    무슨 일이 있었나

    한 인디 개발자가 업데이트 6개를 연속으로 승인받았습니다. 공유된 리뷰 기록을 보면 최신 제출 건은 '심사 중(In Review)'이며, 이전 건들은 모두 '심사 완료(Review Completed)' 상태였습니다. 이후 10월 중순에 일반적인 업데이트를 제출했으나 심사 단계에서 멈춰버렸습니다. 심사 결과 대신, 해당 개발자 계정 전체가 3.2(f) 조항에 따라 해지되었습니다. App Store Connect에는 해당 제출일자로 된 메시지가 여러 버전에 첨부되어 '미해결 문제(unresolved issues)'로 표시되어 있었습니다. 개발자는 자신의 앱이 네이티브 앱이며 그동안 승인 기록도 깨끗했다고 설명하며, 현재 Apple 지원팀에서 이의 제기를 조사 중이라고 밝혔습니다.

    해결

    게시 당시 이의 제기 조사 중

    교훈

    승인 기록이 깨끗하다고 해서 3.2(f) 조항에 따른 계정 해지를 피할 수 있는 건 아닙니다. 모든 제출 내역, 리뷰 메시지, 승인 기록을 날짜별로 남겨 두고, 리뷰가 끝날 때마다 App Store Connect의 Messages 섹션을 확인하세요. 그래야 이의 신청이 가능해지는 즉시 전체 히스토리를 보낼 수 있습니다.

81. 

    App Review 정보 요청(데모 계정 및 화면 녹화) iOS 로그인

    제출 5분 만에 삭제된 데모 계정, 그리고 두 번째 거절을 막아준 녹화 요청

    무슨 일이 있었나

    한 에이전시가 App Review용 데모 계정과 함께 클라이언트 앱을 제출했습니다. 그런데 제출 5분 만에 App Review 측이 해당 데모 계정을 삭제해 버렸습니다. 이후 Apple은 앱의 화면 녹화를 요청했습니다. 녹화를 만들던 팀은 앱 안에서 미처 발견하지 못했던 판매 문구를 찾아냈고, 그대로였다면 앱이 또 거절당했을 내용이었습니다.

    해결

    게시 시점 기준 최종 결과는 공유되지 않음.

    교훈

    리뷰어가 계정 삭제 기능 등을 테스트하는 과정에서 제공된 데모 계정을 삭제할 수 있으니, 계정을 다시 생성하거나 여러 개를 제공할 수 있는 방법을 마련해 두세요. 제출 전 직접 리뷰 과정을 녹화해 보는 것도 좋습니다. 리뷰어의 시선으로 앱을 살펴보면 다음 거절 사유가 될 만한 문구를 미리 찾아낼 수 있는 가장 쉬운 방법입니다.

82. 

    제3.2(f)조 (Developer Program 라이선스 계약) Apple Developer Program 계정 해지 메타데이터와 IAP

    초기 5번의 거절, 4번의 업데이트 승인, 그리고 1년 뒤 받은 3.2(f) 통지

    무슨 일이 있었나

    약 10년의 앱 개발 경력을 가진 한 독립 iOS 개발자가 2025년 4월, 새로운 AI 이미지-투-비디오 앱을 제출했습니다. 사용자는 자신의 사진을 upload하여 첫 번째 생성 결과물을 무료로 받을 수 있었고, 구독 방식이 아닌 일회성 인앱 결제로 크레딧을 구매할 수 있는 구조였습니다. 첫 제출은 스크린샷과 메타데이터 문제로 인해 다섯 번이나 거절되었습니다. 스크린샷이 지나치게 마케팅 중심적이라는 평가를 받았고, 커플이 키스하는 장면을 담은 스크린샷을 교체하여 프로포즈 장면을 넣었으나 이번에는 '부적절한 콘텐츠' 가이드라인에 걸렸습니다. 스크린샷과 텍스트, 빌드를 수정한 끝에 앱은 승인되었고, 이후 2025년 8월 마지막 업데이트를 포함해 네 번의 업데이트가 거절 없이 통과되었습니다. 그 이후로는 업데이트가 없었습니다. 그런데 14개월이 지난 후, 해당 계정의 제출물들이 심사를 회피하려는 시도로 가이드라인을 반복적으로 위반했으며, 여러 번의 재제출 후에도 위반 사항이 해결되지 않았다는 내용의 계정 해지 예고 통지(Pending Termination Notice)가 날아왔습니다. 이 통지에는 과거 다섯 번의 버전 모두가 연루되어 있었습니다. 개발자에 따르면 App Store Connect에는 과거 거절 사유에 대한 상세 정보가 더 이상 표시되지 않는 상태였습니다. 개발자는 자정 무렵 통지를 받은 후 약 30분 만에 2,000자 제한 내에서 항소를 진행했지만, 나중에는 조금 더 차분하게 내용을 정리해서 보낼 걸 그랬다며 후회했습니다.

    해결

    게시 시점 기준 이의 신청 심사 대기 중.

    교훈

    승인이 났다고 해서 상황이 끝난 것은 아닙니다. 거절 메시지, 인용된 가이드라인, 수정 사항, 승인 날짜를 반드시 따로 기록해 두세요. App Store Connect에서 이전 상세 내역이 사라질 수 있기 때문입니다. 거절 통보를 받으면 성급하게 바로 답변을 보내기보다, 글자 수 제한에 맞춰 논리적이고 명확한 항소문을 작성하는 데 시간을 투자하세요.

83. 

    제3.2(f)조 (Developer Program 라이선스 계약) Apple Developer Program 계정 해지 메타데이터와 IAP

    앱 제목 키워드, 3.2(f) 조항에 따른 계정 해지, 그리고 스트리밍 관련 참조를 지적한 항소 답변

    무슨 일이 있었나

    한 인디 개발자가 3.2(f) 조항 위반으로 개발자 계정 전체가 해지되는 일을 겪었습니다. 개발자의 설명에 따르면 사전 경고나 메타데이터 거절 없이 갑작스럽게 진행되었으며, 앱 제목에 포함된 키워드 실수 때문인 것으로 추정되었습니다. 개발자는 항소를 제기했으나, App Review Board는 조사 결과 가이드라인 위반이 확인되었다고 답변했습니다. 개발자의 앱 중 하나가 사용자에게 스트리밍 서비스를 제공하는 것으로 오해하게 만드는 잘못된 정보를 포함하고 있었으며, Apple은 이를 심각한 위반으로 간주했습니다. 통지서에는 조작적이거나 기만적인 행위 패턴이 명시되어 있었고, 수익금 지급은 중단되었습니다. 또한 계정 해지가 공식화된 이후, 개발자가 재심사를 요청하려면 해지 사유와 향후 개선 계획을 상세히 설명하여 App Review Board에 청원해야 한다고 안내되었습니다.

    해결

    항소 거부됨. 공식적인 계정 해지 후에는 재가입 신청이 가능합니다.

    교훈

    앱이 제공하지 않는 스트리밍 같은 서비스를 제목이나 키워드에 포함하면, 단순한 메타데이터 실수가 아닌 기만 행위로 간주될 수 있습니다. 이는 사전 거절 없이 바로 계정 해지로 이어질 수 있으니, 제출 전 제목, 부제, 키워드가 실제 앱 기능과 일치하는지 반드시 확인하세요.

84. 

    가이드라인 4.1(a) Copycats iOS 끝없는 심사

    15일간의 심사 후, 공개 API의 영화 포스터 사용으로 인한 4.1(a) Copycats 거절

    무슨 일이 있었나

    한 개발자가 영화 선택을 도와주는 iOS 앱을 개발했습니다. 이 앱은 공개 영화 데이터베이스인 API에서 가져온 제목과 포스터를 보여주며, 앱 내에 출처를 명시하고, 시청 버튼을 누르면 직접 스트리밍하는 대신 공식 스트리밍 앱을 실행하도록 설계되었습니다. 하지만 15일간의 심사 끝에 Apple은 포스터를 제3자 콘텐츠로 간주하여 4.1(a) Copycats 가이드라인을 근거로 앱을 거절했습니다. Apple은 사용 권한 증명을 요구하거나 포스터를 삭제하라고 요청했습니다. 동일한 포스터를 사용한 같은 앱은 이미 Android와 TV 기기 앱 스토어에서 승인된 상태였습니다.

    해결

    게시 시점 기준으로 미해결 상태였습니다. 개발자는 다른 개발자들에게 API 약관이 증빙으로 인정되는지, 아니면 포스터를 내려야 하는지 묻고 있었습니다.

    교훈

    앱 내 크레딧 표기와 다른 스토어의 승인은 App Review에서 권리로 인정되지 않습니다. 앱에 API의 포스터, 아트워크, 로고가 들어간다면 제출 전에 표시 권한에 대한 서면 증빙을 준비하거나, 해당 요소를 뺀 버전을 계획하세요.

85. 

    메타데이터 거절(현지화 키워드) iOS 메타데이터와 IAP

    AI가 앱을 5개 언어로 번역하면서 거절을 부른 키워드를 끼워 넣은 사례

    무슨 일이 있었나

    한 개발자가 AI 모델로 앱을 5개 언어 더 번역했습니다. 그중 한 언어에서 오해를 살 만한 키워드가 번역에 끼어들었고, 이 때문에 제출이 거절되었습니다. 일주일이 지나도 답변을 받지 못한 개발자는 다른 개발자들의 3.2(f) 계정 해지 사례가 이어진 한 주를 보내며, 수정안이 승인되더라도 나중에 계정에 불이익이 생기지 않을까 걱정하고 있었습니다.

    해결

    게시 시점 기준으로 Apple의 답변을 기다리는 중입니다.

    교훈

    제출 전, 각 언어별 담당자가 모든 현지화 키워드, 제목, 부제목을 검토하도록 하세요. 기계 번역은 빠르지만, App Review 심사관은 사용자가 직접 선택한 것처럼 모든 로케일의 단어를 검토합니다.

86. 

    App preview 메타데이터(가격 참조) iOS 메타데이터와 IAP

    App preview에 무료 체험 가능 문구가 포함되어 업데이트가 거절됨

    무슨 일이 있었나

    한 인디 개발자가 '무료 체험 가능'이라는 문구가 포함된 App preview 영상을 포함하여 업데이트를 제출했습니다. Apple은 preview 내 'free'라는 언급을 가격 참조로 간주하여 업데이트를 거절했습니다. 개발자는 영상을 다시 편집하여 재제출했습니다.

    해결

    영상을 재편집하여 다시 제출했습니다. 게시 시점 기준으로 최종 결과는 공유되지 않았습니다.

    교훈

    무료 체험 기간이라 하더라도 앱 미리보기에서 가격이나 '무료'라는 단어는 제외하세요. 대신 앱 내 결제 페이지(paywall)에서 체험 조건을 보여주어야 합니다.

87. 

    가이드라인 2.5.1 소프트웨어 요구 사항(HealthKit) iOS 끝없는 심사

    6일간 대기 후, HealthKit 동기화 기능에 Apple Health 배지가 없다는 이유로 2.5.1 거절 판정

    무슨 일이 있었나

    한 인디 개발자가 Apple Health 동기화 기능을 처음으로 추가한 대규모 업데이트를 제출했습니다. '심사 대기 중' 상태로 6일 동안 머물렀는데, 그제야 계정에 서명해야 할 새로운 개발자 약관이 있다는 사실을 발견했습니다. 약관에 서명하자 그날 오후 바로 심사가 시작되었지만, 두 사건 사이의 연관성은 알 수 없었습니다. 이후 해당 업데이트는 앱 인터페이스 내에 Health 기능이 명확하게 표시되지 않았다는 이유로 가이드라인 2.5.1에 따라 거절되었습니다. 개발자는 Apple Health 배지의 존재를 모르고 있었습니다.

    해결

    동기화 토글 옆에 Works with Apple Health 배지를 추가하고, 리뷰 노트와 실제 기기에서 녹화한 화면 영상을 첨부했습니다. 다음 제출에서 승인되었습니다.

    교훈

    앱에서 Health 데이터를 읽거나 쓰는 경우, 첫 제출부터 인터페이스에 Apple Health 배지를 명확히 표시하세요. 또한 리뷰가 며칠째 진행되지 않는다면, 무엇보다 먼저 App Store Connect에서 서명되지 않은 계약이 있는지 확인해 보세요.

88. 

    가이드라인 1.1 Objectionable Content iOS 부적절한 콘텐츠

    1년 넘게 거절 없이 운영되다가 예고 없이 1.1 조항에 따라 삭제됨

    무슨 일이 있었나

    한 인디 개발자가 App Store에서 1년 넘게 앱을 운영해 왔습니다. 한 번도 거절된 적이 없었고 매달 적당한 구독 수익을 올리고 있었죠. 그런데 아무런 사전 경고 없이, Apple로부터 해당 앱이 가이드라인 1.1 Objectionable Content를 위반해 스토어에서 삭제되었다는 메시지를 받았습니다.

    해결

    개발자는 개발자 계정을 위험에 빠뜨리지 않으려고 Apple에 다시 제출하지 않겠다고 밝히고, 앱과 해당 니치 전체를 포기했습니다.

    교훈

    깨끗한 심사 이력이 나중에 앱이 내려가는 것을 막아주지는 않으며, 오랫동안 승인된 앱에도 콘텐츠 규정이 적용될 수 있습니다. 민감한 니치의 앱이라면 삭제 통보를 받은 뒤가 아니라 지금 가이드라인 1.1에 맞춰 콘텐츠와 스크린샷을 검토하세요.

89. 

    버그로 인한 거절(가이드라인 미명시) iOS 끝없는 심사

    100초 매치메이킹 타임아웃이 버그로 보고된 후, 6일 동안 답변을 기다렸습니다.

    무슨 일이 있었나

    한 개발자가 멀티플레이어 게임을 제출했습니다. 리뷰어는 버그 때문에 거절했지만, 리뷰어가 마주친 것은 크래시가 아니었습니다. 게임은 상대를 찾기 위해 100초를 기다린 뒤 검색을 멈추는데, 리뷰어는 이 타임아웃을 오작동으로 본 것입니다. 개발자는 리뷰어에게 매치메이킹 작동 방식을 설명하고 게임에서 타임아웃도 제거했습니다. 하지만 6일이 지나도 답변 한 줄 받지 못했습니다.

    해결

    답변을 통해 설명하고 타임아웃 설정을 제거했습니다. 하지만 게시 시점까지 여전히 답변을 기다리는 중입니다.

    교훈

    리뷰어는 종종 혼자서 늦은 시간에 테스트하므로 매치메이킹 대기열이 비어 있을 가능성이 높습니다. 리뷰 팀이 실제 게임에 접속할 수 있도록 봇 상대나 데모 모드 같은 수단을 제공하고, 제출 전 리뷰 노트에 이를 설명하세요.

90. 

    메타데이터 거절 (이용약관 및 개인정보 처리방침 링크) iOS 메타데이터와 IAP

    Code를 다른 앱에서 재사용했는데, 이용약관 및 개인정보 처리방침 링크가 여전히 이전 앱을 가리키고 있었습니다.

    무슨 일이 있었나

    한 개발자가 기존 앱의 일부를 재사용하여 새 앱을 빌드했습니다. 앱 내부의 이용약관 및 개인정보 처리방침 링크가 여전히 이전 앱을 가리키고 있었고, 이로 인해 App Review에서 제출이 거절되었습니다. 개발자에 따르면 거절 메시지에 수정해야 할 사항이 정확히 명시되어 있었다고 합니다.

    해결

    링크를 수정해서 다시 제출했습니다. 개발자 말로는 빠른 검토(expedited review)를 요청하면 보통 하루 정도 걸리지만, 꼭 필요한 경우에만 신중히 사용해야 한다고 하네요.

    교훈

    이전 프로젝트 기반으로 빌드한 앱을 제출하기 전에는, 포함된 모든 링크와 bundle 이름, 법적 고지 페이지를 반드시 확인하세요. 거절 사유 메시지를 꼼꼼히 읽어보세요. 무엇을 수정해야 하는지 정확히 알려주는 경우가 많습니다.

91. 

    Guideline 2.1 정보 필요 iOS 가이드라인 2.1

    리포트에 버그는 없었고, 2.1 Information Needed 항목에 대해 89초짜리 녹화 영상을 첨부해 답변했습니다.

    무슨 일이 있었나

    한 개발자가 두 번째 앱을 제출했는데, 버그 리포트 없이 가이드라인 2.1 Information Needed 항목으로 거절되었습니다. App Review 측에서 앱의 타겟 사용자, 사용 방법, 의존하는 외부 서비스, 타겟 지역에 대한 답변과 함께 화면 녹화 영상을 요구했습니다. 개발자는 시뮬레이터로 앱 실행부터 주요 기능 사용, 결제창(paywall)까지 이어지는 89초 분량의 영상을 녹화하고, 메모에 모든 질문에 대한 답변을 작성하여 당일 재제출했습니다.

    해결

    녹화 영상과 답변은 당일에 전송되었습니다. 최종 결과는 게시 시점에 공유되지 않았습니다.

    교훈

    신규 앱의 경우 2.1 정보 요청이 발생할 수 있으니 미리 대비하세요. 첫 리뷰에서 질문 때문에 지연되지 않도록, 제출 전 리뷰 노트에 주요 플로우 녹화 영상과 타겟 사용자, 사용 사례, 외부 서비스 및 지역에 대한 답변을 미리 준비해 두는 것이 좋습니다.

92. 

    가이드라인 2.5.4 소프트웨어 요구 사항 (백그라운드 모드) iOS 끝없는 심사

    오디오 background mode 체크박스 하나 때문에 거절된 후, 다음 업데이트까지 10일 소요

    무슨 일이 있었나

    이미 출시된 앱의 업데이트를 제출한 소규모 팀의 사례입니다. App Review는 앱에 필요하지 않은 오디오 background mode가 활성화되어 있다는 이유로 guideline 2.5.4에 따라 거절했습니다. 팀은 해당 모드를 제거하고 당일 재제출하여 하루 정도를 소모했습니다. 하지만 그 후 진행된 다음 업데이트는 리뷰 단계에서 약 10일 동안 머물러 있었습니다.

    해결

    오디오 백그라운드 모드를 제거하고 당일 바로 재제출했습니다. 하지만 다음 업데이트는 심사에서 약 열흘을 기다려야 했습니다.

    교훈

    백그라운드 모드는 지정된 용도로만 허용됩니다. 제출 전에는 반드시 Background Modes 권한을 열어 앱에서 실제로 사용하지 않는 항목을 모두 제거하세요. 체크박스 하나가 남겨져 있는 것만으로도 거절 사유가 될 수 있으며, 다음 심사가 얼마나 걸릴지는 예측할 수 없습니다.

93. 

    가이드라인 4.3(a) 스팸 iOS 가이드라인 4.3

    래퍼(wrapper) 형태의 웹 앱이 4.3(a) 스팸 판정을 받아, 개발자가 네이티브 앱으로 다시 구축한 사례

    무슨 일이 있었나

    한 개발자가 앱의 첫 버전을 네이티브 래퍼 내부의 웹 앱 형태로 제출했습니다. App Review는 이를 스팸 규정인 guideline 4.3(a)에 따라 거절했습니다. 개발자도 Apple의 지적이 타당함을 인정했습니다. 그들은 앱을 실제 네이티브 앱으로 다시 구축하고, 백엔드를 직접 운영하는 릴레이 서버로 옮긴 뒤 code 소스를 공개했습니다.

    해결

    자체 호스팅 relay server를 사용하는 native app으로 재구축했습니다. 재구축 버전의 결과는 게시물에 공유되지 않았습니다.

    교훈

    웹사이트를 단순히 감싼 형태는 App Review에서 스팸으로 간주하기 쉽습니다. App Store에 출시하려면, 웹사이트를 감싸서 통과되길 바라기보다 첫 제출부터 앱에 진정한 native 가치를 담으세요.

94. 

    부적절한 콘텐츠(Objectionable content) 거절 (스크린샷, 그 다음 부제목) iOS 부적절한 콘텐츠 메타데이터와 IAP

    성인용 콘텐츠가 전혀 없는 게임임에도 불구하고, 스크린샷이 부적절한 콘텐츠로 분류됨 (그 다음 부제목)

    무슨 일이 있었나

    한 소규모 스튜디오가 성인용 테마, 도박, 크립토 요소가 없는 심플한 스토리 게임을 iOS용으로 제작하고 있습니다. 할리우드 스타를 꿈꾸는 플레이어를 다룬 한 게임이 스크린샷 내 부적절한 콘텐츠 문제로 거절되었습니다. 스크린샷에는 옷을 제대로 갖춰 입은 캐릭터들만 등장했습니다. 스튜디오는 모든 스크린샷을 교체하여 재제출했습니다. 하지만 다음 거절 사유는 부제목의 부적절한 콘텐츠였습니다. 부제목은 단순히 게임을 '연예인의 삶과 드라마 게임'이라고 설명했을 뿐이었습니다. 각 리뷰 과정은 몇 주씩 소요되었습니다.

    해결

    9월에 앱을 처음 제출했지만, 10월 말까지도 승인이 나지 않았습니다.

    교훈

    App Review에서 이유 없이 메타데이터를 부적절하다고 반려한다면, 모든 것을 다시 수정하기 전에 App Store Connect를 통해 정확히 어떤 요소가 왜 문제인지 먼저 문의하세요. 스크린샷, 부제목, 키워드를 함께 검토한 후 재제출해야 합니다. 하나를 수정하면 다른 문제가 드러날 수 있기 때문입니다.

95. 

    가이드라인 5.2.5 법적 사항 및 지적 재산권 iOS Guideline 5 법적 사항 메타데이터와 IAP

    스크린샷에 iPhone과 유사한 기기가 포함되어 5.2.5 규정에 따라 거절됨

    무슨 일이 있었나

    한 개발자가 가이드라인 5.2.5로 인해 리젝을 당했습니다. App Review 측은 스크린샷의 메타데이터에 iPhone과 유사한 이미지가 포함되어 있어 사용자가 Apple 제품으로 혼동할 수 있다고 밝혔습니다. 화면에 표시된 기기는 Apple 제품이 아닌 Apple과 유사한 기기였을 뿐이며, 개발자는 이미 다른 앱에서 동일한 방식의 기기 이미지를 사용하여 승인받은 적이 있었기에 매우 당황스러웠습니다.

    해결

    게시 시점 기준으로 최종 결과는 공유되지 않았습니다. 다만, 다른 개발자의 답변에 따르면 App Review는 플랫폼과 일치하지 않는 디바이스 프레임이나 실제 iPhone과 다르게 보이는 렌더링 이미지에 대해서도 이의를 제기할 수 있다고 합니다.

    교훈

    한 앱이 승인되었다고 해서 다음 앱의 선례가 되지는 않습니다. iPhone과 거의 흡사해 보이는 디바이스 목업은 Apple 제품과 혼동을 줄 수 있는 유사한 이미지로 간주될 수 있습니다. 가급적 일반 스크린샷을 사용하거나 Apple이 마케팅용으로 제공하는 디바이스 프레임만 사용하고, 해당 프레임이 플랫폼과 일치하는지 반드시 확인하세요.

96. 

    Guideline 2.1 정보 필요 iOS 가이드라인 2.1

    첫 iOS 앱에서 2.1 정보 요청을 받았고, 모든 정보를 쉽게 찾을 수 있도록 수정하여 해결했습니다

    무슨 일이 있었나

    Android 버전을 이미 Google Play에 출시한 1인 개발자가 첫 iOS 앱을 제출했습니다. 앱에는 인앱 결제 3개와 사용자 생성 콘텐츠(UGC)가 있었습니다. App Review는 바로 거절하지 않고 가이드라인 2.1에 따른 정보 요청을 보냈습니다. 개발자는 리뷰어가 모든 인앱 결제를 확인할 수 있고 정상 작동해야 한다는 가이드라인 2.1을 다시 읽고, 사용자 생성 콘텐츠(1.2)와 계정 삭제(5.1.1(v)) 규칙도 확인했습니다. 다음 날 개발자는 새 빌드를 다시 제출했습니다. 모든 사용자 콘텐츠에 신고 및 차단 옵션이 보이도록 했고, 게시 전 사용자가 동의하는 커뮤니티 규칙, 로그아웃 및 계정 전환 기능, 결제·안전 도구·계정 제어 위치를 보여주는 화면 녹화를 포함했습니다.

    해결

    요청 다음 날 새 빌드 제출. 게시 시점에는 결과를 알 수 없음.

    교훈

    리뷰를 짧은 시간 안에 낯선 사람과 진행하는 사용성 테스트라고 생각하세요. 모든 결제, 신고 및 차단 옵션, 계정 제어 기능은 몇 초 안에 찾을 수 있어야 하며, 리뷰 노트에 첨부한 녹화 영상은 각 항목의 위치를 보여줘야 합니다. Google Play에 출시됐다고 해서 App Review를 통과할 수 있다는 보장은 없습니다.

97. 

    가이드라인 4.3(a) 디자인, 스팸 iOS 가이드라인 4.3 끝없는 심사

    신규 앱이 대기열에서 27일을 기다린 뒤 4.3(a) 스팸으로 거절됨

    무슨 일이 있었나

    한 개발자가 새로운 앱을 제출하고 App Review를 27일 동안 기다렸습니다. 마침내 App Store Connect에 결과가 떴을 때, 가이드라인 4.3(a) Design, Spam 항목으로 거절되었습니다. 개발자는 다른 개발자들에게 4.3(a) 거절을 극복해 본 사람이 있는지 물었습니다.

    해결

    게시 당시에는 해결책이 공유되지 않았습니다. 해당 개발자는 4.3(a)를 경험해 본 다른 이들의 조언을 구하고 있었습니다.

    교훈

    오래 기다린다고 해서 앱이 안전하다는 뜻은 아닙니다. 리뷰 대기열이 이렇게 느리면, 몇 주 뒤에 받는 4.3(a) 거절은 한 달이라는 시간을 통째로 날리는 셈입니다. 새 앱을 제출하기 전, 기존 카테고리 앱들과 무엇이 다른지 솔직하게 정리하고, 이를 리뷰 노트와 메타데이터에 명확히 기재하세요.

98. 

    가이드라인 4.3(a) 디자인, 스팸 macOS가 가이드라인 4.3

    iPhone 앱은 이미 출시된 상태였으나, Mac 버전이 스팸으로 거절되었습니다.

    무슨 일이 있었나

    한 개발자가 이미 App Store에 출시된 iPhone 앱을 기반으로 Mac용 Native Build 데스크톱 버전을 제작했습니다. 하지만 App Review 과정에서 가이드라인 4.3(a) 위반으로 거절되었습니다. 거절 사유는 해당 앱이 다른 개발자가 제출한 앱과 바이너리, 메타데이터 또는 컨셉이 매우 유사하며 차이점이 미미하므로, 독창적인 콘텐츠와 기능을 갖춘 고유한 앱을 제출하라는 내용이었습니다. 개발자는 커뮤니티에 4.3 이슈를 해결한 사례가 있는지 문의했습니다.

    해결

    게시 당시에는 해결 방법이 공유되지 않았습니다.

    교훈

    각 플랫폼은 별도의 리뷰 과정을 거치며, iPhone 앱이 승인되었다고 해서 Mac 앱까지 자동으로 승인되는 것은 아닙니다. 4.3(a) 메시지는 귀하의 앱을 타사 앱과 비교하는 것이므로, 답변 시 귀하의 앱이 유사한 앱들과 차별화되는 구체적인 기능과 독보적인 특징을 명확히 설명해야 합니다.

99. 

    끝없는 심사 iOS 끝없는 심사

    14일 이상의 리뷰 끝에 거절되었으며, 재제출 후에도 2주를 더 기다려야 했습니다.

    무슨 일이 있었나

    한 개발자는 이전 심사가 14일 넘게 걸렸고 결국 거절되었다고 합니다. 10월 21일에 다시 제출했지만, Apple은 보통 심사에 24~48시간이 걸린다고 함에도 불구하고 거의 2주가 지난 지금까지도 여전히 '심사 대기 중' 상태입니다.

    해결

    게시 시점 기준으로 여전히 심사 대기 중입니다.

    교훈

    평균 심사 시간은 최악의 상황을 반영하지 않으며, 거절되면 다시 느린 심사 대기열의 맨 끝으로 돌아가게 됩니다. 출시 계획은 몇 주 정도 여유를 두고 세우고, 첫 제출 시 최대한 완벽하게 준비하여 거절로 인해 대기 시간이 두 배로 늘어나는 일을 방지하세요.

100. 

     계정 삭제 요구 사항 (가이드라인 5.1.1(v)) iOS 가이드라인 5.1.1

     첫 번째 심사관이 여러 계정을 삭제한 후, 계정 삭제 기능 누락으로 거절됨

     무슨 일이 있었나

     사용자 생성 콘텐츠(UGC) 기반 앱을 개발하던 한 개발자가 계정 삭제 기능 누락을 이유로 두 번째 심사에서 거절되었습니다. 로그를 확인해 보니 첫 번째 심사 당시에는 리뷰어가 아무 문제 없이 여러 계정을 생성하고 삭제했던 것으로 나타났습니다. 개발자는 이 거절이 기능의 부재보다는 해당 카테고리에 대한 심사 기준이 엄격했기 때문이라고 느꼈습니다.

     해결

     게시 당시 별도의 해결책은 공유되지 않았습니다.

     교훈

     기능이 제대로 작동하더라도 리뷰어가 이를 빠르게 찾아낼 수 있어야 합니다. 계정 삭제 경로를 리뷰 노트에 명시하고, 클릭해야 할 정확한 화면과 짧은 녹화 영상을 첨부하세요. UGC 기반 앱의 경우 신고, 차단, 모더레이션 기능도 함께 보여주어야 합니다. 해당 카테고리는 심사가 매우 까다롭기 때문입니다.

본 페이지는 법적 조언이 아니며, 다음 앱 제출 시 Apple의 심사 결과를 예측하지 않습니다.