MapKit (25)
Deploy CloudKit
사이트 들어가서 이걸 누르면 된다.
CloudKit 환경 비교: Development vs Production
그리고 CloudKit에는
Development와 Production으로 나뉘어 지는데,
표로 간단하게 정리를 하면
| 구분 | Development (개발 환경) | Production (배포 환경) |
|---|---|---|
| 목적 | 앱 개발, 기능 테스트 및 디버깅 | 실제 앱스토어 출시 및 일반 유저 서비스 |
| 데이터 스키마 | 자유롭게 생성, 수정, 삭제 가능 (Just-in-Time) | 스키마 고정 (Development에서 배포 후 변경 불가능) |
| 데이터 독립성 | 개발 환경의 데이터만 접근 가능 | 실제 유저들의 리얼 데이터만 접근 가능 |
| 사용자 제한 | 개발자 계정 및 등록된 테스트 계정 중심 | 앱을 다운로드한 모든 일반 사용자 |
| 서버 초기화 | 언제든 대시보드에서 데이터를 초기화 가능 | 데이터 삭제 및 초기화가 불가능하거나 매우 까다로움 |
| 연동 앱 상태 | 시뮬레이터 구동, TestFlight(내부 테스트) | App Store 배포 버전, TestFlight(외부 테스트) |
💡 핵심 포인트
- 초기 배포의 필수성 (Deploy): 처음에는 Production 환경에 우리가 정의한 레코드 타입(예:
DDGProfile,DDGLocation)의 구조가 전혀 존재하지 않는다. 따라서 TestFlight나 상용 버전에서 앱이 정상 작동하도록 테스트하려면, 반드시 CloudKit 대시보드에서 Development의 스키마를 Production으로 최소 한 번 이상 Deploy해 주어야 한다. - 일방통행 배포:
Development에서 완성된 데이터 구조(스키마)를Production으로 ‘배포(Deploy)’하는 방식이다. 반대로 배포용 환경의 구조를 개발 환경으로 되돌릴 수는 없다. - 데이터 격리: 두 환경은 이름표만 다른 게 아니라 서버 자체가 완전히 격리되어 있다. 따라서 개발 중에 배포용 데이터를 건드리거나, 반대로 유저 데이터가 개발 환경에 섞일 염려가 없다.
이렇게 사진을 보면 우리가 시뮬레이터에서 작동확인을 위해 만들었던 Profile들이 Production에서는 아무런 데이터가 없음을 알 수 있다.
실기기 확인을 위해 Mock Data를 넣어보도록 한다. (넣는 방법은 이전에 한것과 동일하므로 생략)
그리고 시뮬레이터에서 Production 을 테스트 하는 방법은
이렇게 해주면 된다.
1
com.apple.developer.icloud-container-environment
근데 한가지, 시뮬레이터에서 로그인 세션이 만료되어서 다시 비밀번호를 입력하라고 할때, 입력을 하지않고 실행을 했더니 CloudKit 자체에 앱이 접근을 하지 못했다.
혹시나해서 다시 로그인을 하니 문제없이 작동확인이 되었는데, 이유는 잘 모르겠다.
물론 저기서 production이 아닌 development로 바꾸게 되면 우리가 이전에 테스트하던 그 CloudKit DB를 확인 가능하다.
LocationDetailView
1
2
3
4
VStack(spacing: 16) {
// 생략
Spacer()
}
사진으로 알 수 있듯, 아무도 체크인 안했을때 가운데 정렬? 처럼 View가 보이기에 Spacer를 추가해주었다.
Github: Dub-Dub-Grub Repository
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.