이 글에선 React Native(Expo) 프로젝트의 프로덕션 빌드를 생성하고, 앱 스토어에 앱을 제출하는 과정을 EAS Build, Submit 기능을 사용하여 구현한 것을 작성하고 있습니다.
EAS
EAS(Expo Application Services) 는 Expo 팀에서 제공하는 Expo 및 React Native 앱을 위한 통합된 클라우드 서비스이다.
앱을 빌드 서비스인 EAS Build, 앱을 앱 스토어에 제출하는 EAS Submit 등 다양한 서비스를 제공한다.
EAS Build
Expo 프로젝트를 빌드하는 방법은 로컬에서, 혹은 EAS Build 기능을 사용하는 방법이 있다.
EAS Build 는 Expo 및 React Native 프로젝트를 위한 앱 빌드 호스팅 서비스로서, 앱 배포용 빌드를 간단하고 자동화하기 쉽게 만든다. 또한, 앱 서명 자격 증명을 관리도 해주며,
eas.json이라는 설정 파일을 통해 각 용도에 맞는 빌드를 손쉽게 나누고 관리할 수 있다.
이러한 이점으로 이 글에선, 로컬에서가 아닌 EAS Build 를 통해 프로덕션 빌드를 생성하고 EAS Submit 을 통해 앱 스토어에 앱을 제출하도록 하겠다.
Profile
앞서 얘기했듯, eas.json 이라는 설정파일을 통해 각 용도에 맞는 빌드를 손쉽게 나누고 관리할 수 있다. 이는 profile 이라는 개념으로 가능하다. profile 을 적절하게 나누어, 최종적으로 프로덕션 빌드를 가능하게 할 것이다.
우선 eas.json 을 살펴보자. 각 항목, 즉 build.development, build.production 이 profile 을 나타낸다.
// eas.json
{
/* ... */
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"production": {
}
},
/* ... */
}build.development (내부 배포 빌드)
distribution 속성의 값을 보면, internel 로 지정되어있다. 이것은 해당 profile 이 내부 배포 빌드 profile 임을 나타낸다.
내부 배포 빌드 는 앱 스토어에 앱을 업로드할 필요 없이, 디바이스에 직접 앱을 다운하여 직접 배포 할 수 있도록 한다. 해당 profile 로 빌드한 결과물은 APK 타입을 가진다.
build.production (프로덕션 빌드)
우리가 원하는 프로덕션 빌드에 해당하는 profile 이다. 따라서, 앞서 얘기했듯 distribution 속성의 값은 지정되지 않아야 할 것이다.
프로덕션 빌드
프로덕션 빌드는 앱을 일반 사용자에게 공개하거나 TestFlight 와 같은 앱 스토어 테스트틀 위해 앱을 앱 스토어에 제출하기 위한 빌드 이다.
앞선 과정에서, 프로덕션 빌드 profile (build.production) 을 설정했으니, EAS CLI 의 커맨드를 통해 프로덕션 빌드를 진행할 수 있을 것이다.
EAS 를 통해 빌드 하는 커맨드는 기본적으로 다음과 같다.
eas build옵션을 통해 플랫폼과 용도에 맞는 profile 을 설정할 수 있다. Android 플랫폼에 프로덕션 빌드를 생성한다면 커맨드는 다음과 같이 된다.
eas build --platform android --profile production결과물
빌드의 결과는 EAS CLI 의 eas build:list 커맨드를 통해서도 확인 가능하고, EAS 프로젝트 - Builds 에서 확인할수 있다.
Expo 프로젝트를 생성하면 EAS 대쉬보드에 각 프로젝트에 관한 페이지가 생성된다. 이 페이지에서 프로젝트에 관련한 여러 설정을 지정하고, 정보를 확인할 수 있다.
Builds 에서 아무 Build 를 클릭하여 들어가면 다음과 같은 뷰를 확인할 수 있다.
Profile 항목에서 어떠한 profile 로 빌드를 진행했는 지 확인할 수 있다. 현재 앱에 대한 버젼도 Version, Version code 에서 확인할 수 있다.
여기서 주의할 점은 Build artifact, 즉 빌드 결과물(추출물) 의 타입이다. 앞서 build. 프로덕션 빌드를 진행할 시, AAB 타입의 결과물이 생성된다.
AAB
구글에서는 2021년 이후 부터, 앱 스토어에 제출할 수 있는 앱의 타입을 APK 에서 AAB 로 바꾸었다.
AAB 는 APK 를 완성해주는 요소를 담은 패키지로써, 이미 완성된 앱 파일을 뜻하는 APK 와 차이점이 있다. 앱의 크기가 줄어든다는 장점이 있어, 2021년 부터 구글 앱 스토어는 앱의 형식을 AAB 로 강제하고 있다.
즉, 앱을 앱 스토어에 제출하기 위해선 AAB 타입의 앱을 빌드하는 프로덕션 빌드가 필수적인 것 이다.
내부 배포 빌드와 프로덕션 빌드의 차이점
즉, 앱에 제출하기 위해선 AAB 타입의 앱을 빌드하는 프로덕션 빌드가 필수적인 것 이다. 앞서 얘기했듯, 내부 배포 빌드의 결과물은 APK 타입이다. APK 타입의 앱은 앱 스토어에 제출할 수 없다.
따라서, 앱 스토어에 제출 하는 과정을 생략하고, 즉시 팀원들과 앱을 공유하고 싶다면 내부 배포 빌드를, 앱 스토어에 제출해야 하는 경우에는 프로덕션 빌드를 사용해야 한다.
Google Play Console 내부 테스트
Google Play Console 에서 앱을 생성하면, 내부 테스트의 과정을 거치게 되어있다. 이때 앱의 타입은 AAB 이어야한다.
나는 이 과정에서 약간 혼동이 되었는데, EAS Build 내부 배포 빌드 === Google Play Console 의 내부 테스트 앱을 위한 용도 라고 생각하고 있었다.
하지만 앞서 얘기했듯, 내부 배포 빌드는 앱 스토어에 제출하지 않고 디바이스에 직접 설치하는 용도의 빌드에 해당한다.
따라서 내부 테스트 앱을 생성할 지라도, EAS 에서는 내부 배포 빌드가 아닌 빌드를 진행해야한다. build.production 이라는 profile 이름이 헷갈린다면 다음과 같이 내부 테스트용 profile 을 생성할 수 있을 것이다.
// eas.json
{
/* ... */
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"production": {
},
"internelTest": {
/* ... */
}
},
/* ... */
}App Signing
EAS Build는 서명된 앱 또는 서명되지 않은 앱 모두 생성할 수 있지만, 앱 스토어를 통해 배포하려면 반드시 서명된 앱이어야 한다. 따라서 프로덕션 빌드에서는 앱 서명을 생성해야한다.
EAS 에서는 EAS CLI 의 eas credentials 커맨드를 통해 손쉽게 서명을 생성할 수 있다. 생성된 서명은 EAS 서버에 업로드 되며, 각 EAS 프로젝트 페이지에서 확인할 수 있다.
수동으로 만들고 싶다면, 이 문서를 참고하면 된다.
EAS Submit
EAS Submit 은 앱을 앱 스토어에 업로드하고 제출하기 위한 호스팅 서비스이다. EAS Submit 으로 지속적으로 앱을 제출하기 위해선, 다음의 과정이 필수적이다.
준비물
- 최초 한번 앱을 스토어에 수동으로 직접 제출하는 과정이 필요하다. 이 또한 Expo 에서 문서로 제공하니, 확인하여 진행할 수 있다.
- 구글 서비스 계정 키 가 필요하다. 따라서, 구글 서비스 계정을 생성 하고, 구글 서비스 계정 키 를 생성 하여, EAS 프로젝트 페이지에 업로드하는 과정이 필요하다.
이는 모두 Expo 문서에서 자세하게 확인할 수 있으니, 꼭 확인해보도록 하자.
앱 스토어에 제출하기
위의 과정을 모두 마쳤다면, EAS Submit 을 통해 제출하는 과정 자체는 아주 간단하다. 터미널에 다음 커맨드를 입력하면 된다.
eas submit --platform android --profile production--profile 옵션에서 유추할 수 있듯, profile 기능 은 Submit 에서도 사용할 수 있다.
Profile
EAS Submit profile 에서 신경써야 할 점은 두가지 정도이다.
-
track: 앱이 사용될 track 을 의미한다. track 은 앱의 배포 단계 정도로 생각할 수 있다. enum 타입을 가지며, 값들은 다음과 같다.production,beta,alpha,internal만일 앱 스토어에 제출하는 앱이 Google Play Console 내부 테스트 용도라면,
track: internal로 지정할 수 있을 것이다. -
releaseStatus: 앱의 release 의 상태, 버전 상태를 의미한다. 역시 enum 타입을 가지며, 값들은 다음과 같다.completed: 버전에 추가 변경사항이 없으며, 버전의 APK는 최신 버전의 APK를 사용할 수 있는 경우를 제외하고 모든 사용자에게 제공된다.draft: 버전의 APK가 사용자에게 제공되지 않는다.halted: 버전의 APK가 더 이상 사용자에게 제공되지 않는다. 이 APK를 이미 보유한 사용자는 영향을 받지 않는다.inProgress: 버전의 APK가 일부 사용자에게 제공된다.
이를 바탕으로 다음과 같은 EAS Submit profile 을 구성해 볼 수 있을 것이다.
// eas.json
{
/* ... */
"build": {
/* ... */
},
"submit": {
"production": {
"android": {
"track": "production",
"releaseStatus": "completed"
}
},
"internal": {
"android": {
"track": "internal",
"releaseStatus": "draft"
}
},
}
/* ... */
}Issues
하지만, 나는 위와 같이 Expo 공식 문서를 따라 차례대로 진행했음에도, 여러 에러를 마주했다. 이들의 원인과 해결방법을 정리해보았다.
1. Google Api Error: Invalid request - The Android App Bundle was signed with the wrong key. Found
App Signing 에서 생성한 JSON 형태의 서명이 있다. 이것을 Google Play Console - 설정 - 앱 서명 의 업로드 키 인증서 에 넣어줘야한다. 업로드 후 반영되는데 1 - 2일 정도의 시간이 소요된다.
2. Error: version code X has already been used. try another version code.
만약 N 회차 의 제출을 진행했다면 해당 에러가 발생할 수 있다. 이는 앱 스토어에 새롭게 제출한 앱의 version code 가 이전 앱의 version code 와 동일하여 발생한 에러이다. 따라서 프로덕션 profile 에 해당 속성을 추가해주어야 한다. 관련 내용 과 version 관리 에 대한 자세한 내용은 Expo 문서에서 확인할 수 있다.
// eas.json
{
/* ... */
"build": {
"development": {
"developmentClient": true,
"distribution": "internal"
},
"production": {
"autoIncrement": true
}
},
/* ... */
}3. Google Api Error: Invalid request - Only releases with status draft may be created on draft app.
EAS Submit 으로 제출을 처음 할 시에 발생하는 에러로 추측한다. 에러를 해석하면, draft 의 앱에서만 draft 릴리스 를 생성할 수 있다는 의미이다. 이런 에러가 발생할 때는 해당 profile 에서 releaseStatus: draft 로 값을 지정해야한다.
References
