⎮ 앱 배포하기
이전 포스팅을 통해 배포를 잘 해냈다면, 재배포는 더 쉽다!
iOS | AppStore에 배포하기(feat. 한 큐에 바로 성공!)
앱 배포 전 실기기 빌드로 테스트하기⎮ 사전 준비 팀프로젝트를 하게 되면, 실기기 빌드를 위한 초기세팅을 해줘야 한다 "엥? 빌드를 할건데 초기 세팅을 한다고?" 할 수도 있다 혼자 프로젝트
uddt.tistory.com
먼저 버전 규칙에 따라 버전을 바꿔야 한다
앱 재배포하기(업데이트)
⎮ 버전 규칙
Semetic Versioning이라는 것이 있다
유의적 버전 2.0.0
Semantic Versioning spec and website
semver.org
위 문서는 버전 번호를 어떻게 정하고 올려야 하는지를 명시하는 규칙과 요구사항을 제안한 것으로, 버전을 X.Y.Z (주.부.수) 형식으로 정한다.
> 1.0.0과 같은 형태
API에 영향이 없는 버그 수정은 수(修)버전을 올리고,
> 1.0.1
API가 호환되면서 바꾸거나 추가하는 경우에는 부(部)버전을 올리고,
> 1.1.0
API가 호환되지 않는 변경이라면 주(主)버전을 올린다.
> 2.0.0
⎮ 버전 규칙 쉽게 이해하기
그냥 어떻게 이해하면 되냐면,
1. 형식(x. y. z)
X (주버전): 큰 변화가 있을 때 (예: 기존 기능이 없어지고 새로 바뀔 때)
Y (부버전): 기존 기능은 그대로 두고, 새로운 기능이 추가될 때
Z (수버전): 버그만 고친 경우(기능 변화 없을 때)
1.0.0과 같은 형태가 바로 x.y.z이다
2. 버전 번호 규칙
1) 숫자만 사용해야 하고, 앞에 0을 붙이면 안 된다
→ 예: 1.09.0 (잘못된 형식), 1.9.0
2) 버전은 항상 올라가기만 해야한다
→ 예: 1.9.0 다음엔 1.10.0 그 다음엔 1.11.0
3) 한 번 배포된 버전은 수정하면 안 된다
→ 수정할 게 있다면 꼭 버전을 새로 올려서 배포해야 해요.
3. 사용 예시
* 기존 버전 1.0.0
1) 버그만 고친 상황
1.0.0 → 1.0.1
2) 새 기능 추가(기존에서 호환되는 기능)
1.0.1 → 1.1.0
3) 기존 기능 변경(호환 안됨)
1.1.0 → 2.0.0

⎮ Archive 하기
위처럼 Version과 빌드 숫자를 변경해주었으면 배포 때와 동일하게 Archive를 하면 된다


조금 기다리면, 위 화면이 뜰텐데 여기서 Validate App을 눌러주면 된다


조금 기다렸다가 완료가 되면 Destribute App을 눌러주고,



마찬가지로 다음의 절차들을 완료하고 Done을 누르면 AppStore Connect에서 해당 빌드를 확인할 수 있다
⎮ TestFlight부터 심사까지
https://appstoreconnect.apple.com/
https://appstoreconnect.apple.com/
appstoreconnect.apple.com
위 사이트에서 앱을 누르고 들어가서 TestFlight로 들어가면 된다

들어가면 '처리 중'이라고 떠있을텐데 약 5분정도 기다리면 위의 상태가 되고,
그룹에 + 버튼을 누르면 테스터를 추가할 수 있다
실기기로 빌드하면서 테스트해본 후 이상이 없으면, 배포 탭을 누른다

하단에 업그레이드 된 사항을 작성해주고,

여기서 새롭게 추가한 빌드를 넣어준 뒤 제출해주면 된다
'스파르타코딩 클럽 > 기초' 카테고리의 다른 글
| iOS | AppStore에 배포하기(feat. 한 큐에 바로 성공!) (1) | 2025.06.21 |
|---|---|
| Swift | 모야(Moya)가 모야요? (0) | 2025.05.25 |
| Swift | 유저 디폴트(UserDefaults) 이해하기 (0) | 2025.05.24 |
| Swift | KingFisher(feat. 이미지 캐싱) (0) | 2025.05.17 |
| Swift | CocoaPods 설치하기 (0) | 2025.04.26 |