App Store 심사 2일 통과기 — path_provider 크래시와 iPad 함정
2026-04-20 제출, 2026-04-22 승인. iOS 1.0.0 심사는 2일 만에 끝났지만 그 전 2주가 전쟁이었다. path_provider FFI 크래시, iPad 스크린샷 함정, build 8까지의 삽질 실전기.
시리즈 위치 — #10 GentleDo라는 이름이 생기기까지 → #11 Claude Code 개발기 → #12 (현재)
2026-04-20 제출, 2026-04-22 승인. iOS 1.0.0 심사는 2일 만에 끝났다. 심사 통과는 빨랐지만, 그 전 2주가 전쟁이었다. GentleDo가 오늘 App Store에서 받을 수 있게 된 기록을 남긴다.
제출 전 마지막 크래시 — path_provider_foundation 2.6.0 FFI
build 7까지 시뮬레이터에서는 멀쩡했다. 실기기(iPhone)에 꽂아서 TestFlight 빌드를 돌렸더니 앱 기동 직후 크래시. 크래시 리포트에 찍힌 건 한 줄이었다.
path_provider_foundation ... Dart_FFI_...
구글링 15분 후 원인을 특정했다. path_provider_foundation 2.6.0 버전이 특정 iOS 기기에서 FFI 크래시를 일으키는 알려진 이슈였다. Flutter 패키지 생태계의 어두운 면이다. 한 라이브러리의 마이너 업데이트가 전체 앱을 내려버린다.
해결책은 pubspec.yaml에 dependency_overrides로 버전을 강제 고정하는 것이었다.
dependency_overrides:
path_provider_foundation: 2.4.4버전 하나 되돌리는 데 7시간이 걸렸다. 원인 찾기가 대부분이었고, 실제 수정은 1분. 이게 Flutter 1인 개발의 현실이다. 커밋은 e887e2c로 남았다.
iPad 스크린샷 함정 — TARGETED_DEVICE_FAMILY 변경
다음 함정은 App Store Connect 제출 페이지에서 튀어나왔다. 메타데이터 입력을 끝내고 "제출" 버튼을 눌렀는데 붉은 에러가 떴다.
"iPad 13-inch display screenshots are required."
GentleDo MVP는 iPhone 전용으로 설계했다. iPad 최적화 UX는 Phase 1의 범위 밖이다. 하지만 Flutter 기본 설정은 iPad까지 타깃으로 포함하기 때문에, App Store Connect가 iPad 스크린샷을 자동으로 요구한다.
선택지는 두 가지였다.
- iPad 스크린샷 5장을 만들고, iPad UX를 어느 정도 검증한다 → 최소 3일 추가
- iPad 타깃 자체를 제거한다 → 30분
MVP 정신으로 2번을 골랐다. ios/Runner.xcodeproj/project.pbxproj에서 TARGETED_DEVICE_FAMILY를 "1,2"에서 "1"(iPhone only)로 변경. 커밋 e887e2c에 함께 담았다.
App Store 페이지에 "Compatible with: iPhone"만 뜨지만, 지금은 그게 옳다. iPad 버전은 Phase 1.5에서 만든다.
build 8, 마침내 제출 (2026-04-20)
2주간의 빌드 타임라인은 이렇게 흘렀다.
| 날짜 | 빌드 | 주요 변화 |
|---|---|---|
| 2026-04-09 | build 2~3 | 구조 모듈화 — 의존성 방향 정리, 대형 파일 분리 |
| 2026-04-10 | build 4 | 런타임 버그 수정 + 다크모드 + l10n 최종 QC (테스트 75개) |
| 2026-04-11 | build 5 | 앱 아이콘 재생성 (Concept D: Progress Arc) + 4탭 전면 UX 개선 |
| 2026-04-11 | — | 테스트 확장 75 → 158개 (QC agent) |
| 2026-04-16 | build 6 | macOS 지원 + 앱스토어 암호화 선언 |
| 2026-04-17 | build 7 | Android 알림 시스템 안정화(권한/Receiver/재부팅 복구) |
| 2026-04-20 | build 8 | path_provider 2.4.4 고정 + iPad 타깃 제거 → 제출 |
빌드 번호 8까지 오는 데 약 2주. 매일 뭔가 깨지고 고쳤다. 가장 긴장한 순간은 제출 직전 "Transporter" 업로드가 28분간 멈췄을 때였다(결국 네트워크 지연이었다).
심사는 2일, 승인 이메일은 새벽에
제출일: 2026-04-20 오후. "Waiting for Review" → "In Review"로 넘어간 시각: 2026-04-21 밤 11시대. 승인 이메일 수신: 2026-04-22 새벽.
2일. 한국 앱 개발자 커뮤니티에서 "첫 심사는 평균 3~7일"이라는 글을 봤던 터라 빨라서 놀랐다. 가설로는 두 가지 요인이 있었던 것 같다.
- 앱이 로컬 전용 (서버 호출 없음, 계정 없음) → 심사관이 체크할 항목이 적다
- 개인정보처리방침·데이터 수집 선언이 깔끔했다 (수집 자체를 안 하므로)
다운로드하러 가기 — iOS 먼저, Android는 다음
출시 범위는 현재 iPhone (iOS 16+) 전용이다. Android 빌드(AAB)는 준비돼 있지만 Play Console 등록은 아직 하지 않았다. 이유는 단순하다. 한 번에 두 스토어를 다루면 피드백 창구가 두 개로 쪼개지고, 1인 개발자는 양쪽을 동시에 수습할 수 없다.
먼저 iOS에서 한 달을 돌리면서
- 실사용 피드백 수집
- 크래시 리포트 모니터링(Apple 기본 제공)
- 리뷰 답변
- 모멘텀 점수 감쇠 곡선 튜닝
를 끝낸 뒤 Android를 내보낼 계획이다.
출시 시점의 Phase 1 기능 범위
참고용으로 1.0.0에 들어간 것들을 정리한다.
- 컨디션 체크 + 에너지 기반 Today 필터
- Today / Tasks / Week / My 4탭 구조
- 태스크 CRUD + 서브태스크 + 반복 + 그룹
- 죄책감 없는 모멘텀 점수제 (스트릭 카운터 없음)
- 미루기 기록 / Fresh Start
- 로컬 알림 (시작/마감 기준)
- Android 13+ 알림 권한 + 재부팅 후 예약 복구(출시는 iOS만이지만 코드에는 포함)
- ko / en i18n
- 홈 위젯 (WidgetKit)
출시 후 다음 빌드에는 이미 커밋된 시작시간 중심 모드 + cross-day 태스크 지원(commit 5c90c92)이 올라갈 예정이다.
출시 다음 날의 기록
이 글을 쓰는 지금, App Store에서 GentleDo를 "내 앱"이라고 부를 수 있게 됐다. 3개월 전에는 이름도 Keelry였고, 2주 전에는 심사 제출도 안 된 상태였다.
가장 크게 배운 건 이것이다. 출시는 완벽한 코드를 기다리는 게 아니라, "가설을 검증할 최소한의 상태"를 결정하는 일이다. iPad 타깃을 제거한 결정이 대표적이다. "iPad도 지원하자"가 아니라 "Phase 1은 iPhone만"이라고 선을 긋는 순간 앞으로 나갈 수 있었다.
다음 스프린트는 실사용 피드백 기반의 튜닝이다. 그 이야기는 또 다른 글에서.
CTA — 다운로드 (iOS): apps.apple.com/us/app/gentledo/id6761796867 · GentleLab 랜딩: lsy860224.github.io/gentlelab.github.io
관련 글
비개발자가 Claude Code로 Flutter 앱을 만든다는 것 — GentleDo 개발기
Flutter를 한 줄도 안 써 본 비개발자가 Claude Code와 함께 GentleDo를 App Store에 올리기까지. 기술 스택 선택, DB 마이그레이션, 의존성 정리, 테스트 158개. AI가 할 수 있는 것과 할 수 없는 것의 경계를 정직하게 기록.
GentleDo라는 이름이 생기기까지 — Keelry를 버린 날
3개월 키운 앱 이름 "Keelry"를 버리고 "GentleDo"로 바꾼 과정. 항해 메타포에 빠졌다가 돌아온 이야기, DB 컬럼 리네임, 그리고 GentleLab이라는 우산 브랜드가 생긴 날의 기록.
네이버 블로그도 시작했다 — 이중 플랫폼으로 간 이유
aigrit.dev만으로 충분할 줄 알았다. 그런데 한국 블로그 수익 구조를 파보니 광고·협찬·공구가 다른 채널에 있었다. 왜 네이버를 추가했고 어떻게 '복사'가 아닌 '에디션'으로 갔는지 기록.