본문 바로가기
스파르타코딩 클럽/기초

iOS | AppStore에 재배포하기(업데이트)

by UDDT 2025. 6. 24.

 앱 배포하기

     이전 포스팅을 통해 배포를 잘 해냈다면, 재배포는 더 쉽다!

    https://uddt.tistory.com/301

 

iOS | AppStore에 배포하기(feat. 한 큐에 바로 성공!)

앱 배포 전 실기기 빌드로 테스트하기⎮ 사전 준비 팀프로젝트를 하게 되면, 실기기 빌드를 위한 초기세팅을 해줘야 한다 "엥? 빌드를 할건데 초기 세팅을 한다고?" 할 수도 있다 혼자 프로젝트

uddt.tistory.com

 

     먼저 버전 규칙에 따라 버전을 바꿔야 한다

앱 재배포하기(업데이트)

 버전 규칙

    Semetic Versioning이라는 것이 있다

    https://semver.org/lang/ko/

 

유의적 버전 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분정도 기다리면 위의 상태가 되고,

    그룹에 + 버튼을 누르면 테스터를 추가할 수 있다

 

    실기기로 빌드하면서 테스트해본 후 이상이 없으면, 배포 탭을 누른다

 

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

 

    여기서 새롭게 추가한 빌드를 넣어준 뒤 제출해주면 된다

 

최근댓글

최근글

skin by © 2024 ttuttak