App Store 심사 기간: 실제 결정 64건, 중앙값 73시간

요약: 제 개발자 계정이 지금까지 받은 App Review 결정 이메일을 전부 모았습니다. 2026년 9월 10일부터 10월 12일까지 iPhone 앱 21개에 대한 결정 64건이며, 각 건마다 Apple이 직접 찍은 "Submitted" 타임스탬프와 결정이 도착한 시각이 있습니다. 대기 시간의 중앙값은 73시간이었습니다. Apple 페이지에는 "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours"(제출의 최소 50%는 24시간 이내, 90%는 48시간 이내)를 심사한다고 적혀 있습니다. 제 경우는 24시간 이내 19%, 48시간 이내 27%였습니다. 이미 스토어에 있는 앱의 업데이트는 중앙값 64시간, 인앱 결제만 단독으로 낸 경우는 12시간이 걸렸고, 새 앱 21개 중 첫 제출에 승인된 앱은 0개였습니다.

검색으로 오신 분을 위한 짧은 답입니다. 2026년에 출시를 계획한다면 업데이트는 심사 라운드당 3일, 완전히 새로운 앱의 승인은 2~5일로 잡고, 새 계정의 새 앱이라면 최소 한 라운드를 더 잡으세요. 첫 라운드는 보통 질문과 함께 돌아오기 때문입니다. 일주일씩 걸리는 심사는 느린 승인이 아닙니다. 제 데이터에서 5.1일을 넘긴 대기는 단 한 건을 빼고 모두 가이드라인 4.3 스팸 리젝으로 끝났습니다.

아직 "비용이 얼마나 들까" 단계라면, 무료 iPhone 앱 비용 계산기가 기능을 시간과 금액으로 바꿔 줍니다. 이 글은 어떤 계산기도 보여 주지 않는 부분, 즉 "Submit"과 "Ready for Distribution" 사이의 달력상 시간에 관한 글입니다. 저는 이 앱들을 Mac 없이 Windows PC에서 만들기 때문에(파이프라인은 여기), 아래의 모든 제출은 Xcode가 아니라 CI 작업이나 App Store Connect 웹사이트에서 나갔습니다.

2026년 App Store 심사는 얼마나 걸릴까?

실제로 마주치게 될 방식대로 나눈 숫자입니다. "대기"는 Apple 이메일의 "Submitted" 줄부터 결정 이메일이 도착한 순간까지의 시간이므로, 심사자가 앱을 본 몇 분만이 아니라 대기열 시간까지 포함합니다.

제출 내용	결정 수	대기 중앙값	최단	최장	승인
인앱 결제만	5	12.2시간	11.7시간	13.4시간	5건 중 5건
출시된 앱의 업데이트	16	64.4시간	6.3시간	203.6시간	16건 중 11건
새 앱(일반 라운드)	21	51.2시간	3.1시간	120.5시간	21건 중 8건
새 앱(4.3 스팸 묶음 두 번)	22	187.8시간	167.7시간	223.3시간	22건 중 0건
전체	64	73.1시간	3.1시간	223.3시간	64건 중 24건

두 가지가 눈에 띕니다. 새 앱에 대한 리젝과 질문은 빨리 돌아옵니다(일반 라운드 13건의 중앙값은 27.8시간). 심사자가 첫 번째 문제에서 멈추기 때문입니다. 승인은 더 오래 걸립니다. 첫 버전 승인 8건의 중앙값은 69.9시간이었고, 48시간 안에 돌아온 건은 하나도 없었습니다. 그러니 통계적으로 보면 빠른 답장은 나쁜 소식입니다.

실험: 이메일 한 통당 타임스탬프 한 쌍

App Store Connect는 심사 소요 시간 기록을 보여 주지 않습니다. 대신 받은편지함이 보여 줍니다. Apple이 보내는 모든 결정 이메일은 모양이 같습니다. 제목은 "Review of your App (iOS) submission is complete." 또는 "There's an issue with your App (iOS) submission." 중 하나이고, 본문에는 Submitted: Oct 08, 2026 at 03:48 PM Pacific Daylight Time 같은 줄이 있습니다. 이메일 자체의 발송 시각이 결정 시각입니다. 데이터셋은 이게 전부입니다.

2026년 10월 17일, Gmail에서 검색 연산자 쿼리 하나 from:no_reply@email.apple.com newer_than:60d로 검색했습니다. 스레드 69개가 나왔고 그중 64개가 결정 이메일입니다(나머지 5개는 App Store Connect 환영 메일, API 접근 승인, "Welcome to the App Store" 안내 2통, "Thank you for submitting" 1통). 계정은 9월 10일에 열었으므로 이건 표본이 아니라 전체 기록입니다. 그다음 파싱입니다.

# media/deepdive/review-time/analyze.py (trimmed)
PT = timezone(timedelta(hours=-7))  # Pacific Daylight Time, as printed in Apple's emails

def sub_dt(s):  # "Oct 08 03:48 PM" from the email body
    return datetime.strptime("2026 " + s, "%Y %b %d %I:%M %p").replace(tzinfo=PT)

for e, app, out, sub, by, kind in ROWS:
    s = sub_dt(sub); d = utc(e)          # e = the email's sent time, UTC
    h = (d - s).total_seconds() / 3600   # hours from Submitted to decision
    recs.append(dict(app=app, outcome=out, kind=kind, hours=round(h, 2), ...))

각 행에는 제출 내용에 따라 새 앱의 첫 버전, 업데이트, 인앱 결제 단독 중 하나로 태그를 붙였습니다. 이 정보는 앱 자체의 기록(저장소 커밋 기록과 제 메모)에서 가져왔고, 애매한 묶음은 항목이 나열된 이메일 본문과 대조했습니다. 예를 들어 Chain의 10월 8일 밤 제출은 앱 버전 없이 In-App Purchases (6)만 적혀 있습니다. 리젝 사유는 이메일에 전혀 나오지 않기 때문에(본문에는 "We noticed an issue"라고만 쓰여 있습니다), 사유는 제가 저장해 둔 Resolution Center 텍스트와 제가 보낸 답장에서 가져왔습니다.

이 방법으로 볼 수 없는 것도 있습니다. 결정 전에 취소한 제출(이메일이 없으니 행도 없음), 그리고 심사자가 앱을 연 정확한 순간입니다. "대기 시간"이 아니라 "심사 중인 시간"을 알고 싶다면 App Store Connect API가 버전 상태를 알려 주지만 이력은 주지 않으므로, 직접 주기적으로 조회해야 합니다.

Apple의 24시간 숫자와 제 숫자

Apple의 표현은 신중합니다. 제출의 절반을 24시간 안에 심사한다고 말합니다. 이 말이 사실이면서도 체감과는 다를 수 있는데, 제 데이터에 나타난 이유는 세 가지입니다.

첫째, 시계는 대기열에서부터 돌아갑니다. 제 승인들은 거의 정확히 같은 경과 시간에 몰려 있습니다. 업데이트 16건 중 7건이 63.5시간에서 64.5시간 사이에 결정되었는데, 9월 26일 토요일 아침에 함께 제출되어 태평양 시간 월요일 밤 늦게 32분 안에 함께 결정되었기 때문입니다. 심사 자체가 얼마나 걸렸든, 대기 시간은 대기열이 언제 그 제출에 도달하느냐로 정해졌습니다.

둘째, Apple은 적어도 제 건에 대해서는 토요일에 새 결정을 내리지 않는 것으로 보입니다. 결정 64건을 태평양 시간 요일별로 보면 월요일 35, 금요일 10, 목요일 7, 수요일 5, 일요일 4, 화요일 3, 토요일 0입니다. 월요일 숫자는 스팸 묶음 두 번(결정 22건) 때문에 부풀려졌지만, 그걸 빼도 토요일에 온 결정은 없습니다. 그러니 App Review가 일요일에 일하는 건 맞지만(일요일 결정 4건 중 2건이 승인이었습니다), 토요일 아침에 낸 제출은 여전히 월요일 밤까지 기다렸습니다.

셋째, 느린 꼬리는 무작위가 아닙니다. 4.3 묶음 두 번을 빼면 제 숫자는 Apple의 숫자에 훨씬 가까워집니다. 24시간 이내 29%, 48시간 이내 40%입니다. 스팸 리젝 22건은 각각 7~9.3일이 걸렸습니다. 긴 대기는 운이 나쁜 게 아니라 신호였습니다.

빠른 길은 인앱 결제입니다. 인앱 결제만 담은 제출 5건(출시된 앱 5개의 새 테마와 팩, 10월 8일 목요일 밤늦게 API로 보냄)은 11.7~13.4시간 뒤에 서로 95분 간격 안에서 모두 승인되었습니다. 새 가격대나 팩을 빨리 내야 한다면 바이너리는 건드리지 말고 별도 제출로 내세요.

새 앱: 21개 중 첫 시도에 승인된 앱은 0개

21개 앱 모두 첫 제출이 돌아왔습니다. 무섭게 들리지만 사유를 읽어 보면 다릅니다. 첫 라운드 이메일 21통 중 10통은 가이드라인 2.1 "Information Needed"(나머지 11통은 아래의 스팸 묶음)였습니다. 새 개발자 계정이 받는 일상적인 질문입니다. 기기에서 앱이 동작하는 화면 녹화를 보내고, 주요 기능을 설명하고, 로그인이 필요한지 밝히고, 외부 서비스를 나열하라는 것입니다. Apple 가이드라인은 이 정보를 처음부터 요구하지만, 계정이 새것이면 심사자가 어차피 다시 묻습니다.

효과가 있었던 해결책은 심사 메모를 형식적인 절차로 여기지 않는 것이었습니다. 이제 모든 앱에는 파이프라인이 App Store Connect 심사 정보에 넣어 주는 Store/review-notes.md가 들어 있습니다. 심사자가 1분 안에 따라 할 수 있는 안내서처럼 쓰고, 유료 화면마다 어떻게 들어가는지까지 적었습니다.

# chain/Store/review-notes.md (trimmed)
No account, login or network connection is required.

IN-APP PURCHASES (StoreKit 2, all optional, Restore in Settings):
- Chain Unlimited (existing non-consumable): add three habits, tap New habit again; ...
- Streak Repair, $0.99 consumable: when a chain of 2+ days breaks, Today shows a
  "chain broke" banner and the rescue sheet opens. ... To see it on a fresh install:
  add a habit, open Week, tick the two days before yesterday, leave yesterday empty,
  then relaunch.

PRIVACY: no data is collected. No accounts, analytics, ads or third-party SDKs.

첫 2.1 라운드 후 Chain, Ironbook, Quiver는 9월 22일 태평양 시간 오전 4:21에 답변과 화면 녹화를 붙여 다시 제출되었고, 셋 다 51~67시간 뒤에 승인되었습니다. 스토어에 오른 앱 8개를 보면, 맨 처음 제출부터 첫 승인까지 걸린 시간의 중앙값은 4.4일(범위 3.75~7.2일)이었습니다. 새 계정의 새 앱이라면 출시 계획에 넣어야 할 정직한 숫자는 24시간이 아니라 근무일 기준 일주일에 가깝습니다.

나머지 첫 라운드 사유도 알아 둘 만합니다. 하나하나 적은 비용으로 막을 수 있기 때문입니다.

• 5.1.1 개인정보, 같은 앱에서 두 번. 만화 같은 눈이 사용자의 얼굴을 따라가는 집중 타이머 Minder(눈 애니메이션은 이 SwiftUI 글에 있습니다)는 어떤 얼굴 데이터를 수집하고, 보관하고, 공유하는지 정확히 밝히라는 요구를 받았습니다. 답(Apple의 온디바이스 Vision 프레임워크에서 나온 x/y 위치 하나, 절대 저장하지 않음)은 답장만이 아니라 개인정보 처리방침에도 들어가 있어야 했습니다. 일주일 뒤에는 개인정보 처리방침 URL 자체가 열리지 않아 다시 리젝되었습니다. 호스팅을 고치고 이메일을 받은 지 6분 만에 다시 제출했고, 24.8시간 뒤에 승인되었습니다.
• 1.4.1, 건강 관련 주장에는 출처가 필요합니다. Race Fuel은 지구력 레이스를 위한 탄수화물, 수분, 나트륨 목표치를 알려 줍니다. 가이드라인 1.4.1은 의료에 가까운 숫자에는 인용 근거를 요구합니다. 해결책은 DOI 링크가 걸린 논문 7편을 담은 출처 화면과, 모든 수치 아래에 단 링크였습니다.

가이드라인 4.3: 일주일의 침묵, 그리고 30초 만의 리젝 11건

제 앱 11개(자동차 정비 기록, 주차 타이머, 집 물품 목록, 장보기 가격 기록, 반려동물 투약 기록, 집안일 표, 팁 기록, 성적 계산기, 볼더링 기록, 러닝 페이스 계산기, 카페인 컷오프 계산기)가 9월 26일에 제출되었습니다. 이 앱들은 8.7~9.3일 동안 대기열에 머물렀습니다. 그리고 10월 5일 월요일, 리젝 이메일 11통이 미 동부 시간 오후 5:29:32부터 5:30:02 사이에 모두 도착했습니다. 모든 앱에 같은 문구였습니다. 가이드라인 4.3 스팸과 4.2.6, 즉 템플릿이나 앱 생성 서비스로 만든 앱이라는 내용에, 답해야 할 질문 9개가 붙어 있었습니다. Resolution Center의 모든 메시지 타임스탬프는 오후 5:29였습니다.

리젝 문구는 다음에 할 일을 분명히 말했습니다. 앱이 이미 가이드라인을 지킨다고 생각한다면 다시 제출하지 말고, 메시지에 답장해서 질문 9개에 모두 답하라는 것이었습니다. 저는 하나하나 답장했고(공개 베타 없음, 자동화된 Simulator 실행으로 테스트함, 공유하는 StoreKit 결제 클래스와 테스트 드라이버가 있음을 밝힘), 11개 모두 App Review Board 이의 신청을 넣었으며, 같은 날 오후에 11개를 모두 다시 제출하기도 했습니다. 재제출이 실수였습니다. 7일 뒤인 10월 12일 월요일, 리젝 11통이 27초 안에 다시 도착했고, 각각 재제출 후 정확히 7.0일 만이었습니다.

출시를 준비하는 입장에서 데이터가 4.3에 대해 말해 주는 것은 다음과 같습니다.

• 대기 시간이 단서입니다. 제 데이터에서 5.1일을 넘긴 심사는 한 건을 빼고 모두 4.3 리젝이었습니다. 예외는 Clear the Strait 1.1.1로, 심사자가 질문한 뒤 게임이 어떻게 동작하는지 길게 쓴 설명과 함께 다시 제출한 건이었는데, 8.5일이 걸려 승인되었습니다.
• 판단은 앱 단위가 아니라 개발자 단위로 내려집니다. 두 묶음 모두 30초 안에 도착했습니다. 심사가 어떤 방식이었든, 앱 11개에 대한 별도의 심사 11번은 아니었습니다.
• 바꾸지 않은 채로 다시 제출하지 마세요. Apple의 이메일 자체가 실질적인 변경 없는 재제출은 다시 리젝된다고 했습니다. 실제로 7일 주기로 다시 리젝되었고, 라운드마다 일주일을 잃었습니다.

앞서 저는 이 앱들이 Swift 코드를 실제로 얼마나 공유하는지 측정했습니다. 계정의 나머지 앱과 겹치는 비율의 중앙값은 34.5%였고, 계정에서 가장 비슷한 두 앱(골프 일지와 테니스 일지)은 둘 다 스토어에 올라 있습니다. 코드 유사도만으로는 누가 걸렸는지 설명되지 않았습니다. 숫자는 iPhone 앱 비용 글에 있습니다. 제 해석이라는 전제로 말하자면, 새 계정 하나에서 같은 날 아침에 제출된 단일 목적 유틸리티 11개는 화면이 얼마나 다르든 대기열에서는 앱 공장처럼 보입니다. 작은 앱 아이디어가 여러 개라면 하나를 먼저 내서 리뷰와 업데이트를 쌓은 뒤 나머지는 간격을 두고 내거나, 인앱 결제가 있는 앱 하나로 합치세요. 가이드라인 4.3(a)가 권하는 방법이 정확히 이것입니다.

전체 일정을 한 장으로

달력으로 보면 패턴이 뚜렷합니다. 처음 2주는 짧은 빨간 막대(빠른 2.1 질문) 뒤에 2~5일짜리 초록 막대가 옵니다. 9월 26일부터 계정은 둘로 나뉩니다. 이미 출시된 앱들은 약 64시간 만에 업데이트가 통과되고, 새 유틸리티 11개는 매번 같은 30초 구간에서 끝나는 긴 빨간 막대 두 개에 갇힙니다.

승인 후: 몇 분 만에 출시

이메일에는 승인된 항목이 노출되기까지 "it can take up to 24 hours"(최대 24시간이 걸릴 수 있음)라고 쓰여 있습니다. 제 출시 앱 8개는 공개 출시 타임스탬프가 훨씬 빨리 찍혔습니다. 개발자가 스토어에 올린 모든 앱의 currentVersionReleaseDate를 돌려주는 Apple의 iTunes Search API에서 읽었습니다.

# every app on the account, with the release time of its current version
curl -s "https://itunes.apple.com/lookup?id=6810582483&entity=software&country=us"

승인 이메일과 비교하면 출시 시각은 앱 8개 모두 승인 후 0.7~7.5분, 중앙값 2.5분이었습니다. 출시일이 중요하다면(언론, 광고 캠페인, Product Hunt 일정 등) 새벽 2시에 승인이 나서 발표 전에 출시되는 일이 없도록 수동 출시를 선택하세요.

기다리는 동안에는 App Store Connect를 열지 않고 상태를 확인하고 싶어질 겁니다. 제 모든 앱 저장소에 들어 있는 상태 확인 코드입니다. App Store Connect API에 최근 버전 5개와 빌드를 요청합니다.

# chain/Store/asc.py
def status():
    app = find_app()
    if not app:
        print("no app record for", BUNDLE_ID)
        return
    print(f"{app['attributes']['name']}  ({BUNDLE_ID})  id={app['id']}")
    versions = call(
        "GET", f"/v1/apps/{app['id']}/appStoreVersions", params={"limit": 5}
    )
    for v in (versions or {}).get("data", []):
        a = v["attributes"]
        print(f"  version {a.get('versionString')}: {a.get('appStoreState')}")

제출 자체는 CI 작업 마지막의 fastlane 호출 하나로, upload_to_app_store를 씁니다. submission_information의 답 세 개는 보기보다 중요합니다. 수출 규정 준수, 광고 식별자, 콘텐츠 권리에 관한 질문인데, 코드로 답해 두면 누군가 양식을 클릭해 주기를 기다리며 제출이 멈추는 일이 없습니다.

# chain/fastlane/Fastfile, lane :release (trimmed)
upload_to_app_store(
  api_key: asc_key,
  app_identifier: APP_IDENTIFIER,
  ipa: "build/Chain.ipa",
  # Submit, rather than leaving it sitting in Connect for a human to press
  # the button on. This is the last step and it is the irreversible one.
  submit_for_review: true,
  force: true,
  precheck_include_in_app_purchases: false,
  submission_information: {
    add_id_info_uses_idfa: false,
    export_compliance_uses_encryption: false,
    content_rights_contains_third_party_content: false
  }
)

App Store 심사는 주말에도 할까?

부분적으로는 그렇습니다. 결정 64건 중 4건이 태평양 시간 일요일에 왔습니다. 9월 20일 오후 4:05의 Pocket Beings 첫 승인, 그리고 10월 11일 저녁의 3건(1.2 업데이트 2건 반려, Chain 1.2는 오후 10:42 승인)입니다. 토요일에 온 결정은 없었습니다. 9월 26일 토요일에 낸 제출 19건은 모두 월요일 밤 이후에 결정되었고, 10월 8일 목요일에 보낸 업데이트 5건은 일요일 저녁과 월요일 이른 시간에 돌아왔습니다. 고를 수 있다면 월요일부터 수요일 사이에 제출하세요. 목요일 이후에 보낸 건은 주말이 지나서 결정된다고 생각하는 게 좋습니다.

제가 여러분의 프로젝트라면 할 일

1. 일 단위가 아니라 라운드 단위로 계획하세요. 한 라운드는 업데이트 약 3일, 새 앱 2~5일입니다. 새 계정의 새 앱은 두 라운드가 필요하니, 첫 제출부터 승인까지 근무일 기준 일주일을 잡으세요.
2. 심사 메모를 테스트 시나리오처럼 쓰세요. 로그인 방법(또는 "로그인 없음"), 유료 화면이 어디 있는지, 예외 상황을 어떻게 재현하는지, 어떤 데이터를 수집하는지. 첫 제출에 화면 녹화를 첨부하면 2.1로 물어볼 게 없어집니다.
3. 제출할 때마다 개인정보 처리방침 URL이 열리는지 확인하세요. 끊긴 링크 하나로 한 라운드를 통째로 날렸습니다.
4. 속도가 중요하면 인앱 결제는 따로 내세요. 12시간, 5건 중 5건 승인.
5. 5일이 넘는 심사는 경고로 받아들이세요. 4.3 질문 9개에 대한 답을 필요해지기 전에 미리 준비해 두세요.
6. Apple이 답장하라고 하면 다시 제출하지 마세요. 변경 없는 재제출로 얻은 건 7일 뒤 같은 시각의 똑같은 리젝이었습니다.
7. 문제가 구체적이면 빨리 고쳐서 다시 제출하세요. Minder의 깨진 개인정보 링크: 6분 만에 재제출, 25시간 만에 승인.
8. 더 빨리 필요하다면? Apple에는 치명적인 버그 수정과 시간이 중요한 이벤트를 위한 신속 심사 요청이 있습니다. 저는 써 보지 않아서 관련 숫자는 없습니다.
9. 직접 측정하세요. 여러분의 계정에서 같은 Gmail 쿼리를 돌려 보세요. 10분이면 실제 심사 달력이 나오고, 이 글을 포함한 어떤 평균보다 낫습니다.

데이터와 다시 실행하는 방법

모든 것이 한 폴더에 있습니다. emails.py(이메일에서 옮겨 적은 64개 행, Gmail 쿼리와 수집 시각 포함), analyze.py(중앙값, 구간, 묶음, 승인부터 출시까지의 지연), summary.json(이 글에서 계산한 모든 숫자), make_charts.py(차트)입니다. 2026년 10월 17일 미 동부 시간 오후 10:15경에 수집했고, iTunes 조회는 오후 10:20경에 실행했습니다. Apple의 주장은 같은 날 밤 developer.apple.com/distribute/app-review에서 확인했으며, 제출 흐름은 Apple의 Submit for review 도움말 페이지에 설명되어 있습니다. 개발자 계정 하나, 앱 21개, 5주. 작은 표본이지만 빠짐없는 표본이고, 실제로 검증할 수 있는 유일한 종류의 심사 기간 데이터입니다.

Windows에서 개발하면서 같은 파이프라인(클라우드 빌드, 서명, 스크린샷, fastlane 제출, 심사 메모 템플릿)을 여러분의 저장소에 구축하고 싶다면 No-Mac iOS Pipeline, $299가 있습니다. 영업일 기준 5일 안에 Windows PC에서 첫 TestFlight 빌드를 받아 보실 수 있습니다. 앱 전체를 맡기고 싶다면 고정 가격 개발은 /build/에 있습니다.