DAY 38 | 개인 프로젝트 — 배포하기
1.0.0+1 형태의 version에서 + 우측에 있는 숫자는 빌드 번호로, 늘 1씩 증가한다. 버전이 바뀌든 바뀌지 않든 스토어에 빌드를 올릴 때마다 이전보다 높은 값으로 설정되어 있어야 한다. + 좌측의 버전은 semantic versioning을 사용하는 게 가장 일반적이지만 반드시 이를 따라야 하는 건 아니다.
앱 서명에 대한 설명도 하셨지만 그건 이미 해놨기 때문에 가볍게 들었다. 나는 CLI로 했는데 수업에서는 GUI로 하더라. 개인적으로 이런 작업은 CLI가 훨씬 간결해서 좋은 것 같다. 물론 이건 어디까지나 선호도 차이일 뿐이다.
안드로이드 배포
다음 명령어를 통해 생성된 app-release.aab 파일이 Google Play Console에 업로드할 녀석이다.
flutter build appbundle --release
환경변수를 사용하는 경우에는 다음과 같이 환경변수 설정도 넣어주어야 한다.
flutter build appbundle --release --dart-define-from-file=env.json
대시보드에서 요구하는 항목들을 다 채워넣어야 한다. 다 채워 넣었으면 [스토어 등록정보]에 미리 준비한 앱 이름과 설명, 아이콘, 그래픽 이미지, 스크린샷을 첨부해서 저장한다.
안드로이드 앱 배포를 위해서는 12명 이상의 테스터가 비공개 테스트 참여를 해야 한다. 따라서 비공개 테스트를 생성한다. 테스터의 구글 이메일을 등록하고 비공개 테스트 버전을 생성하는데, 여기서 아까 flutter build appbundle --release 로 생성한 app-release.aab 파일을 업로드해야 한다.
내 앱의 경우 위치 정보를 사용하기 때문에 이에 대한 항목을 추가로 제출해야 했다. 위치 정보가 어떻게 쓰이는지 동영상을 제출하라는 부분도 있더라.
심사가 완료되기 전에 새 버전을 만들었다면
pubspec.yaml 의 빌드 번호를 1 올린다. 배포된 앱이라면 semantic version도 같이 올리는 게 좋지만 심사 전 테스트 상태에서는 빌드 번호만 올리는 게 일반적이라고 한다.
수정된 소스 코드를 다시 빌드한다.
flutter build appbundle --release --dart-define-from-file=env.json
[비공개 테스트] 트랙 -> [새 버전 만들기]에서 새로 생성된 app-release.aab 파일을 업로드한다.
아이폰 배포
CSR 파일을 생성해야 한다. [키체인 접근]을 실행하여 [인증서 지원]에서 [인증기관에서 인증서 요청]을 선택한다. 이메일과 이름을 적은 뒤 디스크에 저장한다. Apple Developer 계정과 같은 이메일/이름을 사용하는 게 좋다.
Apple Developer에서 Certificate를 발급한다. [
iOS Distribution (App Store Connect and Ad Hoc)] 를 선택하고 조금 전에 만든 CSR 파일을 업로드한다. 다음으로 넘어가면 Certificate를 다운로드받을 수 있으며 이를 더블클릭하면 Mac의 키체인에 설치할 수 있다. keychain: login 으로 선택하여 설치한다.
Identifier는 소셜 로그인 구현 때 사용했던 걸 그대로 쓰면 된다. Profile은 [App Store Connect]를 선택하고 앞서 만든 App ID와 Certificate를 연결한다. 이름은 아무거나 써도 되지만 앱 이름과 통일하는 게 관리하기 수월하다.
준비가 되었으면 App Store Connect에서 앱을 등록할 수 있다. 배포 정보를 입력하고 스크린샷을 첨부하고 앱 심사 정보를 넣는다. 그리고 [앱 정보] 메뉴를 채우고 [가격 및 사용 가능 여부]에 앱 가격을 설정한다. [앱이 수집하는 개인 정보]에 개인정보 처리방침 URL을 넣고 설문을 작성한다.
Xcode의 [Product > Archive] 를 누르고 기다렸다가 [Distribute App]을 눌러 [App Store Connect]를 선택하고 업로드되길 기다린다. 이 때, 환경변수를 사용했다면 [Product > Archive] 를 누르기 전에 [Product > Scheme > Edit Scheme...]를 눌러 [Archive]의 [Pre-actions]으로 이동한다. [New Run Script Action]을 누르고 Provide build settings from Runner 로 설정한 뒤 다음과 같이 스크립트를 작성한다.
cd "$SRCROOT/.." flutter build ios --config-only --release --dart-define-from-file=env.json
Xcode의 [Product > Archive]를 누르는 대신 터미널에서 다음 명령어를 사용하여 빌드 후 바로 Distribute App 할 수도 있다.
flutter build ipa --release --dart-define-from-file=env.json open build/ios/archive/Runner.xcarchive
Symbol에 대한 경고는 무시해도 되고 완료되었으면 5-20분 후에 성공/실패 이메일이 온다. 실패 메일이 올 경우 실패 사유에 따라 수정한 뒤 다시 빌드하여 시도한다. 성공 메일이 올 경우에는 App Store Connect로 돌아가 빌드를 업로드하고 [심사에 추가] 후 [심사를 위해 제출]을 누른다. 심사를 기다리라는 메일이 오면 보통 1-2일 후에 심사가 완료된다는 모양이다.
보니까 지원 URL도 필수라고 하길래 이메일로 문의하기와 FAQ가 포함되어 있는 고객 지원 페이지를 AI로 생성해서 firebase hosting으로 올려 놓았다.
심사가 완료되기 전에 새 버전을 만들었다면
빌드 버전은 안드로이드 재배포 전에 올렸으니 아이폰용으로 빌드하여 올리면 된다.
flutter build ipa --release --dart-define-from-file=env.json open build/ios/archive/Runner.xcarchive
아직 심사 대기 중이라면 App Store Connect에 들어가 기존 빌드를 내리고 새 빌드를 선택하여 심사에 추가한다. 이미 심사 중이라면 임의로 빌드를 변경할 수 없는데, 심사에서 이 버전 삭제를 누른 뒤, 새 빌드를 선택하여 다시 제출하시는 것을 권장한다고 하더라. 결함이 있는 상태로 리젝을 받는 것보다, 자발적으로 빌드를 교체하여 재제출하는 것이 심사 히스토리 관리상 훨씬 안전하다나.
이제 심사를 기다리며 발견된 버그들을 처리하고, 1차 배포 이후로 미뤄 놓았던 개발을 해야 한다. 그리고 12인의 구글 테스터도 모아야 하는데... 번거로운 비공개 테스트를 도와줄 사람이 몇이나 있으려나. 매일 접속해서 뭐라도 건드려 주는 게 좋다는데 아무래도 귀찮은 일이겠지. 테스트 해 줄 사람을 영 못 구하면 돈 주고 맡기기도 한다더라.
라고 했는데 Apple App Store는 심사 요청 당일에 바로 승인 메일이 왔다...! 버그는 계속 발견되고 있지만 열심히 고쳐 나가야지.
