SwiftUI 앱 출시 완벽 가이드 — App Store Connect 등록, 인증서, TestFlight, 앱 심사와 배포
SwiftUI로 앱 개발을 완료했다면 이제 App Store에 출시할 차례입니다.
Android 개발자는 Google Play Console에서 AAB 파일을 업로드하고 앱 정보를 등록한 뒤 심사를 요청하는 과정에 익숙할 것입니다.
iOS 역시 비슷한 흐름이지만 개발자 계정, 인증서, Provisioning Profile, App Store Connect, TestFlight 등 여러 요소를 이해해야 합니다.
특히 iOS는 앱 서명과 배포 설정이 Android와 다르기 때문에 처음 출시하는 개발자는 예상보다 많은 시간을 소비할 수 있습니다.
이번 글에서는 SwiftUI로 개발한 앱을 실제 App Store에 등록하는 과정을 단계별로 살펴보겠습니다.
사진 콜라주 앱을 예제로 사용하지만 달력, 메모, 생물도감, 정보 제공 앱에도 동일하게 적용할 수 있습니다.
1. 이번 글에서 다룰 내용
Apple Developer Program 가입
Bundle Identifier 등록
Xcode Signing 설정
인증서와 Provisioning Profile 이해
앱 버전 및 빌드 번호 관리
App Store Connect 앱 생성
앱 아이콘 및 스크린샷 준비
Archive 생성 및 업로드
TestFlight 테스트
개인정보 공개 항목 작성
앱 심사 정보 입력
인앱결제와 광고 관련 점검
App Review 심사 대응
앱 출시 및 업데이트
개발 환경
| 항목 | 내용 |
|---|---|
| 개발 언어 | Swift |
| UI | SwiftUI |
| 개발 도구 | Xcode |
| 배포 플랫폼 | Apple App Store |
| 앱 관리 | App Store Connect |
| 테스트 배포 | TestFlight |
| 앱 서명 | Apple Developer Signing |
2. Android와 iOS 배포 방식 비교
먼저 Google Play와 App Store의 배포 과정을 비교해 보겠습니다.
| Android | iOS | 역할 |
|---|---|---|
| Google Play Console | App Store Connect | 앱 등록 및 관리 |
| Google Play 개발자 계정 | Apple Developer Program | 개발자 자격 |
| applicationId | Bundle Identifier | 앱 식별자 |
| versionName | Marketing Version | 사용자 표시 버전 |
| versionCode | Build Number | 빌드 구분 |
| AAB | App Archive / 업로드 빌드 | 배포 패키지 |
| App Signing | Code Signing | 앱 서명 |
| Internal Testing | TestFlight Internal Testing | 내부 테스트 |
| Closed Testing | TestFlight External Testing | 외부 테스트 |
| Play Store Review | App Review | 앱 심사 |
Android에서는 Gradle을 중심으로 빌드와 서명을 관리합니다.
iOS에서는 Xcode 프로젝트 설정과 Apple Developer 계정을 중심으로 서명 및 배포를 관리합니다.
3. Apple Developer Program 가입
App Store에 앱을 배포하려면 Apple Developer Program에 가입해야 합니다.
공식 사이트:
https://developer.apple.com/programs/
Apple Developer Program은 일반적으로 연간 99달러의 멤버십 비용이 발생하며, 국가 및 지역에 따라 현지 통화와 세금 등이 적용될 수 있습니다.
개인 계정과 조직 계정 중 선택할 수 있습니다.
| 구분 | 개인 | 조직 |
|---|---|---|
| 가입 주체 | 개인 개발자 | 법인 또는 조직 |
| App Store 판매자 표시 | 개인 법적 이름 | 조직 법적 이름 |
| 조직 확인 | 일반적으로 불필요 | 법적 조직 확인 필요 |
| 팀 관리 | 상대적으로 제한적 | 역할별 구성원 관리 가능 |
개인 개발자라면 개인 계정으로 시작할 수 있습니다.
다만 App Store에 표시되는 판매자 이름은 별도의 앱 브랜드 이름과 다를 수 있으므로 가입 전에 확인하는 것이 좋습니다.
4. Bundle Identifier 이해하기
Android에서 앱을 구분하는 applicationId와 비슷한 개념이 iOS의 Bundle Identifier입니다.
예를 들어 다음과 같이 설정할 수 있습니다.
com.example.photocollageXcode에서는 다음 메뉴에서 확인할 수 있습니다.
Project
→ Targets
→ Signing & Capabilities
→ Bundle IdentifierBundle Identifier는 App Store Connect에 등록하는 앱과 연결됩니다.
앱을 출시한 이후에는 기존 앱의 식별자를 임의로 변경할 수 없으므로 처음부터 일관된 규칙을 사용하는 것이 좋습니다.
5. Bundle Identifier 등록
Apple Developer 사이트에서 앱 식별자를 등록할 수 있습니다.
https://developer.apple.com/account/
다음 메뉴로 이동합니다.
Certificates, Identifiers & Profiles
→ Identifiers
→ +
→ App IDs
→ App앱의 Bundle Identifier를 입력합니다.
예를 들어 다음과 같습니다.
com.example.photocollagePush Notifications, Associated Domains, App Groups 등 특정 기능을 사용한다면 필요한 Capability도 확인해야 합니다.
일반적인 앱은 Xcode의 Automatically Manage Signing 기능을 사용하면 많은 서명 관련 설정을 자동으로 처리할 수 있습니다.
6. 인증서와 Provisioning Profile 이해하기
iOS 앱 배포에서 자주 등장하는 개념이 인증서와 Provisioning Profile입니다.
Certificate
앱 서명에 사용하는 개발자 또는 배포용 인증서입니다.
Provisioning Profile
앱 식별자, 서명 정보, 허용된 기능과 배포 방식 등을 연결하는 설정입니다.
App ID
앱의 식별자와 기능을 관리하는 Apple Developer 등록 정보입니다.
구조를 단순화하면 다음과 같습니다.
Apple Developer Team
│
├── Certificate
│
├── App ID
│
└── Provisioning Profile
│
▼
Signed App처음부터 수동으로 인증서와 프로파일을 관리할 필요는 없습니다.
특별한 배포 요구사항이 없다면 Xcode의 자동 서명 기능을 사용하는 것이 편리합니다.
7. Xcode Automatically Manage Signing
Xcode에서 프로젝트를 열고 다음 메뉴로 이동합니다.
Project
→ Targets
→ Signing & Capabilities다음 항목을 확인합니다.
Automatically manage signing
Team
Bundle Identifier
Signing Certificate
Provisioning Profile
Automatically manage signing을 활성화하고 Apple Developer Team을 선택합니다.
Xcode가 필요한 서명 설정을 자동으로 관리할 수 있습니다.
다만 팀 권한, 계정 상태 또는 Capability 설정에 문제가 있다면 자동 서명이 실패할 수 있습니다.
8. SwiftUI 앱 버전 설정
App Store에 표시되는 앱 버전과 내부 빌드 번호는 구분해야 합니다.
예를 들어 다음과 같습니다.
Version: 1.0.0
Build: 1Xcode에서는 다음 위치에서 설정할 수 있습니다.
Project
→ Targets
→ General
→ Identity주요 항목은 다음과 같습니다.
| 항목 | 예시 | 의미 |
|---|---|---|
| Version | 1.0.0 | 사용자에게 표시되는 앱 버전 |
| Build | 1 | 업로드 빌드 구분 |
Android의 versionName, versionCode와 유사합니다.
동일한 버전으로 여러 빌드를 업로드할 때는 빌드 번호를 변경해야 합니다.
9. 앱 아이콘 준비
App Store에 출시하려면 앱 아이콘이 필요합니다.
Xcode의 Asset Catalog에서 앱 아이콘을 관리할 수 있습니다.
Assets.xcassets
→ AppIcon일반적으로 App Store용 1024×1024픽셀 아이콘을 준비합니다.
최신 Xcode의 Asset Catalog는 단일 크기 이미지에서 필요한 아이콘 표현을 관리할 수 있도록 지원합니다.
아이콘을 준비할 때는 다음 사항을 확인합니다.
정사각형 원본 이미지
충분한 해상도
앱의 실제 기능과 관련된 디자인
불필요한 작은 텍스트 최소화
투명도 및 색상 요구사항 확인
다른 앱과 혼동될 수 있는 디자인 회피
App Store용 아이콘은 플랫폼 요구사항에 맞춰 제작해야 합니다.
10. 앱 표시 이름 설정
앱 이름은 사용자가 홈 화면에서 보는 이름과 App Store에서 검색하는 이름을 구분해서 관리할 수 있습니다.
Xcode의 Display Name은 기기에 설치된 앱의 표시 이름에 영향을 줍니다.
App Store Connect의 Name은 스토어에 표시되는 앱 이름입니다.
두 값이 반드시 동일해야 하는 것은 아니지만 사용자에게 혼란을 주지 않도록 일관되게 관리하는 것이 좋습니다.
11. 앱 실행 화면과 Launch Screen
iOS 앱에서는 실행 시 시스템이 Launch Screen을 표시할 수 있습니다.
SwiftUI 앱에서는 별도의 Splash Activity를 만드는 Android 방식과 다르게 접근합니다.
Android에서는 SplashScreen API를 사용할 수 있습니다.
iOS에서는 Launch Screen을 앱의 초기 화면과 자연스럽게 연결하도록 구성하는 것이 좋습니다.
Launch Screen을 광고나 장시간 로딩 화면처럼 사용하는 것은 피해야 합니다.
12. App Store Connect에 앱 생성
이제 App Store Connect에서 앱을 생성합니다.
https://appstoreconnect.apple.com/
다음 메뉴로 이동합니다.
Apps
→ +
→ New App주요 입력 항목은 다음과 같습니다.
Platforms
Name
Primary Language
Bundle ID
SKU
User Access
Bundle ID는 Apple Developer에서 등록한 값과 일치해야 합니다.
SKU는 App Store Connect 내부에서 앱을 관리하기 위한 식별자입니다.
13. App Store 카테고리 선택
앱의 기능에 맞는 카테고리를 선택해야 합니다.
예를 들어 사진 콜라주 앱이라면 Photo & Video 카테고리를 고려할 수 있습니다.
달력 앱이라면 Productivity 또는 Lifestyle 등 실제 기능에 맞는 카테고리를 검토할 수 있습니다.
카테고리는 단순히 다운로드 수가 많아 보이는 분야를 선택하기보다 앱의 주요 목적과 일치하도록 설정하는 것이 좋습니다.
14. 앱 설명 작성
App Store Connect에서는 앱 설명을 작성해야 합니다.
사진 콜라주 앱을 예로 들면 다음과 같이 작성할 수 있습니다.
앱 설명 예시
사진을 자유롭게 배치하고 나만의 콜라주를 만들어 보세요.
여러 장의 사진을 선택해 이동, 확대, 축소, 회전할 수 있으며 텍스트를 추가해 개성 있는 이미지를 완성할 수 있습니다.
완성한 콜라주는 사진 앱에 저장할 수 있습니다.
주요 기능:
여러 장의 사진 선택
사진 이동 및 크기 조절
사진 회전
텍스트 추가
배경색 변경
콜라주 이미지 저장
실제 앱에 구현되지 않은 기능을 설명에 포함해서는 안 됩니다.
또한 앱 설명에 경쟁 서비스의 상표를 부적절하게 사용하는 것도 피해야 합니다.
15. App Store 키워드 작성
App Store Connect에서는 검색 키워드를 설정할 수 있습니다.
예를 들어 사진 콜라주 앱이라면 다음과 같은 키워드를 검토할 수 있습니다.
사진편집,콜라주,사진합치기,이미지편집,사진꾸미기키워드는 앱 기능과 직접 관련된 단어를 선택하는 것이 좋습니다.
앱 이름이나 부제목에 이미 포함된 단어를 불필요하게 반복하기보다 서로 다른 검색 의도를 고려해 구성할 수 있습니다.
16. 스크린샷 준비
App Store 등록 시 가장 중요한 자료 중 하나가 스크린샷입니다.
스크린샷은 사용자가 앱의 기능을 이해하는 데 직접적인 영향을 줍니다.
사진 콜라주 앱이라면 다음 화면을 고려할 수 있습니다.
메인 프로젝트 목록
사진 여러 장 선택
사진 편집 화면
텍스트 추가
완성된 콜라주
저장 결과
스크린샷은 앱의 실제 동작을 기반으로 제작해야 합니다.
과장된 기능이나 실제 제공하지 않는 화면을 표시해서는 안 됩니다.
17. 스크린샷 크기 확인
Apple은 기기 유형과 디스플레이 크기에 따라 스크린샷 규격을 관리합니다.
예를 들어 iPhone과 iPad는 필요한 스크린샷 세트가 다를 수 있습니다.
새로운 iPhone 기종이 출시되면 지원되는 스크린샷 크기도 변경될 수 있습니다.
따라서 특정 픽셀 크기만 외워서 제작하기보다 App Store Connect의 현재 업로드 요구사항을 확인하는 것이 안전합니다.
공식 참고 자료:
https://developer.apple.com/help/app-store-connect/reference/screenshot-specifications/
18. iPhone Simulator에서 스크린샷 촬영
Xcode Simulator를 실행한 뒤 앱 화면을 준비합니다.
Simulator 메뉴에서 스크린샷을 저장할 수 있습니다.
또는 터미널에서 다음 명령을 사용할 수 있습니다.
xcrun simctl io booted screenshot screenshot.png이 명령은 현재 부팅된 시뮬레이터의 화면을 PNG 파일로 저장합니다.
시뮬레이터가 여러 개 실행 중인 경우에는 대상 기기를 명시하는 것이 좋습니다.
19. Archive 생성 전 점검
앱을 업로드하기 전에 다음 항목을 확인합니다.
Bundle Identifier
Version
Build Number
Signing Team
Deployment Target
앱 아이콘
개인정보 권한 설명
테스트 광고 ID 제거
디버그 코드 제거
실제 서버 주소 설정
인앱결제 상품 ID
개인정보처리방침 URL
특히 AdMob을 사용하는 앱이라면 테스트 광고 단위 ID가 실제 광고 단위 ID로 변경되었는지 확인해야 합니다.
20. Xcode Archive 생성
Xcode에서 배포할 Scheme을 선택합니다.
일반적으로 iOS 앱을 Archive하려면 적절한 빌드 대상으로 설정해야 합니다.
이후 다음 메뉴를 선택합니다.
Product
→ Archive빌드가 성공하면 Xcode Organizer에 Archive가 표시됩니다.
Archive는 앱 배포를 위한 빌드 결과물입니다.
21. App Store Connect 업로드
Organizer에서 생성한 Archive를 선택합니다.
이후 배포 절차를 진행합니다.
Organizer
→ Archive 선택
→ Distribute App
→ App Store Connect
→ UploadXcode 버전에 따라 버튼 이름과 세부 화면 구성은 달라질 수 있습니다.
업로드 과정에서는 앱 서명과 배포 관련 검증이 수행됩니다.
업로드가 완료되면 App Store Connect에서 빌드 처리를 기다립니다.
22. 빌드 처리 상태 확인
앱을 업로드했다고 해서 즉시 App Store Connect에서 사용할 수 있는 것은 아닙니다.
Apple의 서버에서 빌드를 처리하는 시간이 필요합니다.
빌드 처리 중에는 다음과 같은 상태가 나타날 수 있습니다.
Processing
Ready to Test
Invalid Binary
기타 검증 관련 상태
처리 시간은 앱 크기와 Apple 시스템 상태 등에 따라 달라질 수 있습니다.
빌드 처리가 실패하면 App Store Connect의 오류 정보와 관련 안내를 확인해야 합니다.
23. TestFlight란?
TestFlight는 App Store에 정식 출시하기 전에 앱을 테스트할 수 있는 Apple의 배포 서비스입니다.
개발자는 테스트 사용자에게 앱을 배포하고 피드백을 받을 수 있습니다.
TestFlight 테스트는 크게 내부 테스트와 외부 테스트로 구분됩니다.
| 구분 | 내부 테스트 | 외부 테스트 |
|---|---|---|
| 대상 | App Store Connect 팀 사용자 | 초대된 외부 사용자 |
| 사용자 수 | 최대 100명 | 최대 10,000명 |
| 베타 심사 | 일반적으로 별도 베타 심사 불필요 | 첫 외부 테스트 빌드 등 심사 필요 |
| 목적 | 개발팀 검증 | 실제 사용자 환경 검증 |
TestFlight 빌드는 일반적으로 90일 동안 테스트할 수 있습니다.
24. 내부 테스트 설정
App Store Connect에서 다음 메뉴로 이동합니다.
Apps
→ 앱 선택
→ TestFlight
→ Internal Testing테스트 그룹을 생성하고 테스터를 추가합니다.
테스터는 TestFlight 앱을 통해 테스트 빌드를 설치할 수 있습니다.
내부 테스트는 개발팀이 빠르게 기능을 검증하는 데 적합합니다.
25. 외부 테스트 설정
외부 테스트는 일반 사용자에게 앱을 배포하기 전에 실제 사용 환경을 확인하는 데 도움이 됩니다.
외부 테스트를 위해서는 테스트 그룹과 테스터를 구성해야 합니다.
Apple의 베타 앱 심사 절차가 적용될 수 있습니다.
특히 처음 외부 테스트를 진행할 때는 앱의 주요 기능과 테스트 정보를 충분히 제공해야 합니다.
26. TestFlight에서 확인할 사항
사진 콜라주 앱을 기준으로 다음 항목을 확인할 수 있습니다.
사진 선택 권한
카메라 권한
사진 편집 기능
이미지 저장
앱 재실행 후 프로젝트 복원
AdMob 광고 표시
ATT 동의 화면
인앱결제 테스트
구매 복원
네트워크 오류 처리
앱 충돌
메모리 사용량
Simulator에서는 정상 동작하지만 실제 iPhone에서는 문제가 발생하는 경우가 있습니다.
따라서 최소한 한 대 이상의 실제 기기에서 테스트하는 것이 좋습니다.
27. 개인정보 권한 설명 점검
iOS 앱에서 카메라, 사진 라이브러리, 위치 등에 접근하는 경우 필요한 권한 설명을 설정해야 합니다.
예를 들어 다음과 같습니다.
<key>NSCameraUsageDescription</key>
<string>사진을 촬영하여 콜라주에 추가하기 위해 카메라를 사용합니다.</string>
<key>NSPhotoLibraryAddUsageDescription</key>
<string>완성한 콜라주를 사진 앱에 저장하기 위해 사용합니다.</string>사용하지 않는 권한을 불필요하게 요청하지 않는 것이 좋습니다.
또한 권한 설명은 실제 앱 기능과 일치해야 합니다.
28. App Privacy 작성
App Store Connect에서는 앱의 개인정보 처리 방식을 공개해야 합니다.
특히 다음 SDK를 사용하는 앱이라면 관련 데이터 처리를 확인해야 합니다.
Google AdMob
Firebase Analytics
Crashlytics
기타 광고 및 분석 SDK
개인정보 공개 항목은 앱에서 직접 수집하는 정보뿐 아니라 포함된 제3자 SDK의 데이터 처리 방식도 고려해야 합니다.
광고 SDK를 설치했다는 이유만으로 모든 개인정보 항목을 일괄 선택하는 것도 적절하지 않습니다.
실제 SDK 구성과 데이터 처리 방식을 기준으로 작성해야 합니다.
29. 개인정보처리방침 URL
개인정보처리방침 URL은 앱이 실제로 처리하는 개인정보에 맞게 준비해야 합니다.
예를 들어 다음과 같은 내용을 포함할 수 있습니다.
앱에서 수집하는 데이터
데이터 사용 목적
광고 SDK 사용 여부
분석 SDK 사용 여부
데이터 보관 및 삭제 정책
제3자 서비스 제공자
사용자 문의 방법
앱에 개인정보처리방침 링크가 필요한 경우 App Store Connect와 앱 내부 설정 화면에 연결할 수 있습니다.
개인정보처리방침 페이지는 사용자가 접근할 수 있도록 정상적인 HTTPS 주소로 제공하는 것이 좋습니다.
30. App Review Information 입력
앱 심사에서는 심사자가 앱의 기능을 이해할 수 있도록 필요한 정보를 제공해야 합니다.
App Store Connect의 App Review Information에서 다음 사항을 설정할 수 있습니다.
연락처 정보
로그인 계정
특수한 기능의 접근 방법
심사 참고 메모
추가 설명
로그인이 필요한 앱이라면 심사자가 사용할 수 있는 계정을 제공해야 할 수 있습니다.
로그인이 없는 앱이라면 로그인 기능이 없다는 점을 설명할 수 있습니다.
31. 심사 메모 작성 예시
사진 콜라주 앱을 예로 들어 보겠습니다.
This app allows users to create photo collages.
Main features:
- Select multiple photos
- Move, resize, and rotate photos
- Add text
- Save completed collages to the photo library
No account or login is required.
The app uses Google AdMob to display advertisements.
Optional in-app purchases are available
to remove ads and unlock premium features.
All core features can be accessed
without creating an account.실제 심사 메모에는 앱에 구현된 기능만 작성해야 합니다.
특히 인앱결제, 로그인, 외부 서비스, 하드웨어 연결 등 심사자가 쉽게 확인하기 어려운 기능은 구체적인 접근 방법을 설명하는 것이 좋습니다.
32. Guideline 2.1 — Information Needed
Apple 심사에서 자주 접할 수 있는 메시지 중 하나가 Guideline 2.1 관련 추가 정보 요청입니다.
이 메시지는 앱 심사를 완료하기 위해 추가 정보가 필요하다는 의미일 수 있습니다.
예를 들어 다음 사항을 요청할 수 있습니다.
앱의 주요 기능 설명
로그인 방법
외부 서비스 사용 여부
결제 방식
특정 기능의 접근 방법
실제 기기 테스트 정보
이 경우 무조건 새로운 빌드를 업로드해야 하는 것은 아닙니다.
Apple이 요청한 정보가 무엇인지 확인하고 App Store Connect에서 답변하면 되는 경우도 있습니다.
33. 심사 거절과 추가 정보 요청의 차이
심사 결과를 구분해서 대응하는 것이 중요합니다.
Metadata Rejected
앱 설명, 스크린샷, 메타데이터 등에 문제가 있는 경우입니다.
Binary Rejected
앱 기능, 동작, 정책 준수 등에 문제가 있어 새로운 빌드가 필요할 수 있습니다.
Information Needed
심사를 완료하기 위한 추가 설명이나 자료가 필요한 경우입니다.
실제 조치 방법은 App Store Connect의 구체적인 메시지를 기준으로 판단해야 합니다.
34. 앱 심사 대응 방법
심사 관련 메시지를 받았다면 다음 순서로 확인하는 것이 좋습니다.
적용된 Guideline 번호 확인
Apple이 지적한 구체적인 문제 확인
실제 앱에서 재현되는지 테스트
수정이 필요한 문제인지 판단
설명으로 해결할 수 있는지 확인
필요한 경우 새로운 빌드 제출
변경사항과 재현 방법을 명확하게 안내
심사 담당자에게는 감정적인 표현보다 객관적인 설명과 구체적인 테스트 방법을 제공하는 것이 좋습니다.
35. 인앱결제 앱 심사 주의사항
StoreKit 2를 사용하는 앱이라면 다음 항목을 점검해야 합니다.
실제 상품이 App Store Connect에 등록되어 있는가?
상품 ID가 코드와 일치하는가?
구매 화면에서 가격이 정상 표시되는가?
구독 기간과 자동 갱신 조건이 명확한가?
구매 복원 기능이 있는가?
이용약관과 개인정보처리방침이 제공되는가?
구매하지 않아도 무료 기능이 정상 동작하는가?
심사자가 유료 기능을 확인할 수 있는가?
특히 구독 상품은 제공하는 혜택과 결제 조건을 명확하게 설명해야 합니다.
36. 광고 포함 앱 심사 주의사항
AdMob 광고를 사용하는 앱이라면 다음 사항을 확인합니다.
실제 광고 단위 ID 사용
광고 SDK 정상 초기화
ATT 적용 필요 여부 검토
UMP 동의 처리
광고가 주요 기능을 가리지 않는지 확인
광고 클릭을 유도하는 UI가 없는지 확인
개인정보처리방침 반영
App Privacy 작성
광고가 앱의 핵심 기능을 방해하거나 사용자가 의도하지 않은 광고 클릭을 유발하지 않도록 설계해야 합니다.
37. 앱 심사 제출
앱 정보와 빌드 준비가 완료되면 App Store Connect에서 심사를 제출할 수 있습니다.
일반적인 흐름은 다음과 같습니다.
App Store Connect
│
▼
앱 버전 생성
│
▼
빌드 선택
│
▼
스크린샷 및 설명 입력
│
▼
개인정보 및 심사 정보 확인
│
▼
Add for Review
│
▼
Submit for Review실제 화면 구성과 버튼 이름은 App Store Connect의 업데이트에 따라 달라질 수 있습니다.
38. 앱 출시 방식 선택
Apple은 심사 승인 이후 앱을 출시하는 방법을 선택할 수 있도록 지원합니다.
대표적으로 다음 방식이 있습니다.
승인 후 자동 출시
개발자가 직접 출시
특정 날짜 이후 자동 출시
처음 앱을 출시한다면 심사 승인 후 직접 출시하는 방식을 고려할 수 있습니다.
이렇게 하면 앱 소개 페이지, 서버, 개인정보처리방침, 광고 설정 등을 마지막으로 점검한 뒤 공개할 수 있습니다.
39. 앱 업데이트 배포
앱을 출시한 뒤 새로운 기능을 추가하거나 버그를 수정하면 업데이트를 제출해야 합니다.
예를 들어 다음과 같이 버전을 변경할 수 있습니다.
기존 버전
Version 1.0.0
Build 1
업데이트
Version 1.1.0
Build 1새로운 App Store 버전을 생성하고 새로운 빌드를 업로드합니다.
동일한 마케팅 버전에서 빌드를 다시 업로드한다면 기존 빌드와 구분되는 빌드 번호가 필요합니다.
40. What's New 작성
앱 업데이트 시 변경사항을 작성할 수 있습니다.
예를 들어 다음과 같습니다.
이번 업데이트 내용
- 사진 콜라주 편집 기능 개선
- 텍스트 스티커 추가
- 프로젝트 자동 저장 안정성 개선
- 일부 기기에서 발생하던 오류 수정
- 전반적인 성능 개선실제 변경한 기능을 중심으로 작성하는 것이 좋습니다.
매번 단순히 '버그 수정 및 성능 개선'이라고 작성하기보다 사용자에게 영향을 주는 변경사항을 구체적으로 안내하면 좋습니다.
41. 출시 후 확인할 사항
App Store에 앱을 출시했다고 해서 모든 작업이 끝나는 것은 아닙니다.
다음 항목을 지속적으로 확인해야 합니다.
앱 충돌
사용자 리뷰
다운로드 및 설치 추이
인앱결제 정상 동작
광고 요청 및 노출 상태
서버 오류
개인정보처리방침 접근
iOS 업데이트 호환성
새로운 App Store 정책
특히 새로운 iOS 버전이 출시될 때는 주요 기능을 실제 기기에서 테스트하는 것이 좋습니다.
42. 실전 배포 체크리스트
Apple Developer Program 활성화
Bundle Identifier 등록
Xcode Signing 설정
Version 및 Build 설정
앱 아이콘 준비
App Store Connect 앱 생성
앱 카테고리 선택
앱 이름 및 설명 작성
키워드 설정
스크린샷 준비
개인정보 권한 설명
개인정보처리방침 URL
App Privacy 작성
인앱결제 상품 점검
AdMob 광고 설정 점검
Archive 생성
App Store Connect 업로드
빌드 처리 완료 확인
TestFlight 내부 테스트
TestFlight 외부 테스트
실제 iPhone 기능 테스트
App Review Information 작성
앱 심사 제출
심사 결과 확인
앱 출시
출시 후 오류 및 리뷰 확인
43. 마무리
SwiftUI로 개발한 앱을 App Store에 출시하려면 단순히 Xcode에서 빌드하는 것 이상의 준비가 필요합니다.
Apple Developer 계정, Bundle Identifier, Signing, App Store Connect, TestFlight, 개인정보 설정, 앱 심사까지 전체 과정을 이해해야 합니다.
이번 글의 핵심을 정리하면 다음과 같습니다.
App Store 배포에는 Apple Developer Program이 필요합니다.
Bundle Identifier는 앱을 구분하는 중요한 식별자입니다.
Xcode의 Automatically Manage Signing으로 서명 설정을 간소화할 수 있습니다.
앱 버전과 빌드 번호는 구분해서 관리해야 합니다.
App Store Connect에서 앱 정보와 메타데이터를 등록합니다.
Archive를 생성해 배포용 빌드를 업로드할 수 있습니다.
TestFlight로 실제 기기에서 사전 테스트할 수 있습니다.
개인정보 공개 항목은 앱과 SDK의 실제 데이터 처리 방식에 맞춰 작성해야 합니다.
App Review에서 추가 정보를 요청하면 구체적으로 답변해야 합니다.
출시 이후에도 앱 오류, 사용자 피드백, 정책 변경을 지속적으로 관리해야 합니다.
Android에서 Google Play Console을 사용해 본 개발자라면 App Store Connect의 전체 구조도 충분히 익힐 수 있습니다.
다만 Apple은 앱 서명과 개인정보 보호, 심사 정보에 대해 별도의 요구사항을 적용하므로 iOS에 맞는 배포 체크리스트를 준비하는 것이 좋습니다.
앱 개발의 마지막 단계는 코드를 완성하는 것이 아니라 사용자가 안정적으로 설치하고 사용할 수 있도록 배포와 심사를 준비하는 것입니다.
공식 참고 자료
Apple Developer Program
https://developer.apple.com/programs/App Store Connect
https://appstoreconnect.apple.com/App Store Connect Help
https://developer.apple.com/help/app-store-connect/Certificates, Identifiers & Profiles
https://developer.apple.com/help/account/App Store 배포
https://developer.apple.com/distribute/TestFlight
https://developer.apple.com/testflight/App Review Guidelines
https://developer.apple.com/app-store/review/guidelines/App Privacy
https://developer.apple.com/app-store/app-privacy-details/App Store 스크린샷 규격
https://developer.apple.com/help/app-store-connect/reference/screenshot-specifications/
태그: iOS, Swift, SwiftUI, Xcode, App Store, App Store Connect, Apple Developer, Bundle Identifier, Signing, Provisioning Profile, Archive, TestFlight, App Review, 앱 심사, iOS 앱 배포