Apple의 4.3 스팸 검사는 30초짜리 일괄 작업입니다. 리젝 22건이 그 증거입니다

요약: Apple App Review가 제 iPhone 앱 11개를 Guideline 4.3 Spam으로 리젝했습니다. 그리고 한 번 더 그랬습니다. 두 번 모두 리젝 11건이 30초 안에 도착했습니다(10월 5일 30초, 10월 12일 27초). 3초에 한 통꼴이었고, 순서는 제가 제출한 순서와 아무 관계가 없었습니다. 두 번째 라운드는 재제출 후 167.7~167.9시간 만에 왔는데, 앱 하나도 빠짐없이 그랬습니다. 오차 12분짜리 7일 타이머입니다. 10월 5일에 App Review Board에 이의 신청 3건을 넣었습니다. 14일이 지난 지금, 답장은 0건입니다. 오늘은 Apple이 본 그대로의 상태로 앱 저장소 20개 전체에 직접 만든 "스팸 탐지기"를 돌려 봤습니다. 제가 지금까지 낸 앱 중 가장 비슷한 두 앱은 둘 다 스토어에 올라 있습니다. Apple은 4.3을 앱 단위로 심사하지 않습니다. 계정을 심사하고 있으며, 그 사실을 말하지 않습니다.

Google에서 "Guideline 4.3 spam"이 무슨 뜻인지 찾다가 오셨다면, 이것은 중복 앱을 막는 Apple의 규칙입니다. (a)항은 "multiple Bundle IDs of the same app"(같은 앱의 여러 Bundle ID)을 금지하고, (b)항은 "indistinguishable from what's already widely available"(이미 널리 나와 있는 것과 구별되지 않는) 앱을 금지합니다. 리젝 메시지는 보통 여러분의 앱이 다른 앱들과 "shares a similar binary, metadata, and/or concept"(비슷한 바이너리, 메타데이터, 콘셉트를 공유)하며 "only minor differences"(사소한 차이만 있다)고 말합니다. 어떤 앱인지, 어떤 파일인지, 어떤 화면인지는 알려 주지 않습니다. 짧은 해결책 목록은 맨 아래에 있습니다. 한꺼번에 제출하지 말 것, 다시 제출하기 전에 답장할 것, App Review와 통화 예약을 잡을 것. 이 글의 나머지는 그 근거 자료입니다.

앱 11개, 30초, 3초에 이메일 한 통

2026년 9월 26일, 저는 새 iPhone 앱 11개를 제출했습니다. 모두 전에 소개한 Mac 없는 파이프라인으로 Windows에서 만든 앱입니다. Odometer(자동차 정비), Parked(주차 미터), Rooms(주택 보험용 물품 목록), Pricebook(장보기 가격), Pawprint(반려동물 약), Chores(아이들 집안일 표), Clockout(서비스직 팁 기록), Curve(성적 계산기), Climbbook(볼더링 기록), Race Pace(러닝 구간 기록), Cutoff(카페인과 수면)입니다. 제출은 15.5시간에 걸쳐 나뉘어 있었습니다. 첫 제출은 태평양 시간 오전 7:10, 마지막은 오후 10:42였습니다.

9일 뒤인 10월 5일, 11개 모두 똑같은 "There's an issue with your submission" 이메일을 받았습니다. 오늘 아침 Gmail에서 타임스탬프를 뽑아 봤습니다. 첫 통은 미 동부 시간 오후 5:29:32에, 마지막 통은 오후 5:30:02에 도착했습니다. 저마다 다른 사람의 다른 문제를 다른 디자인으로 푸는 앱 11개가 30초 만에 판정받았습니다.

결정이 제출 순서대로 나왔는지도 확인했습니다. 사람이 대기열을 위에서부터 처리한다면 그렇게 나올 테니까요. 그렇지 않았습니다. "제출 순서"와 "리젝 순서" 사이의 스피어만 순위 상관계수는 첫 묶음이 -0.06, 두 번째 묶음이 0.06입니다. 사실상 0입니다. Pawprint는 4번째로 제출해 1번째로 리젝되었고, Odometer는 1번째로 제출해 11번째로 리젝되었습니다. 이 결정을 내린 것이 무엇이든, 앱을 하나씩 차례로 열어 보는 사람은 아니었습니다.

서로 다른 앱 11개가 30초 만에 판정받았습니다. 이건 심사가 아닙니다. for 루프입니다.

두 번째 라운드: 오차 12분짜리 7일 타이머

여기서 제가 Apple의 규칙 하나를 어겼고, 그건 인정합니다. 리젝 메시지는 동의하지 않으면 App Store Connect에서 답장하고 다시 제출하지 말라고 했습니다. 저는 11개 모두에 답장했고, 앱마다 App Review의 질문 9개에 전부 답했습니다. 그런데 그러고 나서 10분 안에(10월 5일 태평양 시간 오후 3:13~3:23) 11개를 전부 다시 제출해 버렸습니다.

두 번째 리젝은 10월 12일 미 동부 시간 오후 6:04:46~6:05:13에 도착했습니다. 앱 11개에 27초. 그런데 이상한 건 대기 시간입니다. 모든 앱이 재제출부터 리젝까지 167.7~167.9시간을 기다렸습니다. 168시간은 정확히 7일입니다. 앱 11개, 대기 11번, 편차는 12분이었습니다.

비교하자면, Apple의 App Review 페이지에는 "at least 50% of submissions in less than 24 hours and 90% in less than 48 hours"(제출의 최소 50%는 24시간 이내, 90%는 48시간 이내)를 심사한다고 쓰여 있습니다. 지난 주말 제 계정의 App Review 결정 64건 전체의 시간을 재 봤을 때 중앙값은 73시간으로, 이미 Apple의 약속보다 나빴습니다. 제 계정에서 다른 어떤 것도 딱 168시간을 기다린 적은 없습니다.

제 해석입니다. 유출된 정보가 아니라 해석입니다. 플래그가 붙은 계정은 1주일 타이머가 걸린 보류 대기열에 들어가고, 타이머가 끝나면 묶음 전체가 똑같은 정형 리젝 문구를 받습니다. 버튼은 사람이 누를 수도 있습니다. 하지만 앱을 열어 보는 사람은 없습니다. 서로 다른 앱 11개가 7일에서 15분 모자란 시점에 떨어진 이유를 더 잘 설명할 수 있는 분이 있다면 꼭 듣고 싶습니다.

저만 그런 게 아닙니다. 같은 주, 같은 30초 처리

2026년 10월에 같은 일을 겪은 다른 개발자들을 X에서 찾아봤습니다. 검색 한 번이면 충분했습니다. 아래는 오늘 캡처한, 편집하지 않은 실제 게시물입니다.

제 첫 묶음과 같은 날인 10월 5일, @krPorsche918은 Apple이 자신의 앱 다섯 개를 "in the same minute, with the same sentence: Guideline 4.3 Spam"(같은 1분 안에, 같은 문장으로: Guideline 4.3 Spam) 리젝했다고 올렸습니다. 이분의 글에는 이 문제에 관해 누가 쓴 것보다 좋은 문장이 있습니다. "To me, 14 apps in 13 days was productivity. To Apple, it was a pattern."(제게 13일 동안 앱 14개는 생산성이었습니다. Apple에게는 패턴이었습니다.) 같은 주에 Apple은 이분의 출시된 앱들에 대한 인앱 이벤트 53건을 모두 승인했습니다.

10월 8일, @vovalukashov(Luka Shaw)는 답글을 단 모든 사람이 생각하던 질문을 던졌습니다. "Looks like Apple stopped approving my new apps... Is this what happens to everyone who builds small apps that do one thing?"(Apple이 제 새 앱을 승인하지 않기 시작한 것 같습니다... 한 가지 일만 하는 작은 앱을 만드는 사람은 모두 이렇게 되나요?) 4주 동안 새 앱 3개가 리젝되었고, 그중 하나는 두 번이었습니다. "Updates to my old apps still go through."(기존 앱의 업데이트는 여전히 통과됩니다.) 이 글은 조회수 62K를 기록했습니다.

그리고 10월 12일 미 동부 시간 오후 6:26, 제 두 번째 묶음 11건이 도착한 지 22분 뒤, @martindonadieu(Capgo 창업자 Martin Donadieu)가 자신의 App Store Connect 화면을 올렸습니다. 빨간 "Rejected" 배지가 벽처럼 늘어서 있었고, 캡션은 "Moved from no review to almost all rejected LOL"(심사 대기에서 거의 전부 리젝으로 바뀜 ㅋㅋ)이었습니다. 조회수 223K. 사흘 뒤 그는 다시 글을 올렸습니다. 이번 여름 500명 규모 행사를 실제로 운영했고 이미 Google Play에 올라 있는, 100% 로컬에서 동작하는 티켓 앱이 4.3으로 두 번째 리젝을 받았다는 내용이었습니다.

네 명 모두의 패턴을 보세요. 새 앱은 죽고, 업데이트는 통과합니다. 제 계정도 그렇습니다. 새 앱 11개를 두 번 죽인 바로 그 기간에, Apple은 Chain과 Minder의 업데이트(10월 12일)와 9월 29일의 업데이트 6건을 승인했습니다. 9월의 업데이트 6건은 모두 리젝된 앱들과 같은 페이월 패턴(Pro.swift, Chain의 경우 Purchases.swift)을 추가했고, 같은 날 아침(9월 26일 미 동부 시간 오전 9:26~9:29)에 커밋되었습니다. 같은 코드, 같은 날. 업데이트는 약 3일 만에 승인, 새 앱은 두 번 리젝. Luka는 업데이트가 통과된다고 하고, Porsche는 인앱 이벤트 53건을 승인받았고, Martin의 기존 앱들은 여전히 올라 있습니다.

그래서 저는 Luka와 의견이 다릅니다. 그의 결론은 "I guess it's a sign to focus on the ones already in the App Store"(이미 App Store에 있는 앱에 집중하라는 신호인가 봅니다)였습니다. 이 필터가 모든 소규모 개발자에게 학습시키는 행동이 정확히 그것이고, 그건 잘못된 교훈입니다. 필터는 여러분의 새 앱이 나쁘다고 말하는 게 아닙니다. 여러분의 계정이 Apple이 편하게 느끼는 속도보다 빨리 출시하고 있다고 말하는 겁니다. 서로 다른 문제이고, 해결책도 다릅니다.

Apple이 옳았을까? 제 앱에 스팸 탐지기를 돌려 봤습니다

정당한 질문입니다. 제 앱들이 정말 복제품일 수도 있으니까요. 저는 30일 동안 iPhone 앱 20개를 AI 코딩 에이전트로, 모두 같은 파이프라인에서 만든 개발자 한 명입니다. 4.3을 받아 마땅한 사람이 있다면 저일지도 모릅니다. 그래서 오늘 오후, 따지는 대신 직접 테스트했습니다.

실험 방법은 이렇습니다. 로컬 앱 저장소 20개 각각에서 Apple이 실제로 본 git 커밋을 고릅니다(출시된 앱 8개는 첫 승인 직전의 마지막 커밋, 리젝된 앱 11개는 10월 5일 재제출 직전의 마지막 커밋). 그다음 모든 앱 쌍 190개를 4.3 필터가 볼 법한 다섯 가지 기준으로 비교합니다.

• 파일 트리 겹침: 추적되는 파일 경로의 자카드 유사도(공유 경로 수를 전체 경로 수로 나눈 값). 이게 "뼈대"입니다.
• 동일 파일: 앱 자체 이름을 치환한 뒤 바이트 단위로 완전히 같은 파일.
• Swift 코드 줄 겹침: 두 앱이 공유하는, 의미 있는 고유 Swift 소스 줄의 비율.
• 스토어 텍스트 겹침: App Store 설명에서 세 단어 구절의 겹침.
• 스크린샷 거리: 두 앱의 스토어 스크린샷 중 가장 가까운 쌍을 256비트 평균 해시로 잰 값(낮을수록 비슷함).

제게 유리하지 않은 정직한 결과부터 말하겠습니다. 리젝된 11개는 정말로 뼈대를 공유합니다. 파일 트리 겹침 중앙값이 출시된 앱의 0.56에 비해 0.76입니다. 쌍당 동일 파일이 14개로 5개에 비해 많고, Swift 줄 겹침은 약 세 배(0.067 대 0.021)입니다. Clockout과 Odometer는 파일 트리가 문자 그대로 똑같습니다. 같은 이름의 Swift 파일 7개가 같은 폴더에 들어 있습니다. Apple의 필터가 바이너리 안의 프로젝트 구조를 본다면, 제 리젝 묶음은 확실히 걸립니다.

이제 Apple이 설명해야 할 부분입니다. 190쌍 전체에서 가장 비슷한 한 쌍은 Baseline Ledger와 Fairway Ledger, 제 테니스 일지와 골프 일지입니다. 두 앱은 Swift 줄의 3분의 1(0.333), 동일 파일 20개, 0.90의 파일 트리를 공유하고, 모든 쌍 중 스토어 설명이 가장 비슷하며 스크린샷도 가장 가깝습니다. 둘 다 이틀 간격으로 9월 22일과 24일에 승인되었습니다. 둘 다 지금도 스토어에 있습니다. Chain과 Quiver는 0.968의 파일 트리를 공유합니다. 둘 다 출시 상태입니다.

그리고 사람 심사자가 실제로 보는 것, 즉 스토어 페이지와 스크린샷은 두 그룹을 전혀 구분하지 못합니다. 스토어 텍스트 겹침은 리젝 쌍 0.010, 출시 쌍 0.009입니다. 스크린샷 거리는 76 대 82입니다. 상품 페이지를 넘겨 보는 사람은 리젝된 앱이 "더 비슷하다"는 걸 알아챌 수 없습니다. 번들을 diff하는 기계만 알 수 있습니다.

리젝된 모든 앱에 있던 파일 하나

두 그룹을 깔끔하게 가르는 지문은 유사도 점수가 아닙니다. 파일 하나입니다. 리젝된 앱 11개 모두 첫 제출에 Sources/Pro.swift를 담고 있었습니다. 출시된 앱 8개 중 첫 승인 시점에 이 파일이 있던 앱은 하나도 없습니다. Pro.swift는 StoreKit 2 페이월입니다. 앱은 무료이고, 한 번 $4.99를 결제하면 전체 버전이 열립니다. 아래는 Apple이 심사한 커밋 시점의 Odometer 파일 앞부분입니다.

// Sources/Pro.swift (odometer repo, commit af40d3658)
/// Odometer Pro: one non-consumable. Keeping one car on schedule is free forever; Pro is the
/// whole garage and the paperwork.
@MainActor
@Observable
final class Pro {
    static let productID = "com.mattbusel.odometer.pro"
    /// The first build that has Pro in it. Anything earlier had every feature.
    static let firstFreemiumBuild = 2

    enum Reason: String, Identifiable { case costs, garage, history, export, settings; var id: String { rawValue } }

    private(set) var unlocked: Bool
    private(set) var grandfathered = false
    private(set) var product: Product?

    var price: String { product?.displayPrice ?? "$4.99" }

    func ask(_ why: Reason) { if !unlocked { paywall = why } }
    ...
}

파일들이 서로의 복사본은 아닙니다(리젝된 앱 중 Pro.swift가 똑같은 두 앱은 없고, 각자 자기 상품, 자기 무료 범위, 자기 업그레이드 이유가 있습니다). 하지만 모양은 같습니다. 비소모성 상품 하나, Pro 클래스 하나, 페이월 시트 하나. 출시된 앱들은 이 파일 없이 승인되었고, 나중에야 업데이트로 프리미엄 모델로 바뀌었는데, 그 업데이트가 제출된 날이 새 앱 11개와 같은 9월 26일입니다. 그 업데이트들은 9월 29일에 순조롭게 통과했습니다.

제가 생각하는 실제 상황은 이렇습니다. Apple은 절대 이걸 입 밖에 내지 않을 겁니다. 하루에 11개를 쏟아 내는 계정에서 나온, $4.99 잠금 해제가 붙은 완전히 새로운 무료 앱은 템플릿 공장의 실루엣 그 자체입니다. 4.3 문구와 자매 규칙 4.2.6은 "commercialized template or app generation services"(상업화된 템플릿 또는 앱 생성 서비스)를 겨냥해 쓰였습니다. 모든 코딩 에이전트가 하루에 앱 하나씩 뽑아낼 수 있는 2026년에는, 템플릿 공장과 Claude Code를 쓰는 1인 개발자가 밖에서 보기에 똑같습니다. Apple의 필터는 실루엣을 판정하고, 승인 버튼을 누르는 사람은 앱을 열지 않습니다. 상관관계이지 증거는 아닙니다. 앱 19개는 작은 표본입니다. 하지만 가이드라인 문구의 어떤 내용보다 깔끔한 구분입니다.

제가 보낸 답, 그리고 돌아온 답: 없음

4.3 리젝에는 질문 9개가 붙어 옵니다. 앱이 하는 일, 대상 사용자, 차별점, 테스트 방법, 다른 앱과 코드를 공유하는지 등입니다. 저는 앱마다 모든 질문에 솔직하게 답했습니다. 아마 제게 불리했을 부분까지 포함해서요. 예를 들어 Odometer 답장의 이 부분입니다.

"No shared framework or asset pack. Every screen, model, illustration and text is specific to Odometer. Two files follow a pattern I reuse: the StoreKit 2 purchase handling for its one non-consumable (the paywall's text, free/Pro split and look are specific to the app), and a test-only driver that steps through the app's screens to record the walkthrough video and is inactive in normal use."

그다음 Apple 양식으로 App Review Board에 이의 신청을 넣었습니다. 양식 하나에 앱은 최대 5개, 사유는 2,000자까지라서 양식 세 개(5 + 5 + 1)가 필요했습니다. 논지는 단순했습니다. 11개 모두 1분 안에 글자 하나 다르지 않은 문구로 리젝되었으니 개별 심사는 없었던 것이고, 사람이 앱을 하나씩 열어 봐 달라고 요청했습니다.

그게 10월 5일이었습니다. 오늘 아침 그 이후 Apple에서 온 메일을 받은편지함에서 검색해 봤습니다. Apple Ads 청구 메일, iPhone Duo 사전 주문 광고, 10월 16일에 App Review Guidelines가 개정되었다는 안내가 있습니다. 10월 12일 두 번째 묶음 이후 App Review나 App Review Board에서 온 이메일은 없고, 이의 신청에 관해서는 아무것도 없습니다. 13.8일째이고, 계속 늘어나는 중입니다.

10월 16일 개정은 그 자체로 작은 모욕입니다. Apple은 가이드라인의 일곱 부분을 고쳤습니다(크리에이티브 에셋과 숨겨진 기능, 결제 링크, 아동 안전에 관한 새 규칙). Guideline 4.3은 그중에 없었습니다. 4.3 일괄 리젝 물결이 공개적으로 일어나는 와중에, 규칙은 글자 하나 바뀌지 않았습니다.

Apple 자신의 숫자는 여러분이 특별하지 않다고 말합니다

Apple은 매년 App Store Transparency Report를 발행합니다. 2025년판은 심사한 제출 9,100,620건, 리젝 2,093,244건, 약 23%를 집계합니다. 스팸과 모방 앱을 포함하는 Design 항목이 리젝 415,532건을 차지합니다. Apple의 2026년 5월 뉴스룸 글은 다른 앱을 베끼거나, 스팸이거나, 사용자를 오도한다는 이유로 371,000건 이상의 제출을 리젝했다고 말합니다.

이제 아무도 인용하지 않는 줄을 보세요. 같은 보고서는 앱 삭제에 대한 이의 신청 26,305건과 복구 423건을 집계합니다. 1.6%입니다. 2021년, Apple의 App Review 담당 시니어 디렉터는 법원 제출 서류에서 팀에 500명이 넘는 사람 심사자가 있고 리젝 중 이의 신청되는 것은 1% 미만이라고 말했습니다. 직접 계산해 보세요. 연간 제출 9.1 million건(910만 건)은 하루 약 25,000건입니다. 스팸 유형 리젝 371,000건은 하루 약 1,000건입니다. 하루에 앱 1,000개를 꼼꼼히 열어 보는 사람은 없습니다. 30초짜리 일괄 처리는 그 시스템의 결함이 아닙니다. 그게 바로 시스템입니다.

도발적인 의견, 순위별로

1. 4.3은 1인 개발자에게 매기는 물량세가 되었습니다. 복제 앱을 잡지 못합니다. 제 가장 비슷한 두 앱은 출시되어 있습니다. 4.3이 잡는 건 Apple이 한 사람에게 적당하다고 보는 양보다 많이 출시하는 계정입니다. AI 코딩 시대에는 실력 있는 인디 개발자 전부가 여기에 해당합니다.
2. App Review Board는 일괄 리젝에 관한 한 블랙홀입니다. 제 예상으로는 이 이의 신청 11건은 11월 전까지 사람의 답을 받지 못하고, 혹시 받더라도 11건 모두에 같은 정형 문단 하나일 겁니다.
3. Apple은 4.3 숫자를 따로 공개하지 않을 겁니다. 투명성 보고서는 "4.3.0 Spam"을 리젝이 아니라 삭제(앱 418개)에 대해서만 표시합니다. 가이드라인별 집계를 공개하면 "스팸" 대응의 상당 부분이 실제로는 신규 개발자에 대한 속도 제한이라는 게 드러나기 때문입니다.
4. 업데이트가 통과하는 건 업데이트가 이미 Apple에 돈을 벌어 주기 때문입니다. 출시된 앱의 업데이트는 결제 이력이 있는 확인된 대상입니다. 새 앱은 비용입니다. 이 글의 모든 계정은 새 앱이 죽어 나가던 바로 그 몇 주 동안 업데이트를 승인받았습니다. 우연이 아니라 비즈니스 모델입니다.
5. Google이 이 몫을 가져갈 겁니다. Martin의 앱은 Apple이 두 번째로 리젝하기 일주일 전에 이미 Google Play에 올라 있었습니다. 인디 개발자의 첫 출시가 Android로 옮겨 가면 Apple의 "품질" 이야기는 훨씬 조용해질 겁니다.

Guideline 4.3 스팸 리젝에서 살아남는 법

위 데이터와 Apple 자체 페이지를 바탕으로, 제가 다르게 했을 일들입니다. 지금 저 자신도 따르고 있는 조언입니다.

1. 새 앱을 절대 한꺼번에 제출하지 마세요. 계정당 일주일에 새 앱 한두 개. Porsche의 "13일 동안 앱 14개"와 제 "하루에 11개"는 같은 답을 받았습니다. 출시된 앱의 업데이트는 원하는 만큼 빨리 내도 됩니다.
2. 답장하고, 다시 제출하지 마세요. 리젝 메시지에 그렇게 쓰여 있는데 저는 무시했습니다. 제 재제출은 7일 타이머에 걸렸고 27초 만에 죽었습니다. App Store Connect에서 질문 9개에 답하고 기다리세요.
3. 새 앱은 페이월 없이 출시하고, 인앱 결제는 업데이트로 추가하세요. 승인된 앱 8개 중 첫 승인 시점에 페이월이 있던 앱은 0개, 리젝된 앱은 11개 중 11개가 있었습니다. 작은 표본이지만 제가 찾은 유일하게 깔끔한 구분이고, 프리미엄 전환 업데이트는 매번 통과했습니다.
4. 앱들이 변형판이라면 합치세요. 4.3(a)는 말 그대로 앱 하나를 내고 변형은 인앱 결제로 팔라고 합니다. 심사자가 여러분의 앱 두 개를 한 문장으로 설명할 수 있다면, 실제로 그렇게 할 겁니다.
5. App Review와 통화를 예약하세요. Apple은 가이드라인에 관해 App Review와 이야기할 수 있는 30분짜리 Webex 상담을 제공합니다. 이걸 언급하는 사람은 거의 없습니다. 사람이 여러분을 직접 봐야 하는 유일한 채널입니다. 제 다음 수입니다.
6. 구체적인 근거로, 제출 하나당 이의 신청 하나씩 하세요. Apple의 이의 신청 페이지는 "specific reasons why you believe your app complies"(앱이 가이드라인을 지킨다고 믿는 구체적인 이유)를 요구합니다. 일괄 리젝의 타임스탬프는 구체적인 근거입니다. 지금까지는 그것만으로 부족했으니 5번과 함께 쓰세요.

이 앱 20개를 만들고 출시한 파이프라인(Windows PC에서, Mac 없이)이 궁금하다면 Windows에서 iOS 개발하기 완전 가이드에 정리되어 있고, 비용 쪽은 실제 앱 20개를 만드는 데 든 비용에 있습니다.

지금까지의 숫자

• 4.3으로 두 번 리젝: 앱 11개(리젝 22건), 2026년 10월 5일과 10월 12일
• 앱 11개를 리젝하는 데 걸린 시간: 30초(10월 5일), 27초(10월 12일)
• 제출 순서 대 리젝 순서: 스피어만 -0.06과 0.06(관계 없음)
• 두 번째 라운드 대기: 11개 모두 167.7~167.9시간(Apple은 90%가 48시간 이내라고 말함)
• 이의 신청: 10월 5일, 앱 11개에 대해 양식 3개. 13.8일 후 답장 0건(10월 19일 오후 1:10 ET 받은편지함 확인)
• 현재 미국 App Store에 출시된 앱: 8개(iTunes 조회, 10월 19일 오후 1:12 ET), 10월 17일 이후 변화 없음
• 190쌍 중 가장 비슷한 쌍: Baseline Ledger + Fairway Ledger, Swift 줄 33% 공유. 둘 다 출시.
• 첫 제출 시점의 페이월: 리젝된 앱 11개 중 11개, 승인된 앱 8개 중 0개

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

결정 타임스탬프: Apple App Review 발신자가 보낸 "There's an issue with your submission" 이메일 22통을 "Submitted:" 줄(태평양 일광 절약 시간)과 함께 10월 17일 Gmail에서 수집했고, 10월 19일 미 동부 시간 오후 1:10에 새 메일이 있는지 다시 확인했습니다(없음). 지문: fingerprint.py를 10월 19일 미 동부 시간 오후 1:19에 로컬 저장소 20개에 실행했습니다. 각 저장소는 결정적인 제출 직전의 커밋(git rev-list -1 --before=...) 기준이며, 파일은 git show로 읽고, 파일 비교에서 PNG는 제외했고, 해시 전에 앱 자체 이름을 플레이스홀더로 치환했습니다. 출시 상태: 제 개발자 계정에 대한 iTunes Search API 조회, 미 동부 시간 오후 1:12. @krPorsche918, @vovalukashov, @martindonadieu의 게시물은 10월 19일 미 동부 시간 오후 1:15경 X에서 캡처했으며, 편집하지 않은 실제 게시물입니다.

그래서 @martindonadieu, @vovalukashov, @krPorsche918님, 여러분의 리젝 이메일을 확인해 보세요. 몇 초 간격으로 도착했나요? 재제출은 정확히 일주일을 기다렸나요? 계정 세 개가 더 같은 168시간 타이머를 보여 준다면, 이건 더 이상 제 가설이 아닙니다. 다른 분들께도 묻습니다. Apple의 App Review Board가 여러분의 4.3 이의 신청에 실제로 답한 적이 있나요? 얼마나 걸렸나요? 댓글로 숫자를 남겨 주세요.

Mac 없이 iPhone 앱을 만들고 있고, 같은 파이프라인(서명, 스크린샷, fastlane 제출, 지금 제가 쓰는 심사 메모)을 여러분의 저장소에 구축하고 싶으신가요? No-Mac iOS Pipeline은 $299이며, 영업일 기준 5일 안에 첫 TestFlight 빌드를 받아 보실 수 있습니다.