당신은 주제를 찾고 있습니까 “react native 배포 – 리액트 네이티브 배포용 APK 빌드하기“? 다음 카테고리의 웹사이트 th.taphoamini.com 에서 귀하의 모든 질문에 답변해 드립니다: https://th.taphoamini.com/wiki/. 바로 아래에서 답을 찾을 수 있습니다. 작성자 DeviceMart 이(가) 작성한 기사에는 조회수 147회 및 좋아요 4개 개의 좋아요가 있습니다.
Table of Contents
react native 배포 주제에 대한 동영상 보기
여기에서 이 주제에 대한 비디오를 시청하십시오. 주의 깊게 살펴보고 읽고 있는 내용에 대한 피드백을 제공하세요!
d여기에서 리액트 네이티브 배포용 APK 빌드하기 – react native 배포 주제에 대한 세부정보를 참조하세요
디바이스마트 홈페이지
https://www.devicemart.co.kr
ch7
https://bit.ly/3Jr2t14
Secure Password Generator
https://passwordsgenerator.net/
react native 배포 주제에 대한 자세한 내용은 여기를 참조하세요.
React-Native: 안드로이드 빌드 및 배포하기
React-Native로 몇 개의 앱을 만들어 보았는데 항상 안드로이드 배포를 할 때마다 찾아보고 고생을 많이 한 것 같습니다. 그래서 간단하게 안드로이드 …
Source: jw910911.tistory.com
Date Published: 4/12/2022
View: 5733
[React Native] 빌드 및 배포하기 – INGG.
React Native CLI(0.60+)로 개발한 앱을 빌드하고 배포해보자. … 앱을 배포하려면 먼저 개발자 등록 후에 인증서 및 프로비저닝 프로파일을 생성할 …
Source: ingg.dev
Date Published: 9/21/2021
View: 3701
React Native 앱을 배포하기 전 간과한 것들 – Weiji ? 왜이지
React Native 앱을 배포하기 전 간과한 것들. 지난 반년 동안 개인 공부를 잠시 멈추고 회사에서 리액트 네이티브 앱을 개발하고 있었다. 처음 만들어보는 …
Source: weiji.io
Date Published: 6/8/2021
View: 434
[React Native] iOS앱 App Store에 배포하기
[React Native] iOS앱 App Store에 배포하기 · ❐ App Store에 앱 등록 및 정보 입력하기 · ❐ iOS 인증서 생성하기. CSR 파일 생성; Identifier 생성 …Source: sodevly.github.io
Date Published: 3/5/2021
View: 5318
ReactNative와 함께하는 서비스 개발부터 배포까지
ReactNative의 존재 이유이자 최강 장점인 크로스플랫폼 동시 개발을 위해서가 가장 큰 이유였습니다. 서비스를 위해선 당연하게 Andro와 iOS를 모두 …
Source: oliveyoung.tech
Date Published: 3/6/2022
View: 98
React Native Code Push로 배포하기 – Medium
React Native Code Push로 배포하기. 안녕하세요. 휴먼스케이프 Software Engineer Dia입니다.. 모바일 앱은 웹 앱과는 다르게 업데이트 버전을 …
Source: medium.com
Date Published: 10/9/2021
View: 6750
react native 통합 배포 자동화하기 – 브런치
react native 통합 배포 자동화하기 … hybr code는 스타트업에게 빠른 앱 출시를 가능하게 만들어주는 고마운 프레임워크임과 동시에 웹 개발 경험 …
Source: brunch.co.kr
Date Published: 1/20/2021
View: 4949
ReactNative – 안드로이드 배포용 APK생성하기
ReactNative – 안드로이드 배포용 APK생성하기 · 1. 키 스토어 생성. 먼저 키 스토어를 생성해 준다. · 2. gradle config · 3. Apk(aab)생성 · 4. play store console에 등록.
Source: intrepidgeeks.com
Date Published: 6/14/2022
View: 1805
안드로이드 앱 스토어 등록 – RN(React Native)로 개발한 …
RN(React Native)로 개발한 안드로이드 앱(Andro App)을 안드로이드 앱 … 대신 apk 파일이 여러개 생기며, 앱을 배포할시 생성된 apk 파일 모두를 업로드하셔야 …
Source: dev-yakuza.posstree.com
Date Published: 5/27/2021
View: 4742
[React Native] Android 배포용 빌드하기 – velog
어제 포폴용으로 만든 RN 앱을 리드 미까지 다 작성하고 나서 빌드도 해보고 싶단 생각이 들었다. 맥북이 없기 때문에.
Source: velog.io
Date Published: 1/25/2021
View: 5572
주제와 관련된 이미지 react native 배포
주제와 관련된 더 많은 사진을 참조하십시오 리액트 네이티브 배포용 APK 빌드하기. 댓글에서 더 많은 관련 이미지를 보거나 필요한 경우 더 많은 관련 기사를 볼 수 있습니다.
주제에 대한 기사 평가 react native 배포
- Author: DeviceMart
- Views: 조회수 147회
- Likes: 좋아요 4개
- Date Published: 2022. 3. 18.
- Video Url link: https://www.youtube.com/watch?v=_ShL_x_EuEI
React-Native: 안드로이드 빌드 및 배포하기
반응형
React-Native로 몇 개의 앱을 만들어 보았는데 항상 안드로이드 배포를 할 때마다 찾아보고 고생을 많이 한 것 같습니다.
그래서 간단하게 안드로이드 배포시 꼭 필요한 부분만 정리해서 포스팅을 해보았습니다.
Release 빌드 준비해야할 것
1. Icon 준비하기
2. 구글 개발자 등록하기
3. keystore 발급하기
4. android/gradle.properties 편집하기
5. release apk 만들기
6. Play Store에 앱 등록하기
1. Icon 준비하기
먼저 기본적으로 안드로이드 앱을 만들고 플레이스토어에 등록하기 위해 준비해야 할 이미지는 아래와 같습니다.
최소 2개의 스크린샷 (측면 최소 320픽셀, 최대 3840픽셀의 JPG 또는 24비트의 PNG)
그래픽 이미지 (1024 x 500픽셀의 JPG 또는 24비트의 PNG)
즉, 아이콘, 스크린샷, 그래픽 이미지 3가지가 반드시 필요합니다.
이는 사용자에게 어떤 앱인지를 알려주는 기본적인 정보입니다.
개발자가 디자인까지 신경써서 만들기는 힘든데 이를 쉽게 제공해주는 사이트를 설명해둔 링크가 있으니 참고하시면 됩니다.
아이콘
스크린샷
2. 구글 개발자 등록
Play console 개발자 등록
위 사이트로 이동하여 구글 개발자 등록을 해줍니다.
개발자 등록에는 $25가 필요하고 매년 재등록을 해야 하는 IOS와는 달리 1회 등록으로 평생 이용이 가능합니다.
개발자 등록에 대한 자세한 내용은 아래 링크를 참고하세요
3. keystore(서명키) 발급 및 관리
보통 Google Play Store에 앱을 올릴 때, 앱 개발자가 누구인지 판별할 수 있도록 하기 위해서 keystore(서명키)를 생성해야 합니다. keystore가 바뀔 경우 빌드는 할 수 있지만, 스토어에 업로드를 할 수 없게 됩니다.
따라서 생성한 keystore는 분실 시 보안상 문제가 생길 수 있기 때문에 잘 보관하여 문제가 생기지 않도록 하는 것이 중요합니다. 해커에게 악용될 경우 훔친 keystore를 이용하여 해당 keystore가 사용된 앱을 강제로 바꾸거나 훼손할 수 있습니다.
그럼 이제 서명키를 생성하는 방법을 알아보겠습니다.
터미널을 통한 서명키 생성은 아래 명령어를 이용해주시면 됩니다.
keytool -genkey -v -keystore my-release-key.keystore -alias my-key-alias -keyalg RSA -keysize 2048 -validity 10000
그러면 아래와 같은 창이 나오는 것을 확인하실 수 있습니다.
키 저장소 비밀번호 입력 : password123 새 비밀번호 다시 입력 : password123 이름과 성을 입력하십시오. : OINGBONG 조직 단위 이름을 입력하십시오. : OINGBONG 조직 이름을 입력하십시오. : OINGBONG 구/군/시 이름을 입력하십시오? : Gangnam-gu 시/도 이름을 입력하십시오. : Seoul 이 조직의 두 자리 국가 코드를 입력하십시오 : kr CN=OINGBONG, OU=OINGBONG, O=OINGBONG, L=Gangnam-gu, ST=Seoul, C=kr 이(가) 맞습니까? y 다음에 대해 유효기간이 36,500일인 2,048비트 RSA 키 쌍 및 자체 서명된 인증서 (SHA256withRSA)를 생성하는중 : CN=OINGBONG, OU=OINGBONG, O=OINGBONG, L=Gangnam-gu, ST=Seoul, C=kr
에 대한 키 비밀번호를 입력하십시오. (키 저장소 비밀번호와 동일한 경우 Enter 키를 누름) : 키스토어 파일 생성완료 release_key.keystore : 키스토어 파일 이름 임의 지정
alias_name : 앱을 키스토어 파일로 서명할 때 사용할 이름
10000 : 유효기간 ( 유효기간이 지나면 더 이상 해당 앱은 업데이트할 수 없음 )
여기서 keystore의 패스워드와 key의 패스워드, alias를 잘 기억하도록 합니다. (또 Git에 올라가지 않도록 주의하여야 합니다.)
생성된 keystore는 android/app 폴더에 위치시키도록 합니다.
안드로이드 스튜디오를 통한 keystore 생성은 아래 링크를 참고하세요.
4. android/gradle.properties 편집하기
MYAPP_RELEASE_STORE_FILE=xxxxxx.keystore MYAPP_RELEASE_KEY_ALIAS=xxxxxx MYAPP_RELEASE_KEY_PASSWORD=xxxxxx MYAPP_RELEASE_STORE_PASSWORD=xxxxxx
5. release .apk 또는 .aab 만들기
$ cd android && ./gradlew assembleRelease
release용 apk를 만들기 위해 터미널에서 위 명령어를 입력해줍니다.
APK 파일은 android/app/build/outputs/apk/app-release.apk 에 위치합니다.
번들 형식으로 빌드하기 위해서는 아래 명령어를 입력해줍니다.
$ cd android && ./gradlew bundleRelease
번들(.aab)파일은 android/app/build/outputs/bundle/app-release.aab 에 위치합니다.
6. Play Store에 앱 등록하기
마지막으로 Play Store에 앱을 등록합니다.
해당 작업은 안드로이드의 Play console에서 작업이 진행됩니다.
자세한 내용은 아래 링크를 참고해주세요
마무리
이상으로 React-Native 앱 개발 시 Play Store에 release 버전 배포에 대해 알아보았습니다.
React-Native는 말은 React이지만 React 문법 외에 Android / IOS의 빌드, 배포 환경도 잘 알아야 되기 때문에 까다로운 부분이 있는 것 같습니다.
그래도 다들 열심히 공부해서 React-Native로 멋진 앱을 만들어 보셨으면 좋겠습니다.!
반응형
[React Native] 빌드 및 배포하기
앱을 배포하려면 먼저 개발자 등록 후에 인증서 및 프로비저닝 프로파일을 생성할 필요가 있다. 개발자 프로그램 등록을 완료했다면 애플 개발자 사이트(https://developer.apple.com/) 에서 [ Account > Certificates, Identifiers & Profiles ] 로 이동한다. 이미 인증서 하나가 있다면 최초로 개발자 등록을 할때 만들어진 개발용 인증서다. 인증서를 선택해서 다운로드하고 키체인에 인증서를 등록하면 된다.
그리고 배포용 인증서가 필요하다. 키체인 접근 > 인증서 지원 > 인증기관에서 인증서 요청 을 실행해서 이메일주소, 일반이름을 클릭하고 요청 항목에서 디스크에 저장, 본인이 키 쌍 정보 지정 을 체크하여 인증서를 생성한다. [ Certificates ] 탭에서 iOS Distribution을 선택하고 키체인으로 만든 파일을 업로드 후 배포용 인증서를 다운로드한다.
프로비저닝 프로파일도 개발용/배포용 두가지가 필요하다. 먼저 개발용은 [ Profiles ] 탭에서 iOS App Development를 선택하여 식별자를 고르고 프로비저닝 이름을 입력해서 생성한다. 배포용은 [ Profiles ] 탭에서 App Store를 선택하면 된다.
ios/[프로젝트이름]/Info.plist 에서 다음 내용을 삭제한다. 앱 내부에서 외부 API를 호출할 때, HTTPS만 사용할 수 있게 한다.
추가로, 사용자 위치 정보를 사용하지 않는다면 이 부분을 제거한다.
그리고 Xcode에서 시뮬레이터를 Any ios Device 로 하고, Product > Scheme > Edit Scheme 에서 Build Configuration의 Debug 를 Release 로 변경한다.
이제 Product > Archive 로 앱을 빌드한다. 빌드가 완료되면 Distribute App 을 눌러서 앱을 앱스토어 커넥트에 업로드한다.
App Store Connect > Upload 를 선택하고 Next로 이동한다.
옵션은 모두 체크한 상태에서 Next로 이동한다. 이제 Upload를 누르고 성공하면 이런 화면을 볼 수 있다.
빌드 과정에서 Use of undeclared identifier ‘GMSServices’ 라는 구글맵 관련 오류가 발생하여 실패했는데 Import 중 제일 하단에있던 GoogleMap을 ifdef 상단으로 옮기고 빌드했더니 해결되었다.
앱스토어 커넥트(https://appstoreconnect.apple.com/)의 Testflight로 이동하면 업로드한 앱이 처리중 상태이고 메일이 오는데, 앱 배포준비가 끝났다는 메일을 받을 수 있다. 이제 제출 준비 중 탭에서 빌드 옆의 + 버튼을 눌러 빌드된 앱을 선택하면 된다. 그리고 필요한 앱 스크린샷, 제목, 정보, 등급 등의 정보와 사진을 모두 등록하면 된다.
iPhone 미리보기 및 스크린샷은 6.5형 디스플레이 (1242×2688), 5.5형 디스플레이 (1242×2208) 파일을 필수로 올려야 한다.
이제 심사를 위한 제출을 누르면 일정 시간이 지난 후, 심사 결과가 이메일로 통보된다.
리젝을 당하면 해명으로 해결하거나, 새로운 빌드가 필요한 경우 버전을 올려서 배포해야 한다. 보통 버전은 1.0.0(major.minor.patch) 과 같이 세 자리로 관리한다.
나의 경우 빌드후에 이런 메일을 받았는데, NSLocationWhenInUseUsageDescription 이 없어서 발생한 이슈로 보인다. 내 앱은 사용자 위치 정보를 사용하지 않아서 해당 코드를 제거했기 때문에 일단 그대로 제출했고, 심사가 통과됐다. 심사에서 리젝될까봐 걱정했는데, 이런 경우 일단 무시하고 심사 제출해보는 것도 나쁘지 않은 것 같다. 조언해주신 개발자 yakuza님께 정말 감사드린다.
성공하면 android/app/build/outputs/apk/release/app-release.apk 이 경로에 생성된다.
배포파일의 사이즈를 최적화하려면 app/build.gradle 를 다음과 같이 수정한다.
React Native 앱을 배포하기 전 간과한 것들
지난 반년 동안 개인 공부를 잠시 멈추고 회사에서 리액트 네이티브 앱을 개발하고 있었다. 처음 만들어보는 앱이라 시행착오가 꽤 있었다. 그중 가장 힘들었던 부분은 웹 프로젝트보다 개발 환경 설정이 까다롭다는 점이었다. 우선 시뮬레이터를 돌리는 것부터, 기기 테스팅을 하기까지, ios 와 android를 별도로 확인해야 한다는 점, xcode 와 android studio 등등, 코딩 외에 신경 써야 하는 부분이 꽤 많았다. 여차저차 고개들을 건너 어느덧 배포할 시간이 되었는데…
코딩하는 부분에서는 찾아볼 수 있는 리소스가 많다, 공홈 독스도 친절한 편이고. 하지만 배포 과정에 대해서 잘 정리되어있는 리소스가 별로 없었다. 온라인은 찾으면 이것저것 나오고, 리소스 양이 많아서 좋긴 한데, 한편으론 여러 목소리가 섞여 읽혀서 혼란스러울 때도 있다. 가끔은 한 명의 저자가 찬찬히 설명해 주는 게 읽고 싶을 때가 있다. 스무디 한 잔 마시며 끝내는 React Native 라는 책 맨 마지막 두 챕터가 각 ios 배포와 안드로이드 배포를 step by step으로 딱 필요한 부분만 짚어서 설명해준다. 그것도 나름 간략하게.
잘 따라 하면 애플 스토어와 구글 플레이 스토어에 일차적으로 앱을 제출하는 단계까지 갈 수 있다. 하지만 앱이 정상적으로 심사를 통과하고 등록되려면 그사이에도 검토할 것들이 좀 있어 보인다. 다음은 내가 앱스토어에 앱을 제출하고 거절을 당하며 재검토하게 된 부분들이다. 어떤 건 바보 같은 실수고, 어떤 건 그냥 몰랐고, 어떤 건 정책적인 부분이다. 누군가 첫 앱 배포를 준비하고 있다면, 참고가 되면 좋겠다.
— 안드로이드 android —
구글 플레이 스토어의 검토 과정은 사실… 검토라는 걸 하나? 싶었다. 대부분의 경우 그냥 통과시켜주는 것 같다. 3일 걸렸다는 사람도 있는데, 내 경우에는 등록 후 승인까지 딱 7일 걸렸다. 검토의 어부가 의심되는 이유는 첫 승인이 나고 스토어에서 다운받아서 설치한 앱이 실행조차 되지 않는 불량한 apk이었던 것이다. 물론 apk 생성 후 제대로 테스트하지 못한 나의 탓이지만… 내가 뭔가 잘못하면 스토어에서 걸려주겠지…라는 생각은 하지 않는 게 좋을 것 같다.
build.gradle 설정
방금 말한 apk 파일이 실행되지 않는 첫 문제는 제출 직전에 수정한 build.gradle 파일에서의 설정이 문제였다. 위에서 말한 스무디 책에서는 release 버전을 위해서 build.gradle 파일에 hermes 사용 여부, apk 파일 여러 버전으로 쪼깰 여부, 그리고 proguard 사용 여부를 수정한 후 release 용 apk를 생성한다. 이후에 갑자기 설치파일의 크기가 급격하게 주는 기쁨을 느낄 수 있었으나… 기존에 하나의 apk 파일로 디버깅하다가 갑자기 1개에서 4개로 늘어난 apk 파일에 ‘아 이건 스토어 용 설치 파일이구나’ 하고 직접 테스트를 해봐야 한다는 사실도 모른 체 제출을 했었다. (그냥 제출 직전에 하는 하나의 의식? 같은 거라고 생각) 하지만 실제로 스토어에 등록된 후 앱이 실행되지 않아 등록하기 직전에 변경했던 것들을 재검토하고, 저 중에서 proguard 사용 여부를 끄니 release 용 apk도 정상적으로 테스트 할 수 있었다. Proguard는 리엑트 네이티브의 Java bytecode를 일부 제거해서 apk 파일의 사이즈를 줄여주는 역할을 하는데, 공홈에서도 Proguard 설정을 변경한 후 앱을 꼭 테스트해 보라는 말이 있다. 나의 경우에는 proguard 는 파일 크기에 큰 영향을 주지 않았기 때문에 그냥 사용하지 않기로 했다. build 설정을 조금이라도 수정했다면 꼭 테스트를 다시 해보자.
앱 아이콘
내가 사실 출시까지 정말 정신이 없긴 했는데, 이건 그냥 좀 이상하게 까먹어버린 부분이었다. 구글 스토어에서는 앱의 아이콘이 잘 노출되는데, 설치된 앱을 핸드폰 바탕화면에서 보면 안드로이드 기본 아이콘을 사용하고 있다. 이건 뭐 좀 당연한 건데, 빌드 과정에서 내가 아이콘을 포함하지 않았기 때문이다. (…) 스토어에 등록할 때 스토어 콘솔에서만 아이콘 이미지를 등록하고 실제 앱 설치파일에서는 빼먹은 것이다. ios 도 xcode에 아이콘 파일 올려서 빌드할 때 asset에 분명히 포함시켰는데, 주로 테스팅으로 아이폰을 써서 그런가, 안드로이드에서 전혀 앱의 로고가 안 보인다는 사실을 이상하게 여기지 않았었다. 사실 거기까지 챙길 정신이 없었던 것 같다… 출시는 맨정신에 하자.
참고 스텍오버플로우 : How to add icons to React Native app
파이어베이스 지문
이번에 만든 앱은 Firebase Auth를 사용하는데, 처음에 앱에 파이어베이스 프로젝트를 연결할 때 Firebase 프로젝트 설정에 들어가서 SHA 인증서 지문을 등록하는 과정이 있다. 이 지문은 android studio 나 터미널에서 조회할 수 있는데, 앱에서 사용하는 keystore마다 지문이 다르다. 그러니까 debug용 키스토어랑 release용 키스토어가 있으면, 지문도 바뀐다는 점이다. 그래서 release 파일을 만들어서 쓴다면, release 용 지문 또한 프로젝트 설정에서 추가해줘야 한다. 이 문제는 안드로이드 release 용 apk에서 sns 로그인에 문제가 생겨서 찾아보다가 다행히 출시 전에 해결했다.
휴… 그런데 그래도 출시하면 또 sns 로그인이 안 된다. ㅎㅎ 아직 프로젝트 설정에 추가해야 하는 지문이 하나 더 남았다. 구글 스토어에 등록된 앱을 받아서 설치하면 또 지문이 달라진다. 이 지문은 구글 플레이 스토어 콘솔에서 확인할 수 있으며, 똑같이 Firebase 프로젝트 설정에서 추가해줘야 한다.
참고 스텍오버플로우 : React Native Firebase Social Auth doesn’t work on release
— 애플 ios —
애플… 애플… 난 이번 경험을 통해서 애플이라는 기업을 더 리스펙하게 되었다. 사실 직접 앱 검토를 해보기 전에는 ‘오래 걸린다, 까다롭다, 골치 아프다’라는 의견을 들었다. 하지만 사실상 이번 경험을 토대로 하면 앱 ‘검토’ 자체가 오래 걸리는 것 같지는 않고, 검토가 까다롭기 때문에 제출, 검토를 여러 번 하다 보니 오래 걸리게 되는 것 같다. 이제 두 번째 거절을 받은 상태인데, 두 경우 다 제출 후 하루 이틀 만에 ‘이러이러한 부분을 고쳐야 합니라’라는 세부적인 답변이 왔었다. 아직 세 번째 제출은 하지 않은 상태이지만 여태껏 애플 스토어에서 지적해 준 부분들을 공유해본다.
Info.plist 사용자 동의 string
리액트 네이티브 앱에서 기기의 여러 기능을 사용하다 보면 ios의 경우는 Info.plist를 수정하고 android의 경우는 AndroidManifest.xml을 수정할 일이 종종 있다. 앱에서 카메라를 사용해야 해서 개발 초기에 두 파일을 이미 수정했었는데, 여기서 사용자에게 카메라 사용 동의를 요청하는 글귀를 너무 대충 썼었다. 물론 android에서는 그런 글을 쓸 필요가 없지만 ios에서는 상세하게 설명해야 한다. 초반에는 영문으로 ‘무슨 무슨 기능 때문에 카메라를 사용해야 해’ 정도로 작성했었고, 그대로 제출했는데 첫 번째 앱 검토에서 해당 이유를 더 설명하라는 답변을 받았다. 2~3문장으로 나눠서 조금 더 상세하게 썼고, 언어도 영어와 국문으로 나눠서 localize 해서 다시 제출했다.
Info.plist에 있는 값들을 localize 하는 방법은 다음 글을 참고했다 : Localize an Application Name in React Native
Apple로 로그인하기
이건 애플 스토어의 정책이다. 당신의 앱이 sns 로그인을 사용한다면 ‘Apple로 로그인’을 로그인 옵션으로 반드시 포함해야 한다. 그리고 Apple로 로그인을 붙이는 법을 찾다 보면 다시 한번 애플이 엄청 치밀한 회사라는 걸 느낄 수 있다. 로그인 버튼을 정확히 어떻게 구현해야 하는지의 가이드가 따로 있고, 최대한 애플에서 제공하는 버튼을 사용하라고 알려준다. 나의 경우에 약간 사이즈를 바꿔서 사용할 필요가 있었고… 가이드라인을 최대한 따랐다 : Human Interface Guidelines – Sign in with Apple Buttons. 가이드라인에서는 애플로고는 반드시 Apple Design Resources에서 다운받은 파일만을 사용할 것을 중요시한다. 필요한 패딩이니 뭐니 이미 다 포함되어있다고… 오케이. Apple Design Resources가서 애플로고를 찾아봤다. 아무리 찾아도 없다. 진심 한 시간 정도 찾았다. 그러다가 그냥 구글 검색해서 사용할까 하다가… 또 검토에서 퇴짜맞을까 봐 열심히 뒤졌다. 결론은 애플로 로그인에서 쓰는 애플 로고는 애플 로고로 별도로 다운받는 것이 아니고 Sign in with Apple 리소스 페키지 파일 안에 애플 로그인 용도로 만들어진 로고 파일로 포함되어있다… 라는 것이다. 그러니까… Apple Design Resources 여기 웹사이트 메인 화면에 도착하자마자 밑으로 내려서 Sign in with Apple 옆에 있는 Download 버튼을 눌러서 받을 수 있다. 하… 아무도 나처럼 로고 찾아 헤매지 않길 바란다.
사용자 개인 정보 수집
이 부분에서 애플 스토어의 검수에서 수정요청이 들어왔다는 것은 검토하시는 분이 일단 앱의 회원가입과 sns 로그인을 자세히 들여봤다는 뜻이다. 그리고 대략 다음처럼 얘기해줬다 : ‘가입 시 앱의 핵심 기능과는 무관한 정보를 입력해야 합니다. 이는 불필요하니 없애거나 선택사항으로 해주세요.’ 이 부분은 아직 다른 부서랑 회의를 좀 해봐야 해서 아직 수정하진 못했지만, 아이폰 사용자의 개인 정보는 조심히 다뤄지고 있구나… 라는 느낌을 받았고, 앞으로도 계속 아이폰을 쓰고 싶어졌다. 어제만 해도 안드로이드를 쓰는 친구랑 저녁을 먹다가 요즘 계속 감시당하고 있는 느낌이라는 얘기를 들었는데, 확실히 이런 부분에 있어서 애플은 철저했다.
늘어놓고 보니 미리 예방할 수 있는 문제도 있었지만, 이 외에도 챙길 게 많으니 출시 직전에 확인해야 하는 사안들은 체크리스트로 만들어서 매번 확인하고 출시하면 좋을 것 같다.
[React Native] iOS앱 App Store에 배포하기
💻 [React Native] iOS앱 App Store에 배포하기 April 22, 2022 React Native
❐ App Store에 앱 등록 및 정보 입력하기
App Store에 앱 등록 및 정보 입력하는 방법은 여기서 자세히 설명하겠습니다.
❐ iOS 인증서 생성하기
CSR 파일 생성
CSR 파일 생성 방법은 여기서 자세히 설명하겠습니다.
Identifier 생성
Identifier 생성 방법은 여기서 자세히 설명하겠습니다.
Certificate 생성
Certificate 생성 방법은 여기서 자세히 설명하겠습니다.
Provisioning Profile 생성
Provisioning Profile 생성 방법은 여기서 자세히 설명하겠습니다.
❐ iOS앱 TestFlight에 배포하기
iOS앱 TestFlight에 배포하기 페이지를 참고해주세요.
❐ 앱 심사 요청
빌드 > ‘앱을 제출하기 전에 빌드를 선택하십시오’ 버튼을 클릭합니다.
TestFlight에 업로드했던 앱 빌드가 보입니다.
빌드 리스트에서 앱 심사 등록할 빌드를 선택한 후 완료 버튼을 클릭합니다.
‘심사에 추가’ 버튼을 클릭합니다.
‘앱 심사에 제출’ 버튼을 클릭합니다.
앱 심사 요청이 완료되었습니다.
상태가 ‘앱 심사 대기중’으로 변경된 것을 확인할 수 있습니다.
앱 심사 결과가 나올 때 까지 기다립니다.
❐ 앱 출시
앱 심사 승인을 받으면 상태가 ‘개발자 출시 대기 중’으로 변경됩니다.
‘이 버전 출시’ 버튼을 클릭합니다.
App Store에 iOS앱이 출시되었습니다.
상태가 ‘판매 준비됨’으로 변경된 것을 확인할 수 있습니다.
ReactNative와 함께하는 서비스 개발부터 배포까지
올-하! 💚 안녕하세요. 여러분! 올리브영에서 모바일 앱 개발을 담당하고있는 개발요정입니다. 오늘은 올리브영의 신규 서비스인 ‘인마이백’ 앱 개발기를 이야기해보려고 합니다.
인마이백은 작년에 올리브영에서 출시한 모바일앱으로, SNS와 커머스가 결합된 신개념 복합 플랫폼입니다. 단독특가로만 진행되는 핫한 큐레이션딜을 통해 생생한 아이템 소개와 사용팁을 둘러볼 수 있고, 내 가방 속 아이템을 소개하거나 크리에이터들의 가방 속 아이템을 구경하며 생생하고 다양한 리뷰를 확인할 수 있는 모바일 앱 서비스에요.
Why ReactNative?
크로스플랫폼 📱
ReactNative의 존재 이유이자 최강 장점인 크로스플랫폼 동시 개발을 위해서가 가장 큰 이유였습니다. 서비스를 위해선 당연하게 Android와 iOS를 모두 지원해야 했는데요, 당시 올디브에는 iOS 앱 개발자가 없었기 때문에 multiple OS 개발이 가능한 플랫폼을 검토 대상에 두었습니다. 또한 한벌의 코드를 작성하고 실행하면, Android와 iOS에서 모두 작동한다는 점은 시간과 비용적인 면에서도 굉장히 큰 절감효과를 가져옵니다. 실제로 인마이백 서비스는 멀티 플랫폼을 지원함에도 불구하고 적은 인원의 개발자로 비교적 단기간에 출시할 수 있던 앱입니다.
React로 인해 확 줄어드는 러닝커브 ⚛️
그렇다면 다른 크로스플랫폼인 Flutter, Xamarin, Cordova 등이 아니라 왜 하필 ReactNative로 선정하게 되었는지 궁금할 수도 있는데요, 이미 올디브에서는 React를 사용한 서비스 경험들이 있습니다. React를 다를 줄 아는 팀원들이 많았기 때문에 러닝커브를 반 이상 줄여서 큰 진입장벽 없이 ReactNative를 도입할 수 있었습니다.
HIP ✨
아직도 몇년째 버전 1로 올라오지 못했지만, 그럼에도 불구하고 꾸준히 핫한 플랫폼입니다. ‘우리도 ReactNative 한번 써보자!’ 하는 마음이 맞는 개발자들끼리 모여 개발을 시작하게 되었습니다.
How to develop?
Typescript
ReactNative는 공식 가이드에서도 TypeScript 사용을 장려하고 있습니다. 인마이백도 마찬가지로 TypeScript를 적용하여 코드를 작성하고 있습니다. TypeScript를 사용할 경우 Code look은 다음과 같습니다.
import React from ‘react’ ; import { Button , StyleSheet , Text , View } from ‘react-native’ ; export interface Props { name : string ; enthusiasmLevel ? : number ; } const Hello : React . FC < Props > = ( props ) => { const [ enthusiasmLevel , setEnthusiasmLevel ] = React . useState ( props . enthusiasmLevel ) ; const onIncrement = ( ) => setEnthusiasmLevel ( ( enthusiasmLevel || 0 ) + 1 ) ; const onDecrement = ( ) => setEnthusiasmLevel ( ( enthusiasmLevel || 0 ) – 1 ) ; const getExclamationMarks = ( numChars : number ) => Array ( numChars + 1 ) . join ( ‘!’ ) ; return ( < View style = { styles . root } > < Text style = { styles . greeting } > Hello { ‘ ‘ } { props . name + getExclamationMarks ( enthusiasmLevel || 0 ) } < / Text > < View style = { styles . buttons } > < View style = { styles . button } > < Button title = "-" onPress = { onDecrement } accessibilityLabel = "decrement" color = "red" / > < / View > < View style = { styles . button } > < Button title = "+" onPress = { onIncrement } accessibilityLabel = "increment" color = "blue" / > < / View > < / View > < / View > ) ; } ; const styles = StyleSheet . create ( { root : { alignItems : ‘center’ , alignSelf : ‘center’ } , buttons : { flexDirection : ‘row’ , minHeight : 70 , alignItems : ‘stretch’ , alignSelf : ‘center’ , borderWidth : 5 } , button : { flex : 1 , paddingVertical : 0 } , greeting : { color : ‘#999’ , fontWeight : ‘bold’ } } ) ; export default Hello ;
Redux
전역으로 관리해줄 필요가 있는 데이터는 Redux를 사용하여 구성했습니다. 여러가지가 있지만 제가 사용했던 부분은, 상세 화면에서 ‘좋아요’ 상태값 변경 후 목록화면으로 되돌아갈 때 API 재호출을 통해 리스트를 전체적으로 갱신하지 않아도, 업데이트 된 항목의 ‘좋아요’ 상태만 갱신해 줄 수 있도록 하는데에 적용하였습니다.
State와 Effect
Redux 오용을 최소화하고자 각 화면별 State를 권장사용하였습니다. 데이터가 바뀌면 View가 갱신되는 flow를 따라갑니다.
브랜치 전략
인마이백 저장소는 크게 4가지 브랜치로 분류되며, 메인 브랜치인 develop 브랜치부터 가지 브랜치인 feature, codepush, release 브랜치를 가지고있습니다. 처음에는 release 이후에는 태그를 따는 방식으로 진행했다가 여러 시행착오를 거쳐 브랜치 형태로 가져가는 것이 프로젝트 특성에 알맞아 현재까지 유지되고 있습니다.
develop : 메인 브랜치입니다. 현재 개발중인 가장 최신 코드가 반영되어 있습니다.
: 메인 브랜치입니다. 현재 개발중인 가장 최신 코드가 반영되어 있습니다. feature : 기능 단위별 feature 브랜치입니다. develop 브랜치에서 분기되어 develop 브랜치로 병합됩니다.
: 기능 단위별 feature 브랜치입니다. develop 브랜치에서 분기되어 develop 브랜치로 병합됩니다. codepush : QC를 위한 브랜치입니다. 어느 정도 릴리즈 가능하게끔 개발이 끝나면 develop 브랜치에서 분기되어 QC fix를 진행하게 됩니다. QC가 끝나면 최신 현상을 develop 브랜치에 병합하고 release 브랜치를 checkout 합니다.
: QC를 위한 브랜치입니다. 어느 정도 릴리즈 가능하게끔 개발이 끝나면 develop 브랜치에서 분기되어 QC fix를 진행하게 됩니다. QC가 끝나면 최신 현상을 develop 브랜치에 병합하고 release 브랜치를 checkout 합니다. release: 기능이 출시되어 운영 기준으로 가장 최신 코드가 반영된 브랜치입니다. QC가 끝난 codepush 브랜치에서 분기되어집니다.
컨벤션
Airbnb Script Convention을 따릅니다. indent를 포함한 기본적인 look set은 git hook을 사용하여 커밋시 auto align 시켜줍니다. 이로써 여러명이 작성한 코드도 한명이 작성한 코드처럼 보여질 수 있습니다.
또한 팀 내 개발룰에 맞게, 모든 feature는 PR 승인제를 통해 머지되어집니다. 최소 1명 이상의 승인이 있을 때에만 develop 브랜치에 반영이 가능하고, 리뷰어는 꼼꼼히 코드를 리뷰해줍니다. 활발한 리뷰를 통해 자주적인 토의 및 오류를 선발견함으로써 비교적 양호한 코드 품질을 유지할 수 있었습니다.
라이브러리 환경
인마이백에는 크게 다음과 같은 환경이 구성되어 있습니다. 각 항목별 적용기는 추후 포스팅을 통해 더 자세하게 다룰 예정입니다. 😊
How to deploy?
코드푸시
빠른 배포를 위해 MS AppCenter의 CodePush를 적용하였는데요, Code Push는 말 그대로 앱 업데이트 없이 코드를 바로 푸시! 할 수 있는 라이브러리로, 은행앱이나 게임앱에서 앱 실행 전 패치 파일을 받아와서 리소스를 업데이트하는 모습과 비슷합니다.
기존에는 각 스토어에 앱을 업데이트하기 위해서는 [ 스크립트 코드 번들링 > 앱 빌드 > 스토어 게시 > 심사 > 출시 ] 단계를 거쳐야만했는데요, 코드푸시를 적용하게되면 단 명령어 한 줄만으로! 앱을 업데이트할 수 있습니다.
$ appcenter codepush release-react -a ${PROJECT NAME} -d ${DEPLOY NAME}
처음 적용할 때는 과연 오류없이 잘 될까하는 의구심이 있었는데, 출시 이후 수백번의 배포를하는 동안 문제 없이 코드푸시가 이루어지고 있어 매우 유용하게 잘 사용하고 있습니다. ReactNative와의 궁합이 아주 좋기 때문에 ReactNative 프로젝트를 진행하는 경우 CodePush도 함께 적용하기를 적극 권장하고 싶습니다. CodePush 적용에 대한 가이드 포스팅도 추후 자세히 다룰 예정입니다!
ReactNative를 사용해보며 느낀점
ReactNative를 사용해보니 장점과 단점이 극명한 플랫폼이라는 것을 느꼈습니다. 많은 사이트에서 ReactNaitve의 장단점을 다루고 있지만, 개인적으로 제가 느낀 경험 위주로 장단점을 작성해보려고 합니다.
장점
찐으로 Hot한 속도 🔥
Hot Reload를 통해 코드를 작성한 즉시! 빌드를 하지 않아도 바로바로 변경사항을 확인할 수 있습니다. 항상 네이티브 개발, 특히 Android 앱 개발을 해오면서 최대 2분 이상 걸리는 빌드 환경 때문에 늘 코드를 잔뜩 작성해놓고 빌드를 최소화하는게 습관이 되어있던 저로서는 굉장한 기쁨이었습니다. (폭풍코딩하다 빌드 버튼 눌러놓고 한숨 돌리는게 업무 리듬이었는데, Hot Reload 덕분에 쉬지 않고 일할 수 있었습니다.. 따흑🥲)
크로스플랫폼 지원 💻
앞에서도 계속 이야기한것이지만, 제가 이제껏 써온 하이브리드 플랫폼 중에는 가장 탄탄하다고 생각이 드는 플랫폼입니다. 적은 인원과 빠른 시간만에 두 OS로 앱을 출시할 수 있었던 것은 ReactNative의 공이 가장 컸습니다. 심지어 저희 개발자 중에는 Windows 환경에서 개발한 개발자도 있답니다! 🤭 윈도우에서 iOS앱을 개발할 수 있다니 놀랍지 않나요?
빠른 배포 🚀
코드푸시를 사용함으로써, 스토어에서 앱을 심사받지 않고도 업데이트할 수 있다는 점이 가장 매력적입니다. 심사에 대한 부담감과 업데이트 기간을 단축시켜주고, 긴급 배포가 있을 때에도 정말 요긴했습니다. ReactNative + CodePush와 함께라면 2-3일씩 걸리던 앱 업데이트가 2-3초면 가능해집니다.
라이브러리 풀 📚
기본적인 api외에도 외부 라이브러리가 굉장히 많습니다. ‘혹시 이런 것도 있을까?’ 하는 것 마저 있습니다. ‘아, 요런거 없을 것 같은데 우리가 이 기회에 라이브러리 하나 만들어보자!’ => 있습니다. Native와의 브릿지 개발이 언젠간 필요하겠지싶어 프로젝트 초기 셋팅 때 CustomBridge를 만들 수 있도록 보일러플레이팅 작업을 했었는데요, 그 마저도 필요 없었을 정도로 커스텀 브릿지 하나 없이 프로젝트를 완성했습니다.
단점
더블 디버깅
디버깅이 힘듭니다. 오류보고에는 앱이 죽었다고 나와있는데, 스크립트 영역에서 화면을 그리다가 무언가의 이슈로 Fatal 오류가 나면 추적이 굉장히 어려워집니다. 또한 어떤 UI 이슈가 있을 때 ReactNative의 이슈인지, Native 영역의 이슈인지 두번 확인해야합니다. 일례로 FlatList 를 사용할 때 Android에서 스크롤 속도가 굉장히 느려지는 이슈가 있었는데요, FlatList 가 원인임을 찾기 전까지는 렌더링 이슈인지 컴포넌트 이슈인지, 데이터 이슈인지 정확한 원인 분석이 힘들었습니다.
라이브러리 버전 싱크
ReactNative 프로젝트 특성 상 외부 라이브러리를 많이 사용할 수 밖에 없게 되는데요, 각 라이브러리끼리 버전 충돌이 잦습니다. 또 OS 업데이트가 있을 때 ReactNative 버전을 올릴 일이 생기는데, 이런 경우에도 외부 라이브러리 버전을 모두 맞춰줘야합니다. 이번 iOS14 업데이트 당시에도 14 OS를 지원하는 ReactNative 버전으로 올리고나니 외부 라이브러리들이 해당 ReactNative 버전 대응이 늦어서 앱을 업데이트할 수 없었던 아찔한 상황이 있었습니다.
마치며
인마이백 프로젝트는 지금 이 순간에도 개발자들의 열정으로 빠르고 꾸준히 리팩토링 되고 있는 프로젝트입니다. 🔥 아직은 많은 시행착오를 거치고 있지만 조금씩 편리성과 성능을 개선해나가고 있습니다. 향후에는 Recoil, HoC 등 적용 계획이 있는데 올해 상반기 쯤에는 성공적인 리팩토링 적용기로 다시 한번 찾아봴 수 있으면 좋겠습니다!
react native 통합 배포 자동화하기
hybrid code는 스타트업에게 빠른 앱 출시를 가능하게 만들어주는 고마운 프레임워크임과 동시에 웹 개발 경험만으로 쉽게 앱을 만들 수 있게 해 줍니다. 하지만 배포 단계에서는 iOS와 android 각각의 배포 설정들과 출시 가이드를 따라야 하기 때문에 앱 개발보다 배포가 더 일이 될 수 있습니다. (각각의 앱 경력자가 있다면 이야기가 조금 다르겠지만… 있으면 네이티브로 개발을 했겠…) 적은 인원의 스타트업에서는 시간을 아끼기 위해 자동화는 필수이며 웹 개발은 이미 태그 한방으로 kubernetes에 배포가 되는 환경이니 앱이라고 그냥 방치하면 배포에 들어가는 시간이 너무 아까워 견딜 수가 없었기도 하고해서 자동화를 해보았습니다.
준비물
1. circle CI (유료 결제 필요)
mac os의 가상화를 위해 필수입니다. gitlab이나 travis CI도 mac os를 가상 머신으로 제공을 하지만 이런저런 이유로 circle CI를 사용하기로 했습니다. (아무 생각 없이 하다 보니 완성되어서…)
2. fastlane
android와 iOS의 배포를 쉽게 해주는 툴입니다. 대부분 로컬 PC(개발용)에서 각각 fastlane명령어를 실행해서 배포하는 것으로 알고 있습니다. 물론 저만 그랬을 수도 있습니다 ^^
자동화 구성 히스토리
1차
X 만드는 기계 설계도.png (도대체 무엇을 위한 자동화인가… 뭘 한거지…)
앱 개발을 마쳤을 때는 일단 출시가 먼저였습니다. 개발은 수월 했으나 개발 경력 10년 동안 앱 배포는 처음이어서… 웹에 대한 배포 자동화는 익숙하기 때문에 android를 먼저 자동화했습니다. mac os docker 이미지가 없는 줄만 알았기 때문이죠. 앱 배포할 때가 되면 돌아버릴 것 같았습니다. 이게 과연 자동화를 왜 했나 한 게 맞나 라는 자괴감과 mac 미니를 사서 빌드 서버로 써야 하나 어째야 하나 이걸 정말 나만 고민했을까 이래 저래 잠이 오질 않았었죠. 구성은 했지만 슬랙에 다운로드 링크만 온다 뿐이지 손수 aab파일을 다운로드하여 플레이 스토어에 등록을 하고 앱 스토어 배포를 위해 다시 배포용 폴더에서 다시 xcode를 실행해 archive 한 다음 distribution 하고… 그 이유이자 가장 큰 고민은 env 파일을 production용으로 주입해야 하는데 jenkins부터 cloud build까지 CI/CD에서 주입하던 저는 이걸 shell script를 만들어야 하나 어째야 하나 마땅한 방법이 생각나지를 않았습니다. 그래서 productin env를 포함하는 iOS용 빌드 폴더를 따로 만들어 최신 master pull 한 다음 버전과 빌드 넘버를 수정한 후… $%#$%@%@#@
2차
백조는 물아래에서 미친 듯이 발을 젓습니다.png
android gradle plugin에 플레이 스토어에 업로드되는 것이 있는 것을 알았습니다. 바로 업로드를 자동화하자마자 fastlane이라는 것이 있다는 것을 알게 되었습니다….. 지금 보니 정말 바보 같은 2차 구성입니다. fastlane을 알았는데 굳이 android를 왜 따로… 아무튼 스토어에 업로드하는 부분의 사람의 개입을 없앴지만 여전히 iOS에 대한 production env 파일 주입이 해결되지 않았습니다. 여전히 폴더를 옮겨가며 master를 pull 받고… @#$#@%@#%! 시간이 지났지만 그림으로만 봐도 너무 거슬려서 미쳐버릴 거 같군요!!
3차
circle ci + fastlane으로 배포 완전 자동화가 되었습니다.
드디어 ( 찾아보지도 않았으면서 ) circle CI에 mac os 이미지가 있다는 것을 알게 되었습니다! 자동화에 돈을 아끼지 않습니다 바로 3만 원을 결제합니다. (mac os 이미지는 유료 플랜에서만 지원됩니다. 내 시간이 3만 원보다 가취 있기를…) 이렇게 되면 아주 간단해집니다. web배포와 다를게 없어지니까요. 개발용 apk 빌드는 cloudbuild에 그대로 남겨놓고 gradle build부분만 fastlane으로 변경했습니다. circle CI로 전체 통합을 할 수 도 있겠지만 유료 결제에 credit 차감 형식이라 나름 아껴봤습니다. (사실 앱이 열개가 넘어가지 않는다면 충분한 credit인 것 같습니다.. 아아 굳이 또 안 해도 될 일을…) circle CI는 workflow를 지원하기 때문에 react native에 fit 하다고 생각됩니다. javascript 부분에서 unit testing과 linting 등을 하고 android, iOS로 각각 빌드, 배포할 수 있기 때문입니다. yarn version 커맨드를 이용해 버전을 올리고 fastlane에 있는 load_json으로 package.json을 읽어와 package.json 버전 기준으로 android와 iOS의 버전을 맞춰줍니다. 또 한 fastlane에서 자동으로 build number(version code)를 올려 주기 때문에 빌드와 배포가 전부 성공하면 repository를 push 해 줍니다. 플로우를 정리해보면
1. 배포 versioning -> yarn version
2. circle CI workflow trigger
3. javascript verify (lining, testing,…)
4. iOS, android 각각 build, archive -> fastlane
5. 변경 사항 repository commit & push
6. 슬랙 알림
7. 출시 관리자 각 스토어 트랙 확인 후 프로덕션 배포 & 심사 제출
십 년 묶은 뭔가가 내려간 것 같습니다. 혼돈의 카오스였던 앱 배포가 yarn version 커맨드 하나로 6번까지 자동화가 되었습니다. 이제 슬랙으로 알림을 받은 출시 관리자(아마도… 자동화를 한 본인일 가능성이 크겠죠…)가 출시 메시지와 함께 스토어에 게시만 하면 되는 것입니다.
아름다운 workflow입니다…
자 이렇게 번 시간은 다른 일을 하는데 씁니다… 술을 먹으러 가도록 합시다.
이로써 케어닥은 웹 배포는 cloudbuild + git ops로 자동화되었고, 앱 배포는 circle CI + fastlane으로 자동화되었습니다. 개발자들은 개발에만 신경 쓰면 되는 것이죠! 정말 신이 나지 않습니까?
이렇게 케어닥에 합류해 함께 다양한 방법을 시도해가며 서비스를 만들어가실 분들을 찾고 있습니다. 하단의 채용 링크를 통해 지원해주세요!
[백엔드 개발자] https://www.rocketpunch.com/jobs/74712/%EC%98%88%EB%B9%84-%EC%9C%A0%EB%8B%88%EC%BD%98-%EC%8A%A4%ED%83%80%ED%8A%B8%EC%97%85-%EC%BC%80%EC%96%B4%EB%8B%A5%EA%B3%BC-%ED%95%A8%EA%BB%98%ED%95%98%EC%8B%A4-%EB%B0%B1%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%B1%84%EC%9A%A9 [프런트엔드 개발자] https://www.rocketpunch.com/jobs/66523/%EC%98%88%EB%B9%84-%EC%9C%A0%EB%8B%88%EC%BD%98-%EC%8A%A4%ED%83%80%ED%8A%B8%EC%97%85-%EC%BC%80%EC%96%B4%EB%8B%A5%EA%B3%BC-%ED%95%A8%EA%BB%98%ED%95%98%EC%8B%A4-%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%B1%84%EC%9A%A9 [콘텐츠 마케터] https://www.rocketpunch.com/jobs/72996/%EC%8B%A4%EB%B2%84%EC%82%B0%EC%97%85%EC%9D%98-%EC%9C%A0%EB%8B%88%EC%BD%98%EC%97%90-%ED%83%91%EC%8A%B9%ED%95%A0-%EC%BD%98%ED%85%90%EC%B8%A0-%EB%A7%88%EC%BC%80%ED%84%B0
ReactNative – 안드로이드 배포용 APK생성하기
1. 키 스토어 생성
먼저 키 스토어를 생성해 준다.
keytool -genkey -v -keystore [your_key_name].keystore -alias [your_key_alias] -keyalg RSA -keysize 2048 -validity 10000
[your_key_name] 와 [your_key_alias] 에 원하는대로 작성한다.추가 정보들을 입력해 준다.
Enter your keystore password: ******** Re-enter new password: ******** What is your first and last name? [unknown]: first last What is the name of your organizational unit? [unknown]: company dev What is the name of your organization? [unknown]: company What is the name of your city or Locality? [unknown]: korea What is the name of your State or Province? [unknown]: seoul What is the two-letter country code for this unit? [unknown]: KR
그러면 [name].keystore 파일이 생성되는데 한번 스토어에 등록된 키스토어 파일은 변경이 불가능하니 잘 간직하도록 하자.
프로젝트 상위에 생성된 키스토어파일을 /android/app 폴더로 옮겨준다.
mv [name].keystore ./android/app
2. gradle config
~/.gradle/gradle.properties 또는 android/gradle.properties 파일에 다음을 추가한다.
MYAPP_UPLOAD_STORE_FILE=[name].keystore MYAPP_UPLOAD_KEY_ALIAS=[alias-name] MYAPP_UPLOAD_STORE_PASSWORD=******** MYAPP_UPLOAD_KEY_PASSWORD=********
android/app/build.gradle 파일에 해당 release들을 추가한다.
… android { …defaultConfig { … } signingConfigs { release { if (project.hasProperty(‘MYAPP_UPLOAD_STORE_FILE’)) { storeFile file(MYAPP_UPLOAD_STORE_FILE) storePassword MYAPP_UPLOAD_STORE_PASSWORD keyAlias MYAPP_UPLOAD_KEY_ALIAS keyPassword MYAPP_UPLOAD_KEY_PASSWORD } } } buildTypes { release { … signingConfig signingConfigs.release } } } …
3. Apk(aab)생성
/android폴더로 이동한 뒤 해당 명령 실행
abb파일 생성
./gradlew bundleRelease
apk파일 생성
./gradlew app:assembleRelease
playstore에 올리고 싶으면 abb로 하자!
4. play store console에 등록
드래그&드롭으로 등록하고 테스트 진행 후 사용하면 된다.
새로운 버전으로 바꿀 때는 /android/app/build.gradle 에서
versionCode, versionName 두 개를 하나씩 올려주며 새로 빌드하면 된다.
참고
[react-native] 안드로이드 APK(AAB) 파일 생성하기📱에러발생ㅠ
에러가 발생했지만 어떤 에러인지도 알수가 없었다. 아래 명령어를 추가함으로 에러를 다시 확인했다.
./gradlew bundleRelease –warning-mode all
Error: Duplicate resources
흔히 발생하는 에러인지 구글에서 쉽게 발견할 수 있었다.
/android/app/src/main/res 에 있는 drawable이라고 시작하는 다양한 파일들을 모두 지우고 다시 도전했다.
[React-Native] apk 생성하는 방법([email protected] 오류 발생 시 대처법)성공하는 듯 싶었으나 다시 한 번 Error: Duplicate resources 에러가 발생 했다.
콘솔을 차근히 읽어보니 /android/app/src/main/res/raw 폴더안에 왜때문에 생긴지 모르는 json파일들이 때문이었고
json파일들까지 제거해주니 성공적으로 build
안드로이드 앱 스토어 등록
개요
RN(React Native)로 개발한 안드로이드 앱(Android App)을 안드로이드 앱 스토어(Google Play)에 등록하려고 합니다. 안드로이드 앱(Android App)을 안드로이드 앱 스토어(Google Play)에 등록하기 위해서는 안드로이드 개발자 등록(구글 플레이 개발자 등록)이 필요합니다. 안드로이드 개발자 등록(구글 플레이 개발자 등록)을 하지 않으신 분은 이전 블로그를 참고하여 등록하시기 바랍니다.(안드로이드 개발자 등록)
이 블로그는 연재물입니다. 아래에 내용을 함께 참고하시길 바랍니다.
준비
RN(React Native)로 개발한 안드로이드 앱(Android App)을 안드로이드 앱 스토어(Google Play)에 등록하기 위해서는 RN(React Native)를 안드로이드용으로 빌드할 필요가 있습니다. RN(React Native)에 안드로이드 서명키(Android Signing Key)를 등록하고 안드로이드용으로 빌드하는 방법에 대해서는 이전 블로그를 참고하시기 바랍니다.
빌드 파일 사이즈 최적화
이전 블로그인 안드로이드 빌드 및 테스트에서 안드로이드용으로 빌드된 파일은 파일 사이즈의 최적화가 되어있지 않습니다. RN(React Native)로 개발한 안드로이드 앱(Android App)을 안드로이드 앱 스토어(Google Play)에 업로드하기 위해서 빌드 파일 사이즈를 최적화할 필요가 있습니다.
RN(React Native) 프로젝트 폴더에서 android/app/build.gradle 을 열고 아래와 같이 수정합니다.
… defaultConfig { … // ndk { // abiFilters “armeabi-v7a” , “x86” // } } … def enableSeparateBuildPerCPUArchitecture = true def enableProguardInReleaseBuilds = true … buildTypes { release { shrinkResources true … } } ..
enableSeparateBuildPerCPUArchitecture: apk 파일 빌드시 각 CPU 별로 파일을 분리해서 apk 파일을 생성합니다. 다른 CPU에 필요한 파일 내용들이 빠지므로 파일 용량이 작아집니다. 대신 apk 파일이 여러개 생기며, 앱을 배포할시 생성된 apk 파일 모두를 업로드하셔야합니다.
enableProguardInReleaseBuilds: 코드 난독화에 필요한 Proguard를 활성화합니다. Proguard는 코드 난독화를 해주는 동시에 코드 사이즈를 줄여주므로 파일 용량이 작아집니다.
shrinkResources: 불필요한 리소스를 제거하여 파일 사이즈를 작게 만듭니다. (앱에서 로컬 이미지가 표시되지 않는다면 이 부분을 false로 변경하여 사용하시기 바랍니다.)
그리고 아래의 명령어를 통해 RN(React Native)를 안드로이드용으로 빌드합니다.
# react-native bundle –platform android –dev false –entry-file index.js –bundle-output android/app/src/main/assets/index.android.bundle # cd android # ./gradlew assembleRelease ./gradlew app:assembleRelease –stacktrace
여기서 –stacktrace 옵션을 붙이는 이유는 enableProguardInReleaseBuilds = true 로 설정할 경우 아래와 같은 빌드 에러가 발생할 경우가 있기 때문입니다.
… Note: the configuration keeps the entry point ‘okhttp3.internal.ws.WebSocketWriter { void writePong(okio.ByteString); }’ , but not the descriptor class ‘okio.ByteString’ Note: the configuration keeps the entry point ‘okhttp3.internal.ws.WebSocketWriter { void writeClose(int,okio.ByteString); }’ , but not the descriptor class ‘okio.ByteString’ Note: the configuration keeps the entry point ‘okhttp3.internal.ws.WebSocketWriter { void writeControlFrame(int,okio.ByteString); }’ , but not the descriptor class ‘okio.ByteString’ Note: the configuration keeps the entry point ‘okhttp3.internal.ws.WebSocketWriter$FrameSink { void write(okio.Buffer,long); }’ , but not the descriptor class ‘okio.Buffer’ Note: the configuration keeps the entry point ‘okio.AsyncTimeout { void scheduleTimeout(okio.AsyncTimeout,long,boolean); }’ , but not the descriptor class ‘okio.AsyncTimeout’ Note: the configuration keeps the entry point ‘okio.AsyncTimeout { boolean cancelScheduledTimeout(okio.AsyncTimeout); }’ , but not the descriptor class ‘okio.AsyncTimeout’ Note: the configuration keeps the entry point ‘okio.AsyncTimeout { okio.Sink sink(okio.Sink); }’ , but not the descriptor class ‘okio.Sink’ Note: the configuration keeps the entry point ‘okio.AsyncTimeout { okio.Source source(okio.Source); }’ , but not the descriptor class ‘okio.Source’ Note: the configuration keeps the entry point ‘okio.ForwardingSink { ForwardingSink(okio.Sink); }’ , but not the descriptor class ‘okio.Sink’ Note: the configuration keeps the entry point ‘okio.ForwardingSink { void write(okio.Buffer,long); }’ , but not the descriptor class ‘okio.Buffer’ Note: the configuration keeps the entry point ‘okio.ForwardingSource { ForwardingSource(okio.Source); }’ , but not the descriptor class ‘okio.Source’ Note: the configuration keeps the entry point ‘okio.ForwardingSource { long read(okio.Buffer,long); }’ , but not the descriptor class ‘okio.Buffer’ … * What went wrong: Execution failed for task ‘:app:transformClassesAndResourcesWithProguardForRelease’ . > Job failed, see logs for details …
위와 같이 빌드 에러가 발생하는 경우 android/app/proguard-rules.pro 파일을 열고 하단에 아래와 같이 추가합니다.
# Note: the configuration keeps the entry point ‘okio.AsyncTimeout { void scheduleTimeout(okio.AsyncTimeout,long,boolean); }’, but not the descriptor class ‘okio.AsyncTimeou -dontwarn okio. ** # Note: the configuration keeps the entry point ‘okhttp3.internal.ws.WebSocketWriter$FrameSink { void write(okio.Buffer,long); }’, but not the descriptor class ‘okio.Buffer’ -dontwarn okhttp3. **
이외에도 사용하시는 라이브러리에 따라 더 많은 에러가 발생할 수 있습니다. 그에 따라 android/app/proguard-rules.pro 을 수정하시기 바랍니다.
빌드된 파일은 아래의 경로에서 확인할 수 있습니다.
android/app/build/outputs/apk/release/app-arm64-v8a-release.apk.apk android/app/build/outputs/apk/release/app-armeabi-v7a-release.apk.apk android/app/build/outputs/apk/release/app-x86_64-release.apk.apk android/app/build/outputs/apk/release/app-x86-release.apk.apk
이 모든 파일을 업르도 해야합니다.
앱 등록
아래의 링크를 선택하여 구글 플레이 콘솔(Google Play Console)로 이동합니다.
구글 플레이 콘솔(Google Play Console): https://play.google.com/apps/publish/
구글 플레이 콘솔(Google Play Console)에 이동하면 아래와 같은 화면을 볼 수 있습니다.
화면 상단에 보이는 PUBLISH AN ANDROID APP ON GOOGLE PLAY 버튼을 선택합니다.
안드로이드 앱 스토어(Google Play)에 표시될 이름과 기본 언어를 선택합니다.
안드로이드 앱 스토어(Google Play)에 표시될 정보들을 입력합니다.
제목(title): 50자
요약 설명(short description): 80자
전체 설명(full description): 4000자
앱 이미지(Screenshots)
앱 아이콘(App icon): 512×512(32-bit PNG, alpha), 1024×500(JPG or 24-bit PNG), 180×120(JPG or 24-bit PNG), 1280×720(JPG or 24-bit PNG), 4096×4096(JPG or 24-bit PNG)
프로모션 비디오(Promo Video)
앱 카테고리(Category)
개발자 연락처(Contact details)
개인 정보 정책(Privacy Policy)
모든 정보 입력이 끝났다면 이제 apk 파일을 등록하는 방법에 대해서 알아보겠습니다.
왼쪽 위에 App release 메뉴를 선택하면 아래와 같은 화면을 볼 수 있습니다.
화면에서 보이는 Production track 의 Production 항목의 MANAGE 를 선택합니다.
위와 같은 화면이 보이면 하단의 CREATE RELEASE 를 선택합니다.
구글 플레이(Google Play)를 이용하여 앱 서명(App Signing)을 하기 위해 FINISH 버튼을 선택합니다.
위와 같이 약관이 표시되면 하단의 ACCEPT 버튼을 눌러 동의합니다.
위에서 빌드한 RN(React Native)의 apk 파일을 업로드합니다.
앱의 배포 이름(Release Name)과 배포 노트(Relase Note)를 작성하고 오른쪽 하단의 SAVE 버튼을 누릅니다. 그러면 오른쪽의 REVIEW 버튼이 활성화됩니다. 활성화된 REVIEW 버튼을 누릅니다.
앱 등록에 필요한 절차가 끝나지 않았기 때문에 오른쪽 하단의 START ROLLOUT TO PRODUCTION 버튼이 활성화되지 않았습니다. 왼쪽 메뉴의 Content rating 을 선택합니다.
콘텐츠 등급(Content Rating)을 설정하는 화면입니다. CONTINUE 를 선택합니다
이메일 정보와 앱의 카테고리를 선택합니다.
앱에 콘텐츠 등급을 정하기 위한 정보를 선택합니다. 전부 선택하였다면 하단의 SAVE QUESTIONNAIRE 버튼을 선택하고 활성화된 CALCULATE RATING 을 선택합니다.
입력한 정보에 의해 콘텐츠 등급이 계산되어 나옵니다. 내용을 확인하고 하단의 APPLYING RATING 을 선택합니다.
콘텐츠 등급 입력이 완료되었습니다. 콘텐츠 등급에 영향이 있는 업데이트가 있다면 콘텐츠 등급을 다시 계산하여 등록하셔야합니다.
이제 마지막 절차인 가격 설정으로 이동합니다. 왼쪽 메뉴의 Pricing & distribution 을 선택합니다.
앱의 가격을 설정하는 화면입니다. 우리는 무료로 앱을 제공할 예정이므로 FREE 를 설정하고 진행합니다. 또한 어린이 대상인지, 앱에 광고가 포함되었는지 등 정보를 입력합니다. 필수 항목을 전부 진행하였다면 하단의 SAVE DRAFT 를 선택합니다.
앱 심사 신청
드디어 앱 심사(App Review)를 위한 준비가 끝났습니다. 다시 메뉴의 App release 를 선택합니다.
위에서 작성한 Production 항목 옆에 EDIT RELEASE 버튼을 선택합니다.
위에서 작성한 내용이 보입니다. 스크롤하여 하단으로 이동한 후, REVIEW 버튼을 선택합니다.
위와 같은 화면이 보인다면 스크롤하여 하단으로 이동한 후 START ROLLOUT TO PRODUCTION 버튼을 선택합니다.
앱 심사 준비가 끝났다면 CONFIRM 버튼을 눌러 앱 심사를 신청합니다.
에러 대응
아래에 명령어로 안드로이드를 빌드할 때,
./gradlew assembleRelease
아래와 같은 에러 메세지가 나오면서 빌드가 실패할 때가 있습니다.
Execution failed for task ‘:app:transformDexArchiveWithExternalLibsDexMergerForRelease’ .
아래에 내용을 android/app/build.gradle 에 추가하고 다시 빌드합니다.
defaultConfig { … multiDexEnabled true }
빌드 에러 대응
RN(React Native) 버전 0.58에서 아래에 명령어로 빌드를 시도하면
./gradlew assembleRelease
아래와 같은 에러가 나옵니다.
–auto-add-overlay \ –non-final-ids \ -0 \ apk \ –no-version-vectors Daemon: AAPT2 aapt2-3.2.1-4818971-osx Daemon #0
아래에 명령어로 진행하면 에러없이 빌드를 할 수 있습니다.
./gradlew app:assembleRelease
권한 에러
RN(React Native) 0.58 버전에 파일을 구글 플레이에 없로드 하면 android.permission.READ_PHONE_STATE 권한이 포함되어 있다며 에러가 나옵니다.
공식 홈페이지에 해결 방법이 나와있습니다.
https://facebook.github.io/react-native/docs/removing-default-permissions
한번 따라해 봅시다.
RN(React Native) 프로젝트의 android/app/src/main/AndroidManifest.xml 파일을 열어 아래와 같이 수정합니다.
+ + + … 그리고 android/app/src/release/AndroidManifest.xml 파일을 생성하고 아래에 내용을 복사 붙여넣습니다.(패키지명을 자신의 패키지명으로 교체해주세요.)
Android 4.4.2 Kitkat
RN(React Native) 0.58에서 빌드한 파일을 안드로이드 4.4.2(Kitkat) 단말기에서 테스트할 때, 앱이 crash나면서 기동하지 못하는 문제가 발생하였습니다. 조사해 본 결과 multiDexEnabled 의 문제로 아래의 내용을 더 추가하여 해결하였습니다.
RN(React Native) 프로젝트의 android/app/build.gradle 을 열고 아래에 내용을 추가합니다.
dependencies { implementation project ( ‘:react-native-firebase’ ) … implementation ‘com.android.support:multidex:1.0.1’ }
또한 MainApplication.java 를 열고 아래와 같이 수정합니다.
import android.app.Application ; import android.content.Context ; import android.support.multidex.MultiDex ; … public class MainApplication extends Application implements ReactApplication { @Override protected void attachBaseContext ( Context base ) { super . attachBaseContext ( base ); MultiDex . install ( this ); } … }
이렇게 수정한 후 안드로이드 4.4.2(Kitkat)에서 무사히 동작하는 것을 확인할 수 있습니다.
Unoptimised APK
최근 APK 파일을 업로드하여 업데이트할 시 아래와 같은 경고 메세지가 표시되었습니다.
아래에 명령어로 apk가 아닌 app bundle을 생성합니다.
./gradlew app:bundleRelease
이 명령어로 생성된 파일은 android/app/build/outputs/bundle/release/app.aab 에 위치합니다.
이 파일 하나를 업로드하면 됩니다.
저는 package.json 에 아래에 스크립트를 추가하여 사용하고 있습니다.
… “scripts” : { … “prebuild-android” : “react-native bundle –platform android –dev false –entry-file index.js –bundle-output android/app/src/main/assets/index.android.bundle” , “build-android” : “cd ./android && ./gradlew app:bundleRelease –stacktrace ” } …
그리고 아래에 명령어를 통해 빌드하고 있습니다.
npm run build-android
완료
안드로이드 앱 스토어(Google Play)에 앱 등록을 위한 모든 절차가 끝났습니다. 앱 심사는 2~3시간 정도 걸리며 앱 심사가 끝나면 등록 신청을 한 앱을 안드로이드 앱 스토어(Google Play)에서 검색 및 다운로드 할 수 있습니다.
제 블로그가 도움이 되셨나요? 하단의 댓글을 달아주시면 저에게 큰 힘이 됩니다!
앱 홍보
책 홍보
[React Native] Android 배포용 빌드하기
어제 포폴용으로 만든 RN 앱을 리드 미까지 다 작성하고 나서 빌드도 해보고 싶단 생각이 들었다. 정리해두면 좋을 것 같아서 전부터 시작하려고 했던 블로그를 이제 시작하게 되었다 !
맥북이 없기 때문에.. 윈도우 데스크탑으로 안드로이드 빌드 시작!
참조사이트: ReactNative 공식문서
1. 서명 키 생성
/android/app 경로에서 아래 코드를 입력한다.
$ keytool -genkeypair -v -keystore my-upload-key.keystore -alias my-key-alias -keyalg RSA -keysize 2048 -validity 10000
그러면 키 저장소 비밀번호를 입력하라고 뜨는데 입력하고 나면 이름과 성을 .. 조직 단위를.. 조직 이름을.. 조직의 두 자리 국가 코드를 입력해라 등등.. (KR 로 입력했음) 입력하라는게 몇개 나온다. 그것을 다 입력하면,
my-key-alias 에 대한 키 비밀번호를 입력하라고 뜨는데 키 저장소와 동일한 비번을 쓰고 싶다면 엔터키를 누르면 된다.
2. Gradle 변수 설정
/android/gradle.properties 경로
MYAPP_RELEASE_STORE_FILE=my-upload-key.keystore MYAPP_RELEASE_KEY_ALIAS=my-key-alias MYAPP_RELEASE_STORE_PASSWORD=위에서 지정한 비밀번호 MYAPP_RELEASE_KEY_PASSWORD=위에서 지정한 비밀번호
/android/app/build.gradle 경로
android { … defaultConfig { … } splits { … } signingConfigs { release { if (project.hasProperty(‘MYAPP_RELEASE_STORE_FILE’)) { storeFile file(MYAPP_RELEASE_STORE_FILE) storePassword MYAPP_RELEASE_STORE_PASSWORD keyAlias MYAPP_RELEASE_KEY_ALIAS keyPassword MYAPP_RELEASE_KEY_PASSWORD } } } buildTypes { release { … signingConfig signingConfigs.release } } }
이 단계에서
FAILURE: Build failed with an exception. [36D> :app > Compiling D:\…\android\app\build.gradle into local compilation cache * Where: Build file ‘D:\…\android\app\build.gradle’ line: 221 * What went wrong: Could not compile build file ‘D:\…\android\app\build.gradle’. > startup failed: build file ‘D:\…\android\app\build.gradle’: 221: expecting ‘}’, found ” @ line 221, column 1. 1 error * Try: Run with –stacktrace option to get the stack trace. Run with –info or –debug option to get more log output. Run with –scan to get full insights. * Get more help at https://help.gradle.org BUILD FAILED in 2s
이런 이상한 에러를 만났는데 .. signingConfigs 에 if문을 입력하고 나서 중괄호를 하나 빼먹는 바보같은 실수를 하는 바람에 시간을 날렸다 ㅠ.ㅠ… 복붙해서 넣다가 생긴 실수이니 꼭 확인하기!!
3. 빌드 명령어
/android 경로 터미널에다 아래 코드를 입력한다.
./gradlew assembleRelease
그럼 몇분가량 소요되면서 빌드 성공!
성공한 apk파일은
/android/app/build/outputs/apk/app-release.apk 에 있다.
이 파일을 가지고 구글 플레이 콘솔가서 배포하면 된다!
키워드에 대한 정보 react native 배포
다음은 Bing에서 react native 배포 주제에 대한 검색 결과입니다. 필요한 경우 더 읽을 수 있습니다.
이 기사는 인터넷의 다양한 출처에서 편집되었습니다. 이 기사가 유용했기를 바랍니다. 이 기사가 유용하다고 생각되면 공유하십시오. 매우 감사합니다!
사람들이 주제에 대해 자주 검색하는 키워드 리액트 네이티브 배포용 APK 빌드하기
- 아두이노
- arduino
- 디바이스마트
- devicemart
- 새로운시작
- neosarchizo
- android
- 안드로이드
- 모바일 앱
- mobile app
- react native
- 리액트 네이티브
- java
- javascript
- 자바
- 자바스크립트
- 타입스크립트
- typescript
- react-native-serialport
- serial communication
- 시리얼 통신
리액트 #네이티브 #배포용 #APK #빌드하기
YouTube에서 react native 배포 주제의 다른 동영상 보기
주제에 대한 기사를 시청해 주셔서 감사합니다 리액트 네이티브 배포용 APK 빌드하기 | react native 배포, 이 기사가 유용하다고 생각되면 공유하십시오, 매우 감사합니다.