iCloud Design Guide  챕터 번역입니다.

공식 도큐멘트 원본:  iCloud Fundamentals (Key-Value and Document Storage)

 

 

사용자의 관점에서, iCloud는 그들의 개인적인 콘텐트를 자신의 모든 기기에서 자동으로 사용가능하도록 해주는 간단한 기능이다. 당신의 앱이 이런 “마법”에 가담하도록 하려면 다른 경우와는 조금 다르게 앱을 디자인하고 구현해야한다. 특히, iCloud를 채택할  때 당신앱의 역할에 관해 생각해볼 필요가 있다.

이런 역할과 iCloud 채택 프로세스의 상세 특성은 앱에 따라 다르다. 앱의 데이터를 어떻게 관리할지 당신이 디자인한다. 그렇기에 어느 iCloud 지원 기술이 당신 앱에 필요한지, 또 어느 것은 필요없는지 당신만이 결정할 수 있다. 이번 챕터는 모든 개발자가 알아야할 iCloud key-value 와 document 스토리지의 기본요소를 설명해준다.

 

첫째로 개발 기기를  프로비저닝한다

iCloud 앱 개발을 시작하려면 당신은 반드시 App Distribution Quick Start에 설명된 것처럼 App ID 와 provisioning profile(프로비저닝 프로파일)을 생성해야한다. 그런다음  App Distribution Guide의 Adding iCloud Support에 설명된 것처럼 당신이 사용하고 싶은 iCloud 서비스를 활성화한다. 

 

아이클라우드 데이터 전송은 자동으로, 안전하게 진행된다

대부분의 iCloud서비스의 경우 당신의 앱은 iCloud 서버와 직접적으로 소통하지 않는다. 그대신, OS가 iCloud 계정에 연결된 장치에 대한 데이터를 초기화하고 업로드와 다운로드를 관리한다. 모든 iCloud 서비스에서 이런 것을 사용하기위한 고차원 프로세스는 다음과 같다:

1. 당신앱의 iCloud 컨테이너로의접속을설정한다. 설정에는그것을사용하기전에 entitlements(자격) 를요청하고 그런 컨테이너를 프로그래밍 적으로 초기화하는 것이 포함된다.
2. 사용자가 iCloud 로그아웃할 때 처럼 아이클라우드의 가용성안에서의 변경사항에대해, 그리고 다른기기에있는당신앱의 인스턴스가 파일을다시이름짓고, 이동하고, 복사하거나 삭제 할 수 있으므로 파일의 위치변경에대해 적절하게 대응 할 수 있도록 당신앱을 디자인한다.
3.  당신이 사용중인 기술의 API 사용에대해 읽고 코드를 작성한다.
4.  필요에따라 OS가 iCloud와의데이터전송을 조정한다.

 

아이클라우드 서비스는 전송에 앞서 데이터를 암호화하고 iCloud 서버는 인증을 위한 안전한 토큰을 사용해서 해당 데이터를 암호화된 포맷 그대로 저장한다. iCloud에 관련해서 데이터 안전성과 개인정보 취급에 대한 상세정보는  iCloud 보안 및 개인 정보 보호 개요를 읽어볼 것.

 

iCloud 컨테이너, 스토리지, 인타이틀먼트

iCloud에 데이터를 저장하려면, 당신의 앱은 iCloud 컨테이너라는 특별한 파일 시스템 위치에 데이터를 저장해야한다. iCloud 컨테이너(또한 ubiquity container라고도 함)는 아이클라우드 스토리지에 대응되는 로컬 개념이다.  이 것은  Figure 1-1 나온 것처럼 당신앱의 다른 앱데이터와는 분리되어있다.

iCloud 컨테이너로의 접속을 활성화하려면 당신은 해당 컨테이너에 대한 적절한 인타이틀먼트(entitlements:자격)을 요청해야한다.

 

Xcode의 Capabilities를 사용해서 iCloud로의 접근을 요청하기

Xcode project의 Capabilities 항목은 당신앱이 iCloud에 접근하기위해 필요한 인타이틀먼트 파일과 컨테이너 생성을 관리한다. iCloud capability를 활성화 한 뒤,  .entitlements 파일이 존재하지 않는 다면 Xcode이 그것을 생성, 그리고 당신이 선택한 서비스에대한 인타틀먼트와 함께 그것을 설정한다. 필요에 따라서 Xcode는 앱의 연결된 컨테이너 생성같은 추가적인 설정을 다룰 수 있다.

 

iCloud Documents를 활성화하면 Xcode는 당신앱이 iCloud 컨테이너에 접근하도록 설정해주는데 이 컨테이너는 앱의 번들ID에 기반해서 이름지어진다. 만일 당신앱이 데이터를 서로 공유한다면, Specifying Custom Containers에 설명된 것처럼 프로젝트 타겟(targets)이 컨테이너를 공유하도록 설정하라. 앱이 여러 컨테이너 ID에대한 접근을 가진다면 접근리스트의 첫번째 ID는 특별한데, 이것은 해당앱의 주 컨테이너이기 때문이다. 또한 OS X에서 이것의 내용물은 NSDocument 열기, 저장 대화상자에 표시된다

중요:  컨테이너 식별자 문자열 (identifier strings)은 와일드카드 문자(*)를 포함해선 안된다.

당신앱을 위한 올바른 iCloud 기술을 어떻게 선택해야할지에 대한 정보는 아래쪽의 적절한 iCloud 스토리지 API를 선택하기 를 볼 것.

 

여러 앱을 위한 공통 아이클라우드 컨테이너 설정하기

Xcode target editor의 Summary 항목에서, 당신앱에 필요한 만큼 아이클라우드 컨테이너들에 대한 접근을 요청할 수 있다.  이 기능은 여러앱에서 문서를 공유하길 원할 때 유용하다. 예를 들어, 당신이 무료버전과 유료버전의 앱을 제공한다면 사용자가 무료버전에서 유료버전으로 업그레이드할 때 iCloud 문서에 대한 액세스 권한을 유지하게할 수 있다. 그런 시나리오에서, 두 앱 모두 같은 컨테이너에 데이터를 작성하도록 설정하라.

 

공통 컨테이너 설정하기

1. iCloud가활성화된앱들중하나를 프라이머리앱(주사용앱)으로지정한다. 이앱의 iCloud 컨테이너가공통컨테이너가된다.
   예를 들어 유료,무료앱의 경우, 당신은 유료앱을 프라이머리 앱으로서 지정할 것이다.
2. 각앱에 대해 iCloud capability를 활성화한다.
3. 프라이머리 앱을 오직 default  container identifier로만설정한다.
4. 다른 세컨더리앱의경우, “Specify custom container identifiers” 옵션을활성화하고프라이머리앱의 container identifier를컨테이너리스트에추가한다.

 

프라이머리와 세컨더리앱 양쪽에서 파일을 읽고 쓸 때, 공통 스토리지 컨테이너에서만 파일에대한 URLs을 만들고 검색한다. 공통 스토리지 컨테이너에 대한 URL을 가져오려면 프라이머리앱의  container identifier(컨테이너 식별자)를 NSFileManager의 URLForUbiquityContainerIdentifier: 메써드에 전달한다. 이 메써드에 nil을 전달하지 말 것. nil을 전달하면 앱의 디폴트 컨테이너를 반환하기 때문인데 디폴트 컨테이너는 각각의 앱이 서로 다르다. 명시적으로 컨테이너 식별자를 지정하면 언제나 올바른 컨테이너 디렉토리를 가져온다.

 

여러앱에 대한 공통된 Key-Value 스토리지 설정하기

당신앱의 무료, 유료 버전의 두앱을 제공하고 같은 key-value 스토리지를 사용하고 싶다면 그렇게 할 수 있다.

 

여러앱을 위한 공통 key-value 스토리를 설정하기

1. 아이클라우드를활성화할앱중하나를프라이머리앱으로지정한다.
   해당 앱의 컨테이너가 공통 컨테이너가 된다. 예를 들어 무료, 유료버전의 두앱의 경우 당신은 유료버전을 프라이머리 앱으로 지정할 것이다.
2. 각앱에대해 iCloud capability를활성화한다.
3. 두앱모두에서 key-value storage 옵션을활성화한다.
   Xcode는 자동으로 각 앱에 대한 인타이틀먼트를 추가하고 앱의 번들 아이디에 기반한 아이클라우드 컨테이너를 할당한다.
4. 프라이머리앱을제외하고모든앱에서앱의.entitlements 파일안의 iCloud container ID를수동으로변경한다.(역자 주: 그냥 Capability에서해주면된다.)
   com.apple.developer.ubiquity-kvstore-identifier 키의 값을 프라이머리 앱의 ID가 조합된 것으로 변경해준다. (역자 주: 이 key 이름은 .entitlements 파일을 소스 보기로 볼때의 이름이다. plist인 상태에서는 iCloud Key-value Store 라는 이름의 키이고 디폴트 값이  $(TeamIdentifierPrefix)$(CFBundleIdentifier) 로 되어있다. 이 값을 바꿔주면될것이다. )

 

아이클라우드 컨테이너는 최소한의 구조를 가진다.

새롭게 생성된 아이클라우드 컨테이너의 구조는 최소한인데 —오직 하나의 Documents 서브디렉토리가 있다. document 스토리지의 경우, 당신이 선택한 어떤 방법으로든 컨테이너 안에 파일을 정리 할 수  있다. Figure 1-2에 나온 것처럼 이것은 당신으로 하여금 커스텀 디렉토리와 커스텀파일을 추가하는등 앱에 필요한대로 구조를 정할 수 있게 해준다. 

 

Documents 서브디렉토리 안에 파일을 만들고 서브디렉토리를 생성할 수 있다. 당신이 생성한 디렉토리안에도 추가적인 서브디렉토리나 파일을 생성할 수 있다. file coordination을 사용하는 NSFileManager 오브젝트를 사용해서 그런 작업을 수행하라.  File System Programming Guide의 The Role of File Coordinators and Presenters를 참조할 것.

 

Documents 서브디렉토리는 iCloud 컨테이너의 얼굴이다. 사용자가 당신앱에 대한 아이클라우드 스토리지를 살펴볼 때 ( iOS의 설정앱이나 OS X의 환경설정을 사용해서 본다), Documents 서브디렉토리 안에 나열된 파일이나 파일 패키지는 개별적으로 삭제가능하다. Documents 서브디렉토리 밖의 파일들은 앱의 비공개 공간(private)으로 취급된다. 만일 사용자가 당신앱의 아이클라우드 컨테이너의 Documents 서브디렉토리 밖의 것을 지우길 원한다면 해당 디렉토리들의 밖에있는 모든 것을 삭제해야한다.

 

아이클라우드 스토리지의 사용자 시점을 보려면 다음 아래를 수행하면되는데 첫째로 아이클라우드가 활성화된 앱이 하나라도 있어야한다.

• iOS에서, 설정앱을연다. 그리고 iCloud > Storage & Backup > Manage Storage로이동
• OS X에서,시스템환경설정을연다. 그런다음 iCloud 설정항목을 열고 ‘관리’를클릭한다.

 

사용자의 아이클라우드 스토리지는 제한되어있다

각각의 iCloud 사용자는 무료의 저장공간 할당을 받고 필요한경우 더 큰용량을 구매할 수 있다. 이 공간은 사용자의 아이클라우드가 활성되 iOS & Mac 앱에 의해 공유되므로, 많은 앱을 가진 사용자는 저장공간을 다 쓰게된다. 이런 이유로 당신의 앱이 iCloud에 필요한 것만 저장하는 것이 중요하다. 구체적으로 말하자면:

•  iCloud에 저장해도 되는 것들:
  • 사용자 문서
  • 사용자가 생성한 데이터를 담고있는 앱에 한정된 파일
  • 환경설정과 앱 상태(key-value 스토리지사용- 사용자의 iCloud 스토리지 할당량에 불리하게 여겨지지 않는것들)
  • SQLite 데이터베이스변경사항로그파일 ( SQLite 데이터베이스의 저장파일은 iCloud에저장하면 안된다)
•  iCloud에 저장하지 말아야 할 것들:
  • 캐시파일
  • 임시파일
  • 앱이 생성하고 재생성 할 수 있는 App support 파일
  • 용량이 큰 다운로드된 데이터파일

 

사용자가 iCloud로부터 콘텐트를 삭제하길 원할 때가 있다. UI를 제공해서 사용자가 iCloud에서 문서를 삭제하면 사용자의 iCloud 계정과 아이클라우드가 활성화된 모든기기에서 삭제됨을 할게 해줄 것. 삭제를 승인하거나 취소할 수 있는 기회를 제공할 것.

파일과 디렉토리가 iCloud안에 저장되는 것을 방지하는 한가지 방법은 .nosync 확장자를 파일이나 디렉토리 이름에 추가하는 것이다. 로컬 컨테이너 디렉토리안에 해당 확장자가 붙은 파일과 디렉토리를 iCloud가 마주하면 그것을 서버로 전송하지 않는다. 당신은 이 확장자를 파일 패키지 안에 저장하길 원하지만 해당 패키지의 콘텐츠의 나머지 것과 함께 전송하길 원하지 않는 임시파일에 사용할 수 있을 것이다.  .nosync 확장자가 붙은 아이템들은 서버에 전송되지 않지만 여전히 부모디렉토리에 묶인다. iCloud안의 부모 디렉토리를 삭제하거나 해당 부모디렉토리와 그것의 콘텐츠를 로컬에서 제거시키면 .nosync 아이템을 포함하여 해당 디렉토리의 모든 콘텐츠가 삭제된다.

 

시스템이 로컬 iCloud 스토리지를 관리한다

iCloud 데이터는 애플의 iCloud 서버에 존재하게되지만 Figure 1-3에 나온것처럼 OS가 각 사용자의 기기에있는 각 데이터의 로컬캐시를 관리한다. iCloud 데이터의 로컬캐싱은 아이폰의 에어플레인 모드를 켰을 때처럼 네트워크가 끊겨있을 때도 사용자가 계속 작업할 수 있게 해준다.

 

iCloud 데이터 로컬 캐시는 기기 안의 다른 파일들과 함께 공간을 공유하기 때문에 몇몇의 경우 모든 아이클라우드 사용자데이터를 위한 로컬 저장소가 충분하지 않게된다. 시스템은 최적화된 파일 서브셋과 다른 데이터 객체를 로컬에서 관리함으로써 이런 문제들 다룬다. 동시에, 시스템은 파일과 관련된 모든 메타데이터를 로컬에 보관하고 그렇게 함으로써 앱사용자가 로컬이든 아니든 모든 파일에 접근할 수 있도록 해준다. 예를 들어, 사용자가 지금당장 사용하길 원하는 파일을 위한 로컬 공간이 필요할경우 시스템은 현재 사용중이지 않은 다른 파일을 iCloud 컨테이너에서 제거 시킬수도 있다; 반면 제거된 파일에대한 업데이트된 메타데이터는 로컬에 남긴다. 사용자는 여전히 제거된 파일의 이름과 몇몇 정보를 볼 수 있고, 만일 네트워크에 연결되면 다시 그것을 열 수 있다.

 

몇 몇의 경우 당신의 앱이 로컬 공간을 관리하는 것을 도울 수 있다

Document-based 앱은 보통 iCloud 파일의 로컬 가용성을  관리할 필요없고 파일의 제거여부를 시스템이 다루도록 나둬야야하는데 여기엔 두가지 예외가 있다:

• 만일 어떤 사용자파일이 현재로선 필요없고 한동안 필요없을 것으로 여겨질 때, 당신은 NSFileManager 의 메써드 evictUbiquitousItemAtURL:error:를 호출해서 명시적으로 해당파일 아이클라우드 컨테이너에서 제거시키도록 도울 수 있다.

참고: 이 메써드는 사용자의 요구를 염두에두고 신중하게 사용할 것. 파일이 제거되고 나면 시스템에서 파일을 다시 다운로드해야 사용할 수 있다.

• 반대로, 파일을 로컬에서 사용할 수 있도록 명시적으로 지정하려면 NSFileManager 의 메써드 startDownloadingUbiquitousItemAtURL:error:를 호출해서 iCloud 컨테이너로 다운로드를 시작할 수 있다. 이 프로세스에대한 자세한 내용은  ‘iCloud 문서 사용에 대한 앱의 책임‘을 참고할 것.

 

당신앱이 iCloud를 사용하도록 준비하기

iCloud가 지원되는 당신앱을 사용자가 처음으로 실행하면, iCloud를 사용하도록 권유할 것. ‘선택지는 모두 사용하든지 또는 사용하지 않든지’ 일 것이다. 특히, 다음을 수행하는 것이 좋다:

•  iCloud만, 또는 로컬공간만 사용할것; 다시 말해서 iCloud 컨테이너와 앱의 로컬 데이터 컨테이너간에 문서를 미러링 하지 말 것. • iCloud만, 또는 로컬공간만 사용할것; 다시 말해서 iCloud 컨테이너와 앱의 로컬 데이터 컨테이너간에 문서를 미러링 하지 말 것.
• 사용자가 앱을 삭제하고 재설치 하지 않는한 iCloud를 사용할지 로컬스토리지를 사용할지에 대해 묻는 메시지를 표시하지 말것.

 

(iOS에서는 application:didFinishLaunchingWithOptions: 메써드에서, OS X에서는 applicationDidFinishLaunching: 메써드에서 아래 예제 1-1에 나온 것처럼 앱 실행과정 초기에 NSFileManager의 ubiquityIdentityToken 프라퍼티 값을 가져와서 iCloud 사용 가용성을 확인할 것:

앱의 메인 쓰레드에서 이 프라퍼티를 접근하라. 이 프라퍼티의 값은 현재활성화된 iCloud 계정을 나타내는 고유 토큰이다. 아래의 ‘iCloud 가용성 변경에 대응하기‘에서 설명한 것처럼 현재 계정이 이전 것과 다른지를 토큰을 비교하여 확인할 수 있다. 비교를 가능하게하려면 예제 1-2와 같은 코드를 사용해서 새로 가져온 토큰을 user defaults 데이터베이스에 보관할 것. 이 코드는 ubiquityIdentityToken 프라퍼티가 NSCoding 프로토콜을 따른다는 사실의 장점을 이용한다.

 

사용자가 기기의 비행기 모드를 사용한다면 iCloud 자체는 접근할 수 없지만 현재 계정은 로그인 상태로 유지된다. 비행기 모드에서도 ubiquityIdentityToken 프라퍼티는 현재 iCloud 계정의 토큰을 담고 있다.

 

사용자가 설정앱에서 Documents & Data 를 끄는 등 iCloud에서 로그아웃하면 ubiquityIdentityToken 프라퍼티 값은 nil이 된다. 사용자의 iCloud 로그인, 로그아웃을 감지하려면 예제 1-3에 나온 코드같은 예처럼 NSUbiquityIdentityDidChangeNotification 알림 옵저버로서 등록하면된다. 론칭 시간에 또는 iCloud를 사용하기에 앞서 이코드를 실행하라.

iCloud 토큰을 가져 와서 보관하고 iCloud 노티피케이션을 등록하면 당신의 앱은 사용자에게 iCloud 사용을 권유 할 준비가된다. 사용자가 iCloud 계정을 사용할 수있는 상태에서 앱을 처음 실행하는 경우 예제 1-4와 같은 코드를 사용하여 메시지를 표시하라. 사용자의 선택사항을 user defaults 데이터베이스에 저장하고 이 값을 사용해서 firstLaunchWithiCloudAvailable 변수를 초기화 하라. 아래의예제는 언어사용을 단순화한 코드이다. 실제 릴리즈에서는 문자열을 그대로 사용하기보다는 NSLocalizedString (또는 유사한) 매크로를 사용하여 문자를 현지화(로컬라이징)해야 할 것이다.

 

ubiquityIdentityToken 프라퍼티는 사용자가 iCloud 계정에 로그인했는지 여부를 알려주긴하지만 iCloud를 앱에서 사용할 수 있도록 준비해주지는 않는다. iOS에서, document 저장공간을 사용하는 앱은 지원되는 각 iCloud 컨테이너에 대해 반드시 NSFileManager의 URLForUbiquityContainerIdentifier: 메써드를 호출해야한다. URLForUbiquityContainerIdentifier: 메써드는 언제나 앱의 메인 쓰레드가 아닌 백그라운드 쓰레드에서 호출할 것. 이 메써드는 로컬과 원격서비스에 따라 다르고, 이런 이유로 항상 즉시 반환하진 않는다.  예제 1-5는 당신의 default 컨테이너를 백그라운드 쓰레드에서 초기화하는 방법의 예를 보여준다.

위 코드는 당신이 이코드를 실행하기에 앞서 myContainer를 NSURL 타입의 인스턴스 변수로 정의했다고 가정한다.

 

iCloud 가용성 변경에 대응하기

사용자가 Documents & Data 기능을 사용 중지하거나 iCloud에서 로그 아웃하는 경우와 같이 iCloud를 앱에서 사용할 수없는 경우가 있다. 앱이 실행 중인 동안 또는 백그라운드 상태인 동안 현재 iCloud 계정을 사용할 수 없게되면 당신의 앱은 반드시 사용자 별 iCloud 파일 및 데이터에 대한 참조를 삭제해야하고 Figure 1-4에서와 같이 해당 데이터를 표시하는 사용자 인터페이스 요소를 리셋하거나 새로 고침해야한다.

 

iCloud 가용성의 변경 사항을 처리하려면 NSUbiquityIdentityDidChangeNotification 노티피케이션을 수신하도록 등록한다. 등록한 핸들러 메소드는 반드시 다음을 수행해야한다:

1. ubiquityIdentityToken 프파퍼티에서 새 값을 가져온다.
2. 새 값을 이전 값과 비교하여 사용자가 계정에서 로그 아웃했거나 다른 계정으로 로그인했는지 확인한다.
3. 값이 다른 경우 이전에 사용한 계정을 사용할 수 없다. 모든 변경 사항을 무시하고 iCloud와 관련된 데이터 캐시를 비우고 모든 iCloud와 관련된 사용자 인터페이스를 새로 고친다. 사용자가 iCloud를 사용할 수없는 상태에서 계속 콘텐츠를 만들 수있게하려면 해당 내용을 앱의 로컬 데이터 컨테이너에 저장한다. 계정을 다시 사용할 수있게되면 새 콘텐츠를 iCloud로 이동시킨다. 이는 일반적으로 사용자에게 알리거나 사용자와의 상호 작용없이 작업을 수행하는 것이 좋다.

 

적절한 iCloud 스토리지 API를 선택하기

Apple은 다음과 같은 다양한 목적의 iCloud 스토리지 API를 제공한다.

• Key-value storage는 환경 설정, 설정 및 간단한 앱의 상태와 같은 개별 값을 나타낸다. 소량의 데이터 (주식 또는 날씨 정보, 위치, 책갈피, 최근 문서 목록,설정 및 환경 설정, 그리고 간단한 게임 상태 등)에 iCloud key-value storage를 사용한다. App Store 또는 Mac App Store에 제출 된 모든 앱은  key-value storage의 장점을 이용해야할 것이다.
• iCloud document storage는 사용자가 볼 수있는 파일기반의 콘텐츠, 코어 데이터 저장소 또는 기타 복잡한 파일 기반의 콘텐츠를 위한 것이다. 서류작업 문서, 다이어그램, 그림 또는 복잡한 게임 상태를 추적해야하는 게임같은 파일 기반 콘텐츠로 작업하는 앱은 iCloud document storage를 사용하면 된다.
• CloudKit storage는 모든 앱 사용자가 액세스 할 수있는 비공개(private) 또는 공개(public) 데이터베이스에 개별 레코드(record)로서 데이터를 저장하기위한 것이다. key-value storage 과 document storage으로는 당신의 필요를 충족하지 못하는 상황에서 CloudKit을 사용하면된다. CloudKit에 대한 자세한 내용은  Designing for CloudKit을 참조.

 

많은경우 앱은 key-value storage를 다른 유형의 저장 공간과 함께사용하면 도움된다. 예를 들어 사용자가 작업을 구성하기 위해 키워드를 적용 할 수있는 작업 관리용 앱을 개발한다고 가정 해 보자. iCloud document storage를 사용하여 작업 정보를 저장하고 key-value storage를 사용하여 사용자가 입력 한 키워드를 저장할 수 있을 것이다.

 

만일 당신의 앱이 문서 또는 iPhoto와 같은 슈박스형(shoebox-style) 앱을 위한 Core Data를 사용하는 경우 iCloud document storage를 사용하라. 당신의 코어 데이터 앱에서 iCloud를 채택하는 방법을 배우려면 Designing for Core Data in iCloud를 참조할 것.

 

앱에 비밀번호를 저장해야하는 경우 iCloud 스토리지 API를 사용하지 말 것. 암호 저장 및 관리를위한 올바른 API는 Keychain Services Reference에 설명 된것처럼 Keychain Services이다.

표 1-1을 사용하여 각 앱의 요구에 맞는 iCloud 스토리지 구성표를 선택할 수 있다.

표 1-1

	iCloud document storage	Key-value storage	CloudKit
목적	사용자 문서, 복잡한 비공개 앱데이터, 앱 또는 사용자가 생성하는 복잡한 데이터를 포함하는 파일	간단한 데이터 유형을 사용하여 표현할 수있는 환경 설정 및 구성 데이터.	복잡한 비공개 앱 데이터 및 파일, 구조화 된 데이터, 사용자 생성 데이터, 사용자간에 공유하려는 데이터
Entitlement 키	com.apple.developer.icloud-services, com.apple.developer.icloud-container-identifiers	com.apple.developer.ubiquity-kvstore-identifier	com.apple.developer.icloud-services, com.apple.developer.icloud-container-identifiers
데이터 포맷	파일과 파일 패키지	숫자, 문자열, 날짜같은 프라퍼티 리스트(plist) 데이터 타입 만 허용	값이 프라퍼티 리스트(plist) 타입의 하위 집합체인 key-value 쌍 모음으로 나타낼 수 있는 레코드(records), 파일, 또는 다른 레코드로의 참조
용량 제한	사용자의 iCloud 계정에 할당된 용량으로 제한됨	앱당 1MB, key당 최대 1MB	비공개(private) 데이터베이스의 경우 사용자의 iCloud 계정에 할당된 용량, 공개(public) 데이터베이스의 경우 앱에 할당된 클라우드킷 storage quota 만큼
가용성 확인	당신의 유비쿼터스 컨테이너 중 하나에 대해 URLForUbiquityContainerIdentifier : 메소드를 호출할 것. 이 메서드가 nil을 반환하면 문서 저장을 사용할 수 없는 상태이다.	Key-value storage의 가용성은 항상 유효함. 기기가 계정에 연결되어 있지 않은 경우 기기에서의 변경 사항은 계정에 연결 되자마자 iCloud로 푸시 됨	공개 데이터베이스는 항상 사용가능. 비공개 데이터베이스는 ubiquityIdentityToken 프라퍼티의 값이 nil이 아니라면 사용 가능 한 것.
데이터 찾기	NSMetadataQuery 객체를 사용해서 사용 가능한 iCloud 파일에 대한 실시간 업데이트 정보를 얻을 것.	공유된 NSUbiquitousKeyValueStore 객체를 사용하여 값을 검색할 것	CKQueryOperation과 함께 CKQuery 객체를를 사용하여 당신이 지정한 predicate와 일치하는 레코드를 검색할것. 다른 operation 객체를 사용해서 ID로 레코드를 가져온다.
데이터 관리	NSFileManager 클래스를 사용하여 파일 및 디렉토리에 직접 작업	값을 수정하려면 디폴트 NSUbiquitousKeyValueStore 객체를 사용	CloudKit 프레임 워크의 클래스를 사용하여 데이터를 관리
충돌 해결	파일 프리젠터로서 Docunents는 충돌을 자동으로 처리한다. OS X에서 NSDocument는 필요한 경우 사용자에게 문서버전을 표시한다. 파일의 경우 파일 프리젠터를 사용하여 수동으로 충돌을 해결.	키에 설정된 가장 최근 값만 남게되고 동일한 iCloud 계정에 연결된 모든 장치로 푸시된다. 각 장치가 제공하는 타임 스탬프는 데이터 수정 시간을 비교하는 데 사용된다.	레코드를 저장할 때 CKModifyRecordsOperation 객체의 savePolicy 프라퍼티에 적절한 값을 할당하여 충돌을 처리 할 방법을 지정할 것.
데이터 전송	iOS에서는 조정 된 읽기(coordinated read)를 수행해서 iCloud 파일의 로컬 복사본을 가져올 것; 그러면 로컬 파일 시스템 변경에 따라 데이터가 자동으로 iCloud로 푸시된다. OS X에서는 iCloud 파일은 로컬 파일 시스템 변경에 따라 자동으로 iCloud에 푸시된다.	로컬 파일 시스템 변경에 따라 자동으로 이루어진다.	클라우드킷 operation 객체 또는 CKOperation 및 CKDatabase 클래스의 편의 메소드를 사용하여 데이터 전송을 시작할 것
메타데이터 전송	로컬시스템 변경에 따라 자동	사용 불가(key-value storage 는 메타데이터를 사용하지 않는다)	사용 불가
UI	iOS에서는 제공되지 않는다. 아이클라우드 데이터를 표시하는 건 당신이 할 일.필요한 경우 iCloud 적용 이전의 UI에서 최소한만 변경하도록하고 원할하게 수행하기 바람. OS X에서는 NSDocument 클래스가 iCloud UI를 제공한다.	사용불가 사용자는 iCloud에 저장된 key-value 데이터에 대해 알 필요없다.	레코드에서 가져온 데이터를 표시하기위한 인터페이스를 제공하는 것은 당신 몫이다.