UIKit框架為管理多個文檔的應用程序提供支持，每個文檔包含存儲在應用程序沙箱或iCloud中的文件中的唯一數據集。

這個支持的核心是在iOS 5.0中引入的UIDocument類。 基于文檔的應用程序必須創建UIDocument的子類，它將文檔數據加載到其內存數據結構中，并向UIDocument提供要寫入文檔文件的數據。 UIDocument負責管理與文檔管理有關的許多細節。 除了與iCloud的集成外，UIDocument還會在后臺讀取和寫入文檔數據，以便您的應用程序的用戶界面在這些操作中不會變得無響應。 它還可以自動定期保存文檔數據，讓用戶免于明確保存。

概述

雖然基于文檔的應用程序負責一系列行為，但是編寫基于應用程序文檔的應用程序通常不是一件困難的任務。

文檔對象是模型控制器

在Model-View-Controller設計模式中，文檔對象（即UIDocument的子類的實例）是模型控制器。文檔對象管理與文檔相關聯的數據，特別是內部表示用戶正在查看和編輯的模型對象。文檔對象通常由向用戶呈現文檔的視圖控制器來管理。

相關章節：設計基于文檔的應用程序

設計應用程序時，考慮文檔數據格式和其他問題

在編寫代碼之前，您應該考慮到基于文檔的應用程序特定的設計方面。最重要的是，您的應用程序的文檔數據的最佳格式是什么，以及如何使該格式在iOS和Mac OS X中為您的應用程序工作？什么是最合適的文件類型？

您還需要規劃視圖控制器（和視圖）來管理打開文檔，指示錯誤以及將所選文檔移入和移出iCloud存儲的任務。

相關章節：設計基于文檔的應用程序，基于文檔的應用程序預檢

創建UIDocument的子類需要兩個方法覆蓋

文檔對象的主要作用是將文檔文件和內部表示文檔數據的模型對象之間的數據“管理”。它給UIDocument類寫入文檔文件的數據，在讀取文檔文件之后，它使用UIDocument給出的數據來初始化其模型對象。為了履行此角色，您的UIDocument子類必須分別重寫contentForType：error：method和loadFromContents：ofType：error：method。

相關章節：創建自定義文檔對象

應用程序通過其生命周期管理文檔

應用程序負責管理文檔生命周期中的以下事件：

創建文件
打開和關閉文檔
監視文檔狀態的更改并響應錯誤或版本沖突
將文檔移動到iCloud存儲（并將其從iCloud存儲中刪除）
刪除文件
相關章節：管理文件的生命周期

應用程序在用戶請求后存儲iCloud中的文檔文件

應用程序為用戶提供將所有文檔文件放在iCloud存儲或本地沙箱中的所有文檔文件的選項。要將文檔文件移動到iCloud，它們將文檔URL組織到應用程序的iCloud容器目錄中，然后調用NSFileManager類的特定方法，傳遞文件URL。將文檔文件從iCloud存儲移動到應用程序沙箱遵循類似的過程。

相關章節：管理文件的生命周期

應用程序確保文檔數據自動保存

UIDocument遵循無保留模式，并以特定的間隔自動保存文檔的數據。用戶通常不需要明確保存文檔。但是，您的應用程序必須發揮其作用，才能使無節制模式正常工作，無論是通過執行撤消和重做，還是通過跟蹤文檔的更改。

相關章節：更改跟蹤和撤消操作

應用程序解決不同文檔版本之間的沖突

當文檔存儲在iCloud中時，可能會發生文檔版本之間的沖突。發生沖突時，UIKit通知應用程序。應用程序必須嘗試解決沖突本身或邀請用戶選擇他或她喜歡的版本。

相關章節：解決文件版本沖突

如何使用本文檔

在開始為基于文檔的應用程序編寫任何代碼之前，您應至少閱讀前兩章，設計基于文檔的應用程序和基于文檔的應用程序預檢。這些章節將討論設計和配置問題，并概述了精心設計的基于文檔的應用程序所需的任務

先決條件

在閱讀“基于文檔的iOS應用程序編程指南”之前，您應該熟悉iOS應用程序編程指南中提供的信息。

也可以看看

以下文檔以某種方式與基于文檔的iOS應用程序編程指南相關：

統一類型標識符概述和相關參考討論了統一類型標識符（UTI），它們是文檔類型的主要標識符。
“文件元數據搜索編程指南”介紹了如何使用NSMetadataQuery類和相關類進行搜索。您使用元數據查詢來查找存儲在iCloud中的應用程序的文檔。
iCloud設計指南提供了iCloud文檔支持的介紹。

設計基于文檔的應用程序

在iOS 5.0中引入的UIDocument類在基于文檔的iOS應用程序中起主要作用。它是一個抽象的基類 - 這意味著你有一些有用的東西，你必須創建一個適合你的應用程序需求的子類。添加到子類中的特定于應用程序的代碼增強了UIDocument可以實現的功能：與iCloud存儲集成的移動環境中的文檔的高效行為。

為什么要創建一個基于文檔的應用程序？

當您有任何應用的想法并坐下來設計它時，您必須評估許多選項。您應該使用什么樣的應用程序（主 - 細節，基于頁面的實用程序，OpenGL游戲等）？應用程序是否會自己繪制圖形，是否會對手勢或觸摸事件做出響應，并且會合并視聽資產嗎？如果應用程序使用核心數據，數據模型將是什么？是否使您的應用程序基于文檔的決定可能似乎使這一系列選擇變得復雜，但它真的歸結為如何預期人們將使用您的應用程序。

當用戶期望在可視容器中輸入和編輯內容并以指定的名稱存儲該內容時，基于文檔的應用程序是理想的，甚至是必要的。每個容器的信息 - 一個文件 - 是唯一的。您無疑熟悉桌面和移動系統中發現的幾種基于文檔的應用程序。舉幾個例子，有文字處理程序，電子表格和繪圖程序。通過iCloud技術，您可以使您的應用程序文檔更加引人入勝。例如，您的用戶可以使用OS X桌面系統上的應用程序創建文檔，然后再使用iOS版本的應用程序在iPad上編輯該文檔，而無需進行任何同步或復制。這個功能使他們有更多的動機去購買你的應用程序。

當您采用基于文檔的應用程序的UIDocument方法時，您的應用程序可以免費獲取大量行為，或者以最少的編碼工作。

與iCloud存儲集成。 UIDocument對象協調從iCloud存儲器讀取和寫入文檔數據的所有內容。它通過采用NSFilePresenter協議和調用NSFileCoordinator和NSFileManager類的方法來實現。
后臺寫入和讀寫文件數據。如果您的應用程序同步讀取和寫入文檔，它將變得暫時無響應。 UIDocument對象通過在背景調度隊列上異步讀取和寫入文檔數據來避免此問題。
無需保存的模型，基于文檔的應用程序的用戶很少需要明確保存文檔; UIDocument對象按照用戶正在使用的文檔進行優化的間隔自動保存文檔數據。您可以通過實施撤銷管理或更改跟蹤來實現基于文檔的應用程序“無節制”（請參閱更改跟蹤和撤消操作信息）。
安全保存，UIDocument對象安全地保存文檔數據;因此，如果一些外部事件中斷保存操作，文檔數據將不會保持不一致的狀態。該對象通過首先將最新版本的文檔寫入臨時文件，然后用其替換當前文檔文件來實現安全保存。
支持處理錯誤和版本沖突。當UIDocument對象檢測到不同版本的文檔之間的沖突時，它會通知應用程序。然后，應用程序可以嘗試解決沖突本身，或者可以要求用戶選擇所需的文檔版本。當保存操作不成功時，UIDocument對象還會通知應用程序。管理文檔的生命周期描述了如何觀察這些通知;解決文檔版本沖突討論了處理文檔版本沖突的策略

iOS中的文檔

雖然文檔的廣泛定義是“信息容器”，但可以通過多種方式查看該容器。對于用戶，文檔是他或她以唯一的名稱創建，編輯和保存的文本，圖像，形狀和其他形式的信息。文檔還可以參考文檔文件：文檔數據的持久磁盤表示。一個文檔可以表示一個UIDocument對象，它表示和管理同一數據的內存中的表示。

文檔對象在將文檔數據在其在磁盤上的表示與其在存儲器中的表示之間的轉換中也起關鍵作用。它與UIDocument類合作，將文檔數據寫入文件并讀取該數據。對于寫入，文檔通常提供可以寫入文檔文件的數據的快照;為了閱讀，它接收數據并用它初始化文檔的模型對象。在某種意義上，文檔是存儲在文件中的數據與該數據的內部表示之間的通道。圖1-1說明了這些關系。

圖1-1由文檔對象管理的文檔文件，文檔對象和模型對象

document_model_2_2x.png

iCloud存儲中的文檔

在iCloud中，文件駐留在與應用程序關聯的容器目錄中。該目錄具有內部結構，其中最重要的是一個Documents子目錄。在iCloud方案中，寫入Documents子目錄的文件和文件包將被視為文檔文件 - 即使它們不是基于文檔的應用程序。寫入容器目錄中其他位置的文件被視為數據文件。

文檔對象是文件呈現器，因為UIDocument類采用NSFilePresenter協議。文件演示者與NSFileCoordinator對象一起使用，以協調對應用程序對象之間以及應用程序和其他進程之間的文件或目錄的訪問。文件演示者涉及其他客戶端訪問相同的文件或目錄。

當用戶要求將文檔文件存儲在iCloud存儲中時，基于文檔的應用程序應將這些文件（包括文件包）保存在iCloud容器目錄的Documents子目錄中。有關詳細信息，請參閱管理文檔的生命周期。有關iCloud移動容器的更多信息，請參閱iCloud設計指南。

UIDocument對象的屬性

文檔對象具有多個定義屬性，其中大部分與其作為文檔數據管理器的角色有關。這些屬性由UIDocument類聲明。

檔案網址，文檔必須具有可以存儲的位置，無論該位置在本地文件系統還是在iCloud存儲中。 fileURL屬性標識此位置。創建UIDocument對象時，必須指定文件URL作為UIDocument的initWithFileURL：initializer方法的參數。
文件名稱。 UIDocument對象從文件URL的文件名組件獲取默認文檔名稱，并將其存儲在localizedName屬性中。您可以覆蓋此屬性的getter方法來提供自定義的本地化文檔名稱。
注意：文檔的顯示名稱不必與文檔的文件名對應。此外，不需要用戶指定文檔名稱。有關此主題的更多信息，請參閱創建新文檔。
文件類型。文件類型是從文件URL的擴展名導出并分配給fileType屬性的統一類型標識符（UTI）。有關詳細信息，請參閱iOS如何識別應用程序的文檔。
修改日期。文檔文件上次修改的日期。該值存儲在fileModificationDate屬性中。它可以用于（除其他外）解決文檔版本沖突。
文件狀態文檔在其運行期間處于幾種可能狀態之一。這些狀態可以指示，例如，保存文檔或存在沖突的文檔版本時出錯。 UIDocument將當前文檔狀態存儲在documentState屬性中。有關觀察文檔狀態更改的信息，請參閱監控文檔狀態更改和處理錯誤。

基于文檔的應用程序的設計注意事項

在為基于文檔的應用程序編寫一行代碼之前，請考慮幾個設計問題。

定義對象關系

與所有應用程序一樣，您應該為基于模型 - 視圖 - 控制器設計模式（MVC）的基于文檔的應用程序的對象設計整體設計。雖然建議使用以下MVC設計文件，您可以自由地提出自己的對象關系設計。

在MVC術語中，文檔是模型控制器;它“擁有”并管理表示文檔內容的模型對象。文檔對象本身由視圖控制器擁有和管理。根據定義，視圖控制器還管理呈現由文檔對象管理的內容的視圖。因此，它是這種關系網絡中的中介控制器，從文檔對象獲取需要呈現的數據，并將用戶輸入或更改的數據傳遞給文檔對象。圖1-2描述了這些對象關系。

圖1-2視圖控制器管理文檔對象和呈現文檔數據的視圖

document_model_2_2x.png

正如視圖控制器嵌入其視圖一樣，視圖控制器可以將文檔對象嵌入為聲明的屬性。當應用程序實例化視圖控制器時，它將使用文檔對象或文檔的文件URL（視圖控制器本身可以創建文檔對象）來初始化它。

當然，基于文檔的應用程序將具有其他視圖控制器（帶有其視圖）和可能的其他模型對象。要了解可能需要其他視圖控制器的信息，請參閱設計用戶界面。

設計用戶界面

UIKit和開發人員工具都不會為基于文檔的應用程序的用戶界面提供任何支持。例如，沒有UIDocumentView類或UIDocumentViewController類，沒有用于選擇文檔的標準接口。不要后悔缺席，而是為了為您的基于文檔的應用程序創建一個使其脫穎而出的用戶界面。

盡管如此，所有基于文檔的應用程序都應使用戶能夠執行需要用戶界面元素的某些功能;這些包括以下內容：

• 查看和編輯文檔
• 創建一個新的文檔
• 從應用程序所擁有的文檔列表中選擇文檔
• 打開，關閉和刪除所選文檔
• 將選定的文檔放在iCloud存儲中（并從iCloud存儲中刪除選定的文檔）
• 指示錯誤條件，包括文檔版本沖突
• 撤消和重做更改（推薦但不需要）
  設計應用程序時，請確保包含執行這些操作所必需的視圖控制器，視圖和控件。

選擇文檔數據的類型，格式和策略

在為基于文檔的應用程序設計數據模型時，請問和回答以下問題至關重要：

我的文檔類型是什么？

文檔必須具有文檔類型，表示文檔特征的信息集合，并將其與應用程序相關聯。文檔類型具有與一個或多個文件擴展名配對的名稱，圖標（可選），處理程序排名和統一類型標識符（UTI）。對于在iOS和OS X中編輯相同文檔的應用程序，文檔類型信息應該是一致的。

創建和配置項目說明了如何在基于文檔的iOS應用程序中指定文檔類型。有關UTI和統一類型標識符的描述，請參閱統一類型標識符概述常見的統一類型標識符的說明。

我應該如何表示寫入文件的文檔數據？

你基本上有三個選擇：

Core Data。核心數據是對象圖管理和持久性的技術和框架。它可以使用內置的SQLite數據庫作為數據庫系統。 UIManagedDocument類是UIDocument的子類，用于使用Core Data的基于文檔的應用程序。
支持的對象格式,UIDocument支持NSData和NSFileWrapper對象作為文檔數據表示的本機類型。 NSData適用于平面文件，NSFileWrapper適用于文件包，它們是iOS視為單個文件的目錄。如果給UIDocument這些對象之一，它會將其保存到文件系統中，而無需進一步參與。
自定義對象格式,如果要將寫入文件的文檔數據為NSData或NSFileWrapper以外的類型，則可以在特定的UIDocument方法的替換中自己將其寫入文件。請記住，您的代碼必須重復UIDocument為您做的，因此您必須處理更大的復雜性和更大的錯誤可能性。有關更多信息，請參閱UIDocument類參考。

為什么要將文檔數據存儲在數據庫而不是文件中？

如果由文檔對象管理的數據集主要是一個較大的對象圖，但是您的應用程序隨時只使用該圖形的一個子部分，則UIManagedDocument和Core Data是一個很好的選擇。核心數據為基于文檔的應用程序帶來許多好處：

• 增量讀寫文件資料
• 支持撤消和重做操作
• 自動支持解決文檔版本沖突
• 跨平臺應用程序的數據兼容性
  核心數據的“缺點”是它是一項復雜的技術;熟悉其概念，課程和技術需要時間。要了解更多信息，請閱讀“核心數據編程指南”和“UIManagedDocument類參考”。

支持的對象格式（NSData或NSFileWrapper）最適合我的應用程序？

是否對文檔數據使用NSData或NSFileWrapper對象取決于數據的復雜程度以及文檔的模型對象圖形的部分內容是否可以單獨寫入文件。例如，如果您的文檔數據是純文本，而沒有其他數據，則NSData是適合的容器。但是，如果數據具有多個組件（例如文本和圖像），請使用NSFileWrapper方法為數據創建文件包。

• 文件包裝器對象和它們所代表的文件包比二進制數據對象提供了一些優勢。

• 文件包裝器支持增量保存。與單個二進制數據對象相反，如果文件包裝器包含文檔數據（例如文本和圖像），文本更改，則只有包含文本的文件必須寫入磁盤。此功能可以帶來更好的性能。
  文件包裝（和文件包）使得版本文檔更容易。例如，文件包可以包含一個屬性列表文件，其中包含有關文檔的版本信息和其他元數據。
  將文檔數據存儲在文件包中討論（并說明）如何使用NSFileWrapper對象來表示可以作為文件包編寫的表單中的文檔數據。

我可以歸檔我的模型對象圖并將該NSData對象寫入文檔文件嗎？

是的，這是可能的，但前面提到的一些注意事項適用。如果您的文檔的模型對象圖形的任何部分可以寫入單獨的文件，請不要歸檔該部分。相反，將NSData存檔和分區項目存儲為文件包的單獨組件。

如果我的文檔文件非常大，該怎么辦？

如果存儲在文檔文件中的數據可能很大，您可能必須逐步寫入和讀取數據，以確保良好的用戶體驗。你可能會采取幾種方法：

• 使用UIManagedDocument。記住，核心數據可以免費增加閱讀和寫作。
• 將文檔數據的可分離組件存儲在文件包中。
• 覆蓋UIDocument的較低級別的方法，并自己進行數據的讀寫。 （有關詳細信息，請參閱UIDocument類參考。）應始終使用適用于數據類型的增量讀寫API，例如，AV Foundation框架具有用于增量閱讀大型多媒體文件的方法。

如果我希望我的文檔在兩個平臺上可以編輯，我該怎么考慮？

如果您的用戶可以在iOS移動設備（iPhone，iPad和iPad touch）和OS X桌面系統上創建和編輯文檔，您的應用程序將具有競爭優勢。但是為了可以這樣做，兩個平臺上的文檔數據的格式應該是兼容的。文檔數據兼容性的一些重要注意事項是：

一些技術在一個平臺上可用，但不是另一個。例如，如果您在OS X中使用RTF作為文檔格式，則該格式在iOS中將無法運行，因為其文本系統不支持富文本。
每個平臺中的相應類別不兼容。這對于顏色（UIColor和NSColor），圖像（UIImage和NSImage）以及Bezier路徑（UIBezierPath和NSBezierPath）尤其如此。例如，NSColor對象是根據顏色空間（NSColorSpace）定義的，但在UIKit中沒有顏色空間類。
如果您使用其中一個類定義了一個文檔屬性，則必須設計一種方法（在準備文檔數據以進行寫入時）將該屬性轉換為可以在另一個平臺上精確重構的表單。這樣做的一個方法是將“下拉”到兩個平臺共享的較低級別的框架。例如，UIColor定義了一個CIColor屬性，它保存一個表示顏色的Core Image對象;在OS X端，您的應用程序可以使用colorWithCIColor：class方法從CIColor對象創建一個NSColor對象。

每個平臺的默認坐標系是不同的，這種差異可能會影響內容的繪制方式。 （有關此主題的討論，請參閱iOS繪圖和打印指南中的iOS中的坐標系和繪圖）。
如果您部分或全部歸檔文檔的模型對象圖形，則在對模型對象進行編碼和解碼時，您可能必須使用NSCoder方法執行平臺敏感轉換。

基于文檔的應用程序預檢

對于大多數開發人員來說，制作基于文檔的應用程序比基于文檔的應用程序不需要更多的工作。基本的區別在于您必須創建UIDocument的自定義子類，然后通過其運行時生命周期來管理文檔，包括與iCloud存儲的集成。本章概述了大多數應用程序執行的特定于文檔的任務，并描述了在iOS中創建和配置基于文檔的應用程序項目的一般步驟。

基于文檔的應用程序您必須做的事情

要創建基于文檔的應用程序，您應該完成以下任務：

• 創建UIDocument的自定義子類，為UIKit框架提供文檔數據的快照，并從文檔文件的內容中初始化文檔的模型對象。
  創建自定義文檔對象描述所需的方法覆蓋，如果將文檔數據存儲為文件包，說明如何使用NSFileWrapper對象進行文檔數據。

• 允許用戶創建新文檔，并選擇并打開現有文檔。您還應執行關閉文檔和刪除所選文檔的補充任務。
  請注意，創建或打開文檔的后續任務是在視圖中顯示文檔的內容。

創建新文檔，打開和關閉文檔以及刪除文檔描述這些任務的要求和步驟。這些討論還包括管理文檔數據的顯示的示例。

• 實施撤銷管理或更改跟蹤功能，實現自動保存文檔數據（無保存模型）。
  有關詳細信息，請參閱更改跟蹤和撤消操作。

• 將文檔（通常由用戶選擇的文檔）放入iCloud存儲。當用戶請求時，也可以從iCloud存儲中刪除文檔。
  從iCloud Storage移動文件討論這些過程。

• 觀察文檔狀態更改的通知，如果發生錯誤，請適當回復。
  監控文檔狀態更改和處理錯誤描述了執行此操作的一般步驟。

• 如果發生不同版本的文檔之間的沖突，請通知用戶并提供解決沖突的方法。
  解決文檔版本沖突描述了如何通知用戶版本沖突，并討論解決這些沖突的策略。

您還可以為基于文檔的應用程序添加額外的功能，例如打印文檔，拼寫檢查或將其發送給其他人的功能。

如果您的應用程序具有高級要求（例如，增量讀取和寫入大型文檔文件或處理除支持的文檔數據格式之外的文檔數據格式），請參閱UIDocument類參考。所有這些高級任務都涉及覆蓋UIDocument方法。

創建和配置項目

為基于文檔的應用程序創建Xcode項目時，請選擇合適的模板。 （請注意，沒有專門針對基于文檔的應用程序的模板。）通常，您希望應用程序的第一個視圖是用戶可以選擇現有文檔并創建新應用程序的視圖。因為Master-Detail Xcode模板適用于此目的，所以在本文檔的代碼示例中使用。此模板為您提供了iPhone的初始表視圖和iPad的拆分視圖。您的項目應使用故事板，因此請務必選擇此選項。

注意：如果您使用Core Data來管理文檔數據，請務必在“新建項目”助手中選擇“使用核心數據”選項。
根據您的應用程序的設計（請參閱設計基于文檔的應用程序），創建應用程序所需的視圖控制器子類。所有你需要的是最低限度聲明的頭文件和源文件在這一點上。然后，在項目故事板中創建應用程序的用戶界面（如果您的應用程序是通用應用程序，則創建故事板）;將自定義視圖控制器與故事板中的視圖控制器占位符相關聯。

接下來，您需要通過在Xcode目標設置中指定應用程序知道的文檔的類型或類型來配置文檔項目。

iOS如何識別您的應用程序的文檔

iOS中文檔對象最重要的屬性是其文件URL（fileURL）。文件網址很重要，除其他原因外，因為它告訴iOS哪些應用程序了解文檔的格式。文件URL以擴展名（例如html）結尾，此擴展名與統一類型標識符（例如，public.html）匹配。統一類型標識符（UTI）是文檔類型的主體標識符。使用擴展名，UIDocument查找文檔類型UTI（如圖2-1所示），并將其分配給fileType屬性。與OSX中的基于文檔的應用程序不同，iOS中的應用程序不需要將UIDocument子類與文檔類型相關聯。

圖2-1 iOS從其文件URL的擴展名查找文檔UTI

lookup_uti_from_extension_2x.png

文件類型UTI可以由系統定義;請參閱系統聲明的統一類型標識符中的統一類型標識符參考這些常見標識符的列表。基于文檔的應用程序還可以為其文檔定義自己的專有UTI（并且通常是）。如果它聲明一個自定義UTI，它還必須導出該UTI以使操作系統了解它。

聲明文檔類型
要在Xcode中聲明文檔類型，首先單擊目標信息設置中的添加按鈕，然后從彈出菜單中選擇添加文檔類型。單擊“無標題”旁邊的三角形以公開屬性字段，并添加表2-1中的屬性。

表2-1定義文檔類型的屬性（CFBundleDocumentTypes）

有關這些鍵的更多信息，請參閱信息屬性列表鍵參考中的CFBundleDocumentTypes。

完成輸入文檔類型的屬性后，Xcode的“文檔類型”區域應類似于圖2-2中的示例。

圖2-2 Xcode中文檔類型的規范

document_model_2_2x.png

應用程序可以有多種類型的文檔 - 例如，文字處理應用程序可能具有常規（空白）文檔的類型，另一種類型可以是預格式化的文檔。對于每種類型，您需要通過上面給出的程序。

導出文檔UTI

如果您為文檔定義了自定義UTI，則還必須導出它。要導出Xcode中的文檔類型，首先單擊目標信息設置中的添加按鈕，然后從彈出菜單中選擇添加導出的UTI。單擊Untitled旁邊的三角形以公開屬性字段，并添加表2-2中的屬性。

注意：聲明和導出UTI的過程在“統一類型標識符概述”中聲明新的統一類型標識符中進行了說明。
表2-2導出文檔的屬性UTI（UTExportedTypeDeclarations）

有關這些鍵的更多信息，請參閱信息屬性列表鍵參考中的CFBundleDocumentTypes。

輸入文檔類型的屬性后，Xcode的Exported UTIs區域應與圖2-3中的示例類似。

圖2-3在Xcode中導出自定義文檔UTI

export_doc_UTI_2x.png