2026년 App Store 심사 통과 방법 (거절 피하는 법)

알고 싶다면 2026년 App Store 심사 통과 방법, 상황이 어떻게 달라졌는지부터 짚고 넘어가겠습니다. AI 코딩 도구 덕분에 반나절이면 앱을 빌드하고 제출할 수 있게 됐고, 실제로 많은 사람이 그렇게 했습니다. 개발자들은 App Store 심사가 너무 오래 걸린다고호소해 왔고, 이제 심사자들은 거의 똑같고 대충 vibe coding으로 만든 앱을 수없이 보고 있습니다. Apple은 심사 시간이 길어지고 있다는 주장을부인하고 있습니다. 어느 쪽이든, 심사자의 관심을 끌기 위해 여러분의 앱이 경쟁해야 하는 제출물의 양상은 달라졌습니다.

그래서 준비 방식도 달라져야 합니다. 웹사이트를 래핑한 앱 10개와 복제된 습관 트래커 5개를 막 검토한 심사자는 여러분 앱의 장점을 굳이 파고들지 않을 겁니다. 장점을 확실히 드러내야 합니다.

이 가이드의 핵심은 하나입니다: Apple이 심사해야 할 범위를 줄이는 것입니다. 네이티브 기능은 적게 출시하고 각각을 탄탄하게 만들며, 앱의 차별점이 한눈에 보이게 하세요. 이 접근법은 2026년 신규 앱에 가장 큰 타격을 주는 두 가지 리젝 사유를 커버합니다: 가이드라인 4.2 (Minimum Functionality) 및 가이드라인 4.3 (Spam).

2026년 App Store 심사가 유독 오래 걸리는 이유

현재 대기 시간에 대한 공식적인 수치는 공개되어 있지 않으므로, 특정 수치를 접할 때는 주의가 필요합니다. 현재 상황은 다음과 같습니다:

기존 팀을 포함한 많은 개발자들이 이전보다 “Waiting for Review” 상태가 더 길어지고 있다고 보고하고 있습니다.9to5Mac, Business Insider).
Apple의 입장은, 9to5Mac의 보도에 따르면,심사 시간이 길어지는 것이 아니며, 제출물의 90%를 48시간 이내에 처리하고 있다는 것입니다.
Apple의 자체 App Review guidelines에 따르면 복잡한 앱은 “더 정밀한 검토”가 필요할 수 있으며, “동일한 가이드라인 위반으로 반복해서 거절된” 앱은 심사 시간이 더 오래 걸릴 수 있습니다.

마지막 항목은 여러분이 직접 제어할 수 있는 부분입니다. App Store 심사에서 가장 느린 경로는 거절당했다가 다시 제출하는 것입니다. 거절될 때마다 대기열로 돌아갑니다. 따라서 목표는 첫 심사에서 통과하는 것입니다.

가장 빈번한 App Store 리젝 사유

Apple은 수치를 공개합니다. Apple의 2025 App Store 투명성 보고서에 따르면, Apple은 2,093,244건의 제출이 거절되었다고 보고합니다. 가이드라인 섹션별로는 Performance(1,354,418)가 Legal(495,673), Design(415,532), Business(283,820), Safety(151,159)보다 훨씬 많았습니다. 하나의 제출이 둘 이상의 섹션에서 거절될 수 있습니다.

Apple의 App Review 페이지 에서는 평균 40% 이상의 미해결 이슈가 다음 항목과 관련이 있다고도 밝힙니다: 가이드라인 2.1: 앱 완성도, 이는 크래시, 플레이스홀더 콘텐츠, 불완전한 정보를 다룹니다.

실무에서 개발자들이 가장 자주 마주치는 App Store 거절 사유는 다음과 같습니다:

2.1 앱 완성도: 크래시, 작동하지 않는 데모 계정, 응답 없는 백엔드, 플레이스홀더 콘텐츠.
5.1.1 데이터 수집 및 저장: 개인정보 처리방침 누락, 모호한 권한 요청 문구, 계정 삭제 기능 미비.
2.3 정확한 메타데이터: 앱과 일치하지 않는 스크린샷 또는 설명.
4.2 최소 기능 요구사항: “이건 그냥 웹사이트잖아요.”
4.3 스팸: “이미 존재하는 앱들과 다를 게 없네요.”

아래 체크리스트는 1~3번 항목을 다룹니다. 4번과 5번은 앱의 범위와 차별화가 중요한 항목이며, 이 가이드의 초점입니다.

스코프가 진짜 문제인 이유

제출하는 모든 기능은 리뷰어가 직접 열어보고, 테스트하고, 거절할 수 있는 대상입니다. 권한 프롬프트, 로그인 제공자, 인앱 결제, SDK를 추가할 때마다 더 많은 가이드라인이 적용됩니다:

소셜 로그인을 추가하면 가이드라인 4.8이 적용되므로, 이에 상응하는 개인정보 보호 친화적 로그인 옵션이 필요할 수 있습니다.
계정 생성 기능을 추가하면 5.1.1(v) 규정에 따라 앱 내 계정 삭제 기능도 반드시 제공해야 합니다.
위치 권한을 추가하면 사용 목적을 설명하는 purpose string이 필요하며, 권한을 거부한 사용자를 위한 대체 방안도 마련해야 합니다.
구독을 추가하면 3.1.2 전체가 적용되고, 2.1(b)의 IAP 검사도 받게 됩니다.
사용자 데이터를 서드파티 AI 서비스로 전송하면 5.1.2(i)에 따라 해당 사실을 공개하고 명시적인 동의를 받아야 합니다.

이 규칙들 중 불합리한 건 하나도 없습니다. 하지만 다 합쳐지면 부담이 커집니다: 검토 대상이 많아질수록 하나라도 실패할 확률이 높아지고,단 하나의 항목만 실패해도 빌드 전체가 거절됩니다.

따라서 첫 제출 전략은 명확히 유용하고, 네이티브답고, 분명히 여러분 것인 최소 버전의 앱으로 출시하는 것입니다. 승인 후에 키워나가면 됩니다.

가이드라인 4.2 최소 기능 미달 거절을 피하는 방법

가이드라인 4.2 는 웹 기반 앱과 웹 래퍼 앱에 가장 치명적인 규칙입니다:

앱은 단순히 웹사이트를 다시 포장한 수준을 넘어서는 기능과 콘텐츠, UI를 갖춰야 합니다. 앱이 특별히 유용하거나 독특하지 않거나 '앱답지' 않다면 App Store에 올릴 수 없습니다.

4.2.2항은 앱이 주로 '마케팅 자료, 광고, 웹 스크랩, 콘텐츠 애그리게이터 또는 링크 모음'이 되어서는 안 된다고 명시합니다. 또한 4.2.6항은 콘텐츠 제공자가 직접 제출하는 경우가 아니라면 '상용 템플릿이나 앱 생성 서비스로 제작된' 앱을 거절합니다.

흔한 실수는 4.2를 통과하려고 카메라, 연락처, 위치 정보, 햅틱, 공유 시트, 생체 인식 등 쓸 수 있는 모든 plugin을 한꺼번에 추가하는 것입니다. 그렇게 해도 앱이 네이티브하게 느껴지지는 않습니다. 오히려 초점이 흐려지죠. 게다가 각 plugin마다 별도의 permission prompt와 개인정보 보호 고지가 따라붙습니다.

여러분에게 필요한 것은 핵심 유스케이스에 실제로 필요한 한두 가지 네이티브 기능입니다., 리뷰어가 웹사이트가 왜 같은 일을 할 수 없는지 바로 알 수 있습니다.

채택하기 좋은 네이티브 기능들

네이티브 기능	왜 “앱처럼” 느껴지는가	주의할 점
푸시 알림	추가 단계 없이 잠금 화면에 적시에 사용자 관련 알림을 표시합니다. 웹사이트는 iOS 16.4+의 Web Push만 사용자가 홈 화면에 추가하고 권한을 허용한 뒤에만	4.5.4: 앱 작동에 푸시가 필수여서는 안 됩니다. 마케팅 푸시는 명시적 동의를 받아야 합니다.
카메라 / 문서 스캔	현실 세계를 담아내는 것은 모바일의 핵심 강점입니다	명확한 purpose string; 사진만 필요할 때는 시스템 피커 사용 (5.1.1(iii))
로컬 스토리지를 활용한 오프라인 모드	비행기나 지하에서도 앱이 동작합니다	리뷰어가 직접 트리거하고 확인할 수 있게 하세요
홈 화면 위젯	앱 밖에서도 한눈에 들어오는 가치	2.5.16: 위젯은 반드시 앱 콘텐츠와 기능과 연관되어야 합니다
HealthKit	피트니스와 건강을 위한 깊이 있는 OS 통합	2.5.1: 건강 목적으로 사용해야 하며, 5.1.3 건강 데이터 규칙은 엄격합니다
생체 인식 잠금 해제 (Face ID / Touch ID)	민감한 데이터를 위한 Native 보안	LocalAuthentication 사용 (2.5.13)
백그라운드 오디오, 지오펜싱, NFC, Bluetooth	브라우저에서 제공하지 않는 하드웨어 또는 OS 기능	2.5.4: 백그라운드 모드는 의도된 용도로만 사용

한두 가지 기능을 고르는 방법

각 후보 항목에 대해 세 가지 질문을 던져보세요:

이 기능이 없으면 핵심 사용자가 알아차릴까? 그렇지 않다면, v1에서는 제외하세요.
리뷰어가 데모 계정으로 1분 안에 작동을 확인할 수 있는가? 사용 후 3일이 지나야 나타나는 기능이라면 리뷰 통과에 도움이 되지 않습니다.
민감한 가이드라인 영역을 건드리고 있지는 않은가 (건강, 아동, 결제, 위치 추적, 사용자 생성 콘텐츠)에 해당하나요? 그렇다면 앱의 핵심일 때만 추가하세요.

몇 가지 예시:

현장 점검 도구: 카메라 촬영과 오프라인 동기화. 연락처와 소셜 로그인은 건너뛰세요.
복약 알림: 로컬 알림과 다음 복용량을 보여주는 위젯. HealthKit은 엄격한 건강 데이터 규정이 따르므로 필요할 때까지 미루세요.
팀 상태 대시보드: 장애 알림용 푸시 알림과 Face ID 잠금 해제. 이 정도면 충분합니다.

앱의 핵심인 잘 만든 네이티브 기능 2개가 어설프게 통합된 8개보다 4.2 대응에 훨씬 강력한 답입니다.

가이드라인 4.3 Spam 통과 방법: 확실히 차별화하고, 그 사실을 맨 위에 명시하세요.

AI 지원 앱이 걸리는 두 번째 규칙은 4.3 (스팸), 및 4.1 (모방 앱). 4.3(b)는 직설적입니다:

이미 널리 퍼져 있는 앱과 구분이 불가능한 앱은 제출하지 마세요.

Apple은 데이팅, 손전등, 효과음, 배경화면, 단순 타이머, 운세 등 포화 상태로 보는 카테고리를 명시합니다. 해당 카테고리에서는 “실질적으로 다르거나 개선된 경험을 제공하지 않는 한” 새 제출을 받지 않겠다고 밝힙니다.

개발자들은 또한 다음과 같은 사례를 보고합니다. “Guideline 4.3(a) - Design - Spam” 거절 사례 앱의 바이너리, 메타데이터 또는 컨셉이 다른 개발자의 앱과 유사하다는 내용입니다. 앱이 흔한 프롬프트나 스타터 템플릿에서 생성됐다면, 리뷰어가 이미 비슷한 앱을 봤다고 가정해야 합니다.

4.3 Spam 사유로 우리가 겪은 일

우리 Capgo에서도 이 규칙에 직접 걸린 적이 있습니다. 동일한 앱 셸을 기반으로 구조와 화면은 같고 콘텐츠만 다른 여러 앱을 만들었습니다. 그리고 그 앱들을 모두 동시에 심사에 올렸습니다.

Apple 입장에서는 한 개발자 계정이 거의 동일한 바이너리 묶음을 한꺼번에 대기열에 넣는 전형적인 스팸 팜(spam farm)처럼 보였을 것입니다. 결국 앱들은 4.3 Spam으로 플래그가 지정됐고, 이 상황을 피하는 것보다 빠져나오는 데 훨씬 더 많은 노력이 들었습니다.

지금 우리가 하는 방식이자 권장하는 방법은 다음과 같습니다:

앱 간 앱 셸 공유 금지. 두 앱의 레이아웃, 네비게이션, 화면 구성이 같고 콘텐츠만 다르다면 Apple은 같은 앱을 두 번 제출한 것으로 봅니다. 각 앱에는 고유한 구조와 UX, 그리고 존재해야 할 이유가 있어야 합니다. 콘텐츠만 다르다면 그 콘텐츠를 담은 앱 하나로 출시하세요.
일괄 제출 금지. 여러 앱을 동시에 심사에 올리지 마세요. 특히 같은 계정의 신규 앱이라면 더욱 그렇습니다. 하나를 제출해 승인을 받은 뒤, 간격을 두고 다음 앱을 제출하세요.
거의 중복되는 메타데이터 금지. 앱마다 이름, 설명, 스크린샷, 키워드가 달라야 합니다. 단어만 바꾼 템플릿을 돌려쓰지 마세요.
실제 제품당 앱 하나. 도시, 고객, 니치별 변형은 각각이 정말 다른 제품이 아니라면 선택 기능이 있는 하나의 앱에 넣으세요.

이 4.3(a) 문구는 이를 분명히 말합니다: “동일한 앱에 대해 여러 개의 Bundle ID를 생성하지 마세요.” 특정 지역, 스포츠 팀, 대학교 등을 위한 여러 버전이 있다면 “하나의 앱을 제출하고 인앱 결제로 변형 버전을 제공하는 것을 고려하세요.” 반복적인 스팸은 앱 하나가 아니라 개발자 계정 전체를 위험에 빠뜨릴 수 있습니다.

진짜 강점을 찾으세요

엣지(Edge)는 메인 키워드 검색 결과 상위 5개에서는 얻을 수 없고, 여러분의 앱에서만 얻을 수 있는 구체적인 무언가입니다. 예:

범용 앱이 외면하는 특정 사용자층(예: '모두'가 아닌 '교대 근무자')
다른 앱이 지원하지 않는 워크플로우(예: 기존 하드웨어나 데이터 소스와 연동)
다른 앱이 해결하지 못하는 제약 조건(offline-first, privacy-first, 계정 불필요)
제품에 녹아든 도메인 지식(예: 실제 직업의 규칙, 템플릿, 데이터)

2026년에는 '깔끔한 디자인'과 'AI 기반'은 엣지가 아닙니다. 모든 클론 앱이 둘 다 내세우니까요.

App Store 설명 첫 줄에 엣지를 넣으세요.

심사자와 사용자 모두 App Store 설명의 맨 위부터 읽습니다. 이 부분으로 한 가지 질문에 답하세요: 다른 앱이 이미 있는데, 이 앱은 왜 존재하는가?

약한 도입부:

최고의 생산성 앱, FocusFlow를 소개합니다! 아름답고 사용하기 쉬운 타이머로 집중력을 유지하고, 더 나은 습관을 만들며, 목표를 달성하세요. AI 기반입니다.

이 문구는 이미 스토어에 있는 수십 개 앱을 설명할 수 있습니다. 4.3(b)가 직접 명시하는 '단순한 타이머(simple timer)'인 셈이죠.

강력한 도입부:

FocusFlow는 야간 근무 간호사를 위한 집중 타이머입니다. 12시간 교대 근무에 맞춰 휴식 시간을 예약하고, 병원 내 통신 음영 지역에서도 오프라인으로 완벽하게 작동하며, 잠금 화면 위젯으로 다음 휴식 시간을 알려주어 병동에서 휴대폰을 잠금 해제할 필요가 없습니다.

단 두 문장만으로 리뷰어는 타겟 사용자, 해결하려는 문제, 그리고 네이티브 기능(오프라인, 위젯)을 파악할 수 있습니다. 단순한 클론 앱이 아닌 실제 제품처럼 느껴집니다.

그다음에는 App Review notes에서 이를 뒷받침하세요. 앱이 누구를 위한 것인지, 무엇이 차별점인지, 네이티브 기능을 정확히 어디서 찾을 수 있는지 두세 문장으로 작성하세요. 2.3.1(a) 2.3.1(a)는 새로운 기능을 “Notes for Review 섹션에 구체적으로 설명해야 하며” “일반적인 설명은 거부된다”고 명시합니다. 리뷰 노트를 짧은 가이드 투어처럼 활용하세요.

2026년 App Store 심사 체크리스트

이 내용 대부분은 Apple의 “제출 전 확인 사항” 섹션과 가이드라인 2에서 가져온 것입니다. 매 제출 전에 꼼꼼히 확인하세요:

체크하지 않은 항목은 거절로 이어질 가능성이 높고, 거절되면 심사 대기열에서 또 기다려야 합니다.

App Store에서 거절되었다면? 답변 및 이의 신청 방법

그래도 거절되었다면, Apple의 가이드라인 두 가지 옵션을 설명합니다:

App Store Connect에서 답변하기. 메시지의 전반적인 어조가 아니라, 인용된 가이드라인에 정확히 답변하세요. 4.2 또는 4.3 항목이라면 더 구체적으로: 앱이 누구를 위한 것인지, 어떤 native 기능이 있는지, 어디서 찾을 수 있는지, 리뷰어가 비교할 만한 다른 앱과 무엇이 다른지를 명시하세요. 앱의 짧은 화면 녹화 영상도 도움이 됩니다.
이의 신청 제출 리뷰어의 판단이 잘못됐다고 생각된다면 App Review Board에 이의를 제기하세요.

단계별 절차는 다음 가이드를 참고하세요: App Store 거절에 대응하는 방법.

둘 중 하나를 하기 전에, 실제 원인이 있다면 먼저 고치세요. 4.3 항목으로 지적된 경우 스크린샷만 바꾸는 건 대개 도움이 되지 않습니다. 타겟 사용자를 좁히고 앱과 설명란에서 차별점을 드러내는 것이 효과적입니다.

이미 출시된 앱의 경우, Apple은 법적 또는 안전 문제가 아닌 한 가이드라인 위반 때문에 버그 수정 제출이 지연되지는 않는다고 밝히고 있습니다. App Store Connect에서 이를 요청하고, 다음 제출에서 해당 문제를 해결하겠다고 약속하세요.

왜 Capacitor, React Native, Cordova 앱이 더 수월하게 통과할까요?

이 부분은 통계가 아닌 제 개인적인 경험입니다. Capgo을 통해 Capacitor 앱을 배포하는 여러 팀과 React Native, 오래된 Cordova 프로젝트를 함께 작업하면서, 크로스 플랫폼 앱이 예상보다 마찰 없이 App Store 리뷰를 통과하는 경향을 봤습니다. 그 이유는 다음과 같습니다:

Native 레이어가 얇고 표준적입니다. 이 앱들은 카메라, 푸시, 스토리지, 생체 인식에 널리 쓰이는 잘 알려진 플러그인을 사용합니다. 리뷰어들은 이런 통합을 늘 접하며 동작도 예측 가능합니다.
네이티브 scope는 자연스럽게 작습니다. 플러그인을 의도적으로 하나씩 추가하므로, 앞서 말한 “한두 개의 실제 네이티브 기능” 접근 방식과 맞아떨어집니다.
앱은 프레임에 URL만 띄운 것이 아니라 실제 제품입니다. Capacitor 앱은 HTML, CSS, JavaScript를 바이너리 안에 포함해 로컬에서 로드하고, 그 위에 네이티브 플러그인을 얹습니다. 웹사이트를 가리키는 웹 래퍼와는 다르며, 4.2가 바로 그 웹 래퍼를 겨냥합니다.

하지만 크로스 플랫폼이 지름길은 아닙니다. 마케팅 사이트만 담은 Capacitor 앱은 다른 웹 래퍼처럼 거절됩니다. 프레임워크는 scope 규칙을 따를 때만 도움이 됩니다.

첫 심사가 가장 어렵습니다. 업데이트는 여전히 까다롭습니다.

첫 승인이 가장 큰 고비입니다. Apple이 앱의 콘셉트 전체를 심사하기 때문입니다. 하지만 업데이트도 같은 대기열을 거칩니다. 오타 수정, 버튼 오류, 문구 변경도 계속 대기할 수 있고, 이번에 리뷰어가 발견한 무관한 문제로 업데이트가 거절될 수도 있습니다.

그래서 많은 팀이 이렇게 나눕니다. 네이티브 릴리스 과 웹 레이어 릴리스.

Apple 규정을 지키는 라이브 업데이트

Apple의 해당 규정은 Apple Developer Program 라이선스 계약섹션 3.3.1(B) “Executable Code”에 명시되어 있습니다. 현재 문구는 다음과 같습니다:

다음 단락에 명시된 경우를 제외하고, 애플리케이션은 실행 가능한 code를 다운로드하거나 설치할 수 없습니다. 해석된 code는 애플리케이션에 다운로드할 수 있지만, 해당 code가 다음 조건을 충족하는 경우에만 가능합니다: (a) 애플리케이션의 의도된 목적 및 광고된 목적과 일치하지 않는 기능이나 동작을 제공하여 애플리케이션의 주요 목적을 변경하지 않아야 함 (b) OS의 서명, 샌드박스 또는 기타 보안 기능을 우회하지 않아야 함; (c) App Store를 통해 배포되는 애플리케이션의 경우, 다른 애플리케이션을 위한 스토어 또는 스토어프론트를 생성하지 않아야 함.

App Review 가이드라인 2.5.2 은 심사 측 규정입니다: 앱은 “앱의 기능이나 동작을 도입하거나 변경하는 code를 다운로드, 설치 또는 실행할 수 없습니다.” 이 두 규정을 함께 읽으면 기준이 명확해집니다. JavaScript, HTML, CSS는 해석된 code입니다. 이를 업데이트하는 것은 허용됩니다 단, 앱이 Apple이 심사한 앱 그대로여야 합니다.

실제로 라이브 업데이트는 다음과 같은 경우에 적절합니다:

JavaScript, HTML 또는 CSS의 버그 수정
UI, 문구, 레이아웃 또는 콘텐츠 조정
동작을 바꾸지 않고 심사된 기존 기능 개선

새로운 기능이나 기존 기능의 동작 방식이 변경되는 경우, 반드시 리뷰를 거친 바이너리로 배포해야 합니다.

그리고 다음과 같은 경우에 하지 마세요 리뷰가 필요합니다:

앱의 목적을 변경할 때. 메모 앱이 카지노 앱이 되지는 않습니다.
가격, 프로모션 또는 결제 방식을 변경할 때. 비즈니스 모델 변경은 리뷰 대상입니다 (3.1 및 2.3 참조).
기만적인 행위를 할 때 사용자가 다운로드한 후 숨겨진 기능, 미끼 상품으로 유인하는 행위, 리뷰어가 본 적 없는 콘텐츠 (2.3.1(a), 5.6).
네이티브 code를 변경하거나,플러그인을 추가하거나 새 권한을 요청하는 경우입니다. 이 경우에는 새 바이너리가 필요합니다.

이 제한 범위 안에서 live update 도구를 쓰면 매번 리뷰를 기다리지 않고 작은 변경 사항을 배포할 수 있습니다. 바로 이것이 Capgo Capacitor 앱에 해 주는 일입니다. CI에서 새 web bundle을 업로드하면 기기들이 백그라운드에서 다운로드하고, 문제가 생기면 해당 채널에서 이전 bundle을 즉시 다시 활성화할 수 있습니다. 기기는 다음 업데이트 확인 때 롤백을 적용합니다. 정책 관련 내용은 다음을 참고하세요: Apple은 live updates를 허용하나요?.

자주 묻는 질문

2026년 App Store 리뷰는 얼마나 걸리나요?

Apple은 제출물의 90%를 48시간 이내에 처리한다고 밝히고 있습니다(9to5Mac 보도에 따르면). 다만 2026년에는 훨씬 오래 기다린다는 개발자들도 있습니다. 믿을 만한 공개 트래커가 없으니 변동성을 감안해 계획을 세우고, 매번 대기 시간을 늘리는 리젝은 피하세요.

App Store 리뷰가 왜 이렇게 오래 걸리나요?

제출 건수 증가, 복잡하거나 민감한 앱(의료, 금융, 아동, 결제), 반복된 리젝 이력은 모두 리뷰를 늦출 수 있습니다. Apple 가이드라인에 따르면 복잡한 앱은 더 엄격한 검토가 필요할 수 있고, 반복 위반은 더 오래 걸립니다. 마감이 급하면 expedited review를 요청할 수 있지만, Apple은 정말 필요할 때만 쓰라고 권합니다.

App Store 리젝의 가장 흔한 원인은 무엇인가요?

가이드라인 2.1, 앱 완성도. Apple에 따르면 평균적으로 해결되지 않은 이슈의 40% 이상이 이 항목과 관련이 있습니다. 크래시, 플레이스홀더 콘텐츠, 불완전한 정보, 작동하지 않는 데모 계정 등입니다.

가이드라인 4.2 Minimum Functionality 거절은 어떻게 해결하나요?

앱의 핵심 사용 사례에 필요한 네이티브 기능(푸시 알림, 카메라, 오프라인 모드, 위젯, HealthKit, 생체 인식)을 한두 개 넣고, 리뷰어가 데모 계정으로 바로 확인할 수 있게 하세요. 리뷰 노트에는 어디서 찾을 수 있는지 설명하세요. 웹사이트를 프레임에 담아 제출하지 마세요.

가이드라인 4.3 Spam(또는 4.3(a) Design - Spam)을 어떻게 통과하나요?

스토어에 이미 있는 앱과 구체적이고 검증 가능한 차이(특정 타겟층, 워크플로우, 제약 사항)를 보여주세요. App Store 설명 첫 두 줄과 리뷰 노트에 이를 명시하고, 남아 있는 템플릿이나 보일러플레이트 화면은 제거하세요. 여러 앱에 같은 앱 셸을 재사용하거나 비슷한 앱을 동시에 여러 개 제출하지 마세요. 그런 다음 App Review에 구체적인 근거를 들어 답변하세요.

App Store 거절에 이의를 제기할 수 있나요?

네. App Store Connect에서 App Review에 답변하거나 App Review Board에 항소할 수 있습니다. 형용사가 아닌 사실로, 인용된 가이드라인에 정확히 답변하세요.

웹 래퍼 앱도 App Store에 출시할 수 있나요?

웹사이트를 그대로 감싼 래퍼 앱은 보통 4.2로 거절됩니다. Capacitor로 빌드해 웹 code을 로컬에 번들링하고 실제 네이티브 기능을 쓰는 앱은 다릅니다. 유용하고 차별점이 분명하다면 통과할 수 있습니다.

Apple이 라이브 업데이트를 허용하나요?

네, 제한된 범위 내에서 가능합니다. DPLA 3.3.1(B)는 앱의 주요 목적을 바꾸거나 OS 보안을 우회하거나 다른 앱을 위한 스토어프런트를 만들지 않는 한, 다운로드된 인터프리터 방식의 code(JS, HTML, CSS)를 허용합니다. 라이브 업데이트로 가격이나 프로모션을 바꾸거나, 네이티브 code를 추가하거나, 기만적인 행위를 해서는 안 됩니다.

요약

심사 대상 범위를 최소화하세요. 분명히 유용한 가장 작은 앱으로 출시하세요.
핵심 유스케이스에 꼭 필요하고, 심사자가 1분 안에 확인할 수 있는 네이티브 기능을 한두 개 선택하세요.
App Store 설명의 첫 두 줄과 심사 메모에서 강점을 보여주세요.
하나의 셸에서 여러 앱을 배포하거나 한꺼번에 제출하지 마세요. 이는 4.3 Spam 플래그를 받는 가장 빠른 방법입니다.
체크리스트 실행하기 매번 제출 전에 확인하세요. 하나라도 건너뛰면 전체 대기 시간을 한 번 더 감수해야 할 수 있습니다.
승인 후에는 네이티브 릴리스를 최소한으로, 신중하게 진행하고, 웹 레이어 수정은 규정을 준수하는 라이브 업데이트로 배포하세요.

Capacitor로 개발 중이고 작은 수정마다 심사를 기다리는 걸 그만두고 싶다면, Capgo를 사용해 보세요.. 라이브 업데이트를 한 번 설정해 두고, App Store 제출은 실제 네이티브 변경에만 사용하세요.