완성한 앱을 배포하고 스토어에 출시하는 방법

개발자 컴퓨터에서 실행되는 앱과 사용자가 안전하게 설치하는 제품은 다릅니다.

채널 선택 → 앱 ID 확정 → Release 빌드 → 서명 → 테스트 → 스토어 자료 → 심사 → 단계적 출시 → 모니터링과 업데이트

스토어 규칙은 바뀌므로 제출 직전에 공식 문서와 콘솔의 현재 요구 사항을 확인합니다.

1. 패키징, 서명, 배포, 심사를 구분한다

패키징은 설치 파일, 서명은 제작자와 업데이트 체인의 증명, 배포는 전달 경로, 심사는 플랫폼 정책 확인입니다.

2. 소유권과 앱 ID를 먼저 정한다

개발자 계정, 회사 이메일, 도메인, 클라우드, 서명 인증서, 결제·세무 자료는 조직이 보유하고 2단계 인증을 사용합니다. Android 패키지명과 Apple Bundle ID는 출시 후 함부로 바꾸지 않습니다.

버전명은 사용자용, Build number는 업로드용입니다. 다시 업로드할 때도 Build number를 올립니다.

3. 실제 Release로 자료를 만든다

Release는 localhost, 테스트 DB, 샌드박스 결제를 가리키지 않고 서버 비밀을 포함하지 않습니다. 실제 화면에서 아이콘, 스크린샷, 설명, 지원, 개인정보 처리방침, 심사 안내를 준비합니다.

앱 권한, SDK 수집, 스토어 신고, 개인정보 문서는 서로 일치해야 합니다.

4. 플랫폼별 공개 경로

Android 새 앱은 보통 서명된 .aab를 Google Play에 올리고 내부 테스트부터 시작합니다. iOS는 App Store Connect, Xcode Archive, TestFlight, 심사 순으로 진행합니다.

Windows는 Microsoft Store의 MSIX 또는 서명된 홈페이지 설치 파일, macOS 홈페이지 배포는 Developer ID 서명과 Apple 공증이 필요합니다. Linux는 Flathub, Snap, AppImage, .deb, .rpm 등을 선택합니다.

Web/PWA는 안정적인 HTTPS 배포가 출시입니다. DNS, 인증서, 환경 변수, 404, 오프라인, Manifest, Service Worker, 모니터링, 백업을 확인합니다.

5. 심사 실패와 단계적 출시

Release 전용 충돌, 사용할 수 없는 심사 계정, SDK와 다른 개인정보 신고, 미완성 버튼, 과도한 권한, 무허가 자산이 흔한 실패입니다.

심사 원문은 다음과 같습니다: 【붙여넣기】. 해당 규칙과 고칠 동작을 찾고 추측하지 마세요.

개발자 테스트, 사내 테스트, 소규모 베타, 심사, 일부 사용자, 전체 출시 순으로 진행합니다. 서명, 개인정보, 모니터링, 롤백도 제품 개발의 일부입니다.