iOS最佳實踐
一、為什麼閱讀本文檔
跳進了 iOS 的坑真是麻煩。無論是 Swift 還是 Objective-C， 都沒有在其他地方廣泛使用，而且這個平台對每個東西都幾乎有它自己的命名方式，並且連要在真機上調試都充滿了坎坷。無論你是剛剛入門 Cocoa 還是想糾正自己開發習慣的開發者，都能從本文檔獲益。不過下面寫的僅僅是建議，所以如果你有一個更好的方案，那就試試吧！
二、入門
Xcode
Xcode 是大多數 iOS 開發者的選擇，並且是 Apple 唯一官方支持的IDE。有一些其他的選擇，比如 AppCode 是最有名的，但是除非你是經驗豐富的開發者，否則就使用 Xcode 吧。不要管它的一些小缺點啦，它現在已經蠻好用咯。
要安裝 Xcode，只需要下載 Mac App Store 中的 Xcode。它會同時下載最新的 SDK 和模擬器，同時你可以從 Preferences > Downloads 下載更多的內容。
項目初始化
開始iOS開發的時候，一個常見的問題是用代碼寫所有的 view 還是使用 Interface Builder（Storyboards 或者 XIB ）。兩種方案都久經考量。但是，有下面幾個考慮：
為什麼使用代碼？
Storyboard 因為它的復雜的 XML 結構容易帶來版本沖突，這讓代碼合並變得困難。
容易用代碼結構化以及復用 view，讓你的代碼變得 DRY。
所有的信息匯集一處。在 Interface Builder 裡面你需要點擊所有的檢查器來尋找你要找的東西。
為什麼用 Storyboard？
為了更少的技術要求，Storyboard 使用了一個很好的直接貢獻於項目的方法，比如，通過調整顏色或者布局的 constraints。然而，它要求一個項目已經做好配置，並且開發者有一些時間掌握基礎
當你不用構建項目也能看到變化的時候，集成更快了
在 Xcode6 裡面，自定義的文字和 UI 元素在 storyboard 裡面都可以可視化表示，比你在代碼裡面修改好多了
從iOS8開始，Size Classes 允許你設計不同類型設備的屏幕，不用重復一些工作
忽略文件
當把項目放入版本控制系統的時候，首先應該有一個好的 .gitignore 文件。這樣，不必要的文件（用戶設置，臨時文件這些）都不會放進你的倉庫裡面。幸運的是，Github 已經給了我們 Objective-C 和 Swift 語言的模板
CocoaPods
如果你計劃增加外部依賴(比如，第三方庫)在你的項目中，CocoaPods 提供了一個快捷的途徑，就像這樣：
sudo gem install cocoapods
要開始使用，僅僅需要在你的 iOS 項目目錄下運行：
pod init
它會創建一個 Podfile， 會管理你所有的依賴，在 Podfile 中加入你的依賴後，允許
pod install
來安裝第三方庫並且將它們作為 workspace 的一部分，你的 workspace 也會包含你自己的項目。 一般推薦提交你自己的項目的依賴，而不是每個開發者在一個 checkout之後運行 pod install 。
注意在之後，你需要打開 .xcworkspace 而不是 .xcproject，否則你的代碼就不能被編譯了，命令：
pod update
會升級所有的 pod 到最新版本，你可以用大量 符號 來定義你期望的版本需求。
三、項目結構
為了組織目錄裡面的上百個源代碼文件，最好根據你的架構來設置一些文件結構。比如，你可以用這樣的：
├─ Models ├─ Views ├─ Controllers ├─ Stores ├─ Helpers
首先，將他們創建為 Group（黃色的目錄），用 Xcode 的項目導航裡面的你的項目中。然後對每個項目裡的文件，將它麼連接到真實的文件目錄 —— 通過打開它右邊的文件檢查器，點擊小小的目錄圖標，在你的項目目錄下創建一個和 group 同名的子目錄。
本地化
一開始就應該把所有的顯示給用戶的字符串放進本地化文件。這樣不僅僅為了翻譯方便，同時也便於查找用戶看見的文本。你可以在 build Scheme 中加入一個啟動參數來指定特定的語言
-AppleLanguages (Finnish)
對於更復雜的翻譯問題，比如復數（比如 "1 person" 和 "3 people"），你應該使用 .stringsdict format 而不是一個普通的 localizable.strings 文件。在有了這個強大的工具來處理比如 "one", some", "few" 和 "many" 的情況。 當處理俄羅斯語和阿拉伯語的時候，你就不用急得抓耳撓腮了。
關於本地化的更多信息，看 2012年 2月的 Helsink iOS 會議的 幻燈片，大部分內容對現在也是適用的。
常量
創建被 prefix header 引入的一個 Constants.h 文件。
不要用宏定義（用 #define），用實際的常量定義
static CGFloat const XYZBrandingFontSizeSmall = 12.0f; static NSString * const XYZAwesomenessDeliveredNotificationName = @"foo";
常量類型安全，並且有更明確的作用域（並不是在所有沒有被引入的文件中能使用）。不能被重定義，並且可以在調試器中使用。
分支模型
特別是分發你的 app 的時候（如提交到 App Store），最好把分支用特別的 tag 區分。同時，新特性的開發，會引入很多 commit 的，也應該在獨立的分支上提交。git-flow 是一個幫助你遵從這個約定的工具。它簡單地包裝了 git的分支和tag的命令，幫助維護一個正確的分支結構。所有的開發分支（比如 develop）， 關於 app版本的tag分支以及提交到 master分支的：
git flow release finish
四、常用庫
總得來說，來把一個第三方庫加入到你的項目中需要慎重考慮。確實，一個靈巧的庫或許能幫助你解決現在的問題，但是可能在之後陷入維護的噩夢，比如在下一個系統版本改變一些東西之後，或者一個第三方庫的場景變成了官方的API。不過在一個良好的設計的代碼中，切換實現是很輕松的。盡量考慮用 Apple 的廣泛（而且優秀的）框架吧～
這個小節盡量保持剪短。庫的特性是為了減少模板代碼（比如 AutoLayout）或者解決復雜的需要很多測試的問題，比如日期計算。當你在 iOS 中更加專業的時候，挖掘這裡的源代碼，通過它們底層的 Apple 框架來認識他們，你會發現這些可以做大量工作。
AFNetworking
99.95% 的 iOS開發者使用這個網絡庫，當 NSURLSession 自己本身也非常完善的時候， AFNetworking 仍然能憑借很多 app 需要的隊列請求管理功能立足於不敗之地。
DateTools 日期工具
總得來說，不要自己寫日期計算。幸運的是，有一個 DateTools 是 MIT 協議的，而且經過徹底測試的，你可以放心的在需要用日期的時候使用它。
Auto Layout 庫
如果你更喜歡在代碼裡面寫界面，你會用過 Apple 難用的 'NSLayoutConstraint' 的工廠或者 Visual Format Language 。前者很羅嗦，後者基於字符串，不利於編譯器檢查。
Masonry 通過它們自己的 DSL 來取代常量， Swift 中一個類似的庫是 Cartography，它利用了語言的豐富的操作符重載特性。如果更加保守的話，FLKAutoLayout 提供了一個干淨但是沒有太多魔法的原生 API 包裝。
Architecture 架構
Model-View-Controller-Store (MVCS)
這是 Apple 默認的架構（MVC），通過擴展一表示 Model 實例的存儲層以及處理網絡，緩存等內容。
每一個存儲通過 RACSignals 或者 void 返回值的自定義 block 方法來返回。
Model-View-ViewModel (MVVM)
通過 "massive view controllers": MVVM 認為 UIViewController 子類是vuew的一部分，並且保持精簡，通過在 viewmodel裡面維持狀態。
對於 Cocoa 開發者是非常新的概念，但是 獲得 推動
View-Interactor-Presenter-Entity-Routing (VIPER)
值得在大型項目中一看的架構，在 MVVM 都顯得復雜，而且需要關注測試的時候。
五、事件模式
這裡有一些通知其他對象的常用方法：
Delegation （委托）: _(一對一)_ Apple 經常用它（或者說，太多了）。用它來執行回調，比如， Model View 做一個回調
Callback blocks （回調代碼塊）: _(一對一)_ 可以更加解耦，可以維護類似的相關代碼段。同時在有很多 sender 的時候比委托有更好的擴展性。
Notification Center （通知）: _(一對多)_ 最常用的對象來向第一個觀察者發送事件的方法。非常解耦合 - 通知甚至可以全局地進行觀察，而不用引用派發對象
Key-Value Observing (KVO，鍵值編碼): _(一對多) 不需要觀察者來明確發送的時間，就像 _Key-Value Coding (KVC) 符合觀察的鍵（屬性）。通常不推薦使用，因為他不自然的特性以及繁瑣的API。
Signals（信號）: _(一對多)_ ReactiveCocoa 的核心, 允許鏈接和組合你的內容, 提供了防止 callback hell 的一個方法。
Models
保持你的 model 是不可變的，以及用他們來改變遠程的 API 的語義以及類型。Github 的 Mantle 是一個好的選擇
Views
當用 Auto Layout 布局你的 view 的時候，確保在你父類中加入了下面的代碼：
+ (BOOL)requiresConstraintBasedLayout
{
return YES;
}否則當系統沒有調用 -updateConstraints 的時候，你可能會遇到奇怪的 bug。
Controllers
建議使用依賴注入，比如：傳遞任何需要的對象作為參數，而不是在一個單例中保持所有的狀態。後一種方法僅僅在狀態是 真的 全局的時候適用。
+ [[FooDetailsViewController alloc] initWithFoo:(Foo *)foo];
六、網絡
傳統的方式：使用回調 block
// GigStore.h
typedef void (^FetchGigsBlock)(NSArray *gigs, NSError *error);
- (void)fetchGigsForArtist:(Artist *)artist completion:(FetchGigsBlock)completion
// GigsViewController.m
[[GigStore sharedStore] fetchGigsForArtist:artist completion:^(NSArray *gigs, NSError *error) {
if (!error) {
// Do something with gigs
}
else {
// :(
}
];這樣運行，但是如果你有多個組合的網絡請求的時候，就會進入回調嵌套的地獄。
Reactive 的方法： 使用 RAC 信號
如果你發現已經陷入了回調的地獄，看看 ReactiveCocoa (RAC) 吧，它是一個萬能而且多功能的庫，能改變大家寫 整個 app 的方法，但是你可以在它適用的地方保守地使用它。
在 Teehan+Lax 和 NSHipster 上面有一些關於 RAC (and FRP in general) 以及函數式編程的概念的優秀介紹。
// GigStore.h
- (RACSignal *)gigsForArtist:(Artist *)artist;
// GigsViewController.m
[[GigStore sharedStore] gigsForArtist:artist]
subscribeNext:^(NSArray *gigs) {
// Do something with gigs
} error:^(NSError *error) {
// :(
}
];它允許通過信號和其他信號的結合，在展示它們之前做一些改變。
七、Assets 資源
Asset catalogs 是管理你所有項目可視化資源的最好方式，它們可以同事管理通用的以及設備相關的iPhone 4-inch, iPhone Retina, iPad,等)資源，並且會自動通過它們的名字分組。告訴你的設計師如何添加它們（Xcode有內置的 Git 客戶端）可以節省很多時間，否則你會話很多時間來在從郵件或者其他渠道復制到代碼庫裡面。它可以讓設計師馬上嘗試資源改變的樣子，並且反復實驗。
Using Bitmap Images 使用位圖
Asset catalogs 僅僅暴露了圖片的名稱，圖片集裡面的抽象的名字。這可以避免資源名字的沖突，就像 [email protected] 的文件的命名空間在它的圖片集裡面。遵守一些命名規則可以讓生活更美好：
IconCheckmarkHighlighted.png // Universal, non-Retina [email protected] // Universal, Retina IconCheckmarkHighlighted~iphone.png // iPhone, non-Retina IconCheckmarkHighlighted@2x~iphone.png // iPhone, Retina IconCheckmarkHighlighted-568h@2x~iphone.png // iPhone, Retina, 4-inch IconCheckmarkHighlighted~ipad.png // iPad, non-Retina IconCheckmarkHighlighted@2x~ipad.png // iPad, Retina
修飾後綴 -568h, @2x, ~iphone and ~ipad 是不必要的，但是有他們在文件裡面，當把文件拖進去的時候，Xcode會正確地處置它們。這避免賦值錯誤。
使用向量圖
你可以用設計師原始的 vector graphics (PDFs) 加入到 asset catalogs，Xcode可以自動地根據它們生成位圖。這減少了你的工程的復雜性（管理更少的文件）。
八、代碼風格
命名
盡管命名約定很長，但是Apple一如既往地在 API中 遵守了命名原則。
這裡有一些你應該使用的基本原則：
一個方法用 動詞 開頭的表示它做了一些副作用，但是不會返回任何東西：
- (void)loadView;
- (void)startAnimating;
任何以 名詞 開頭的方法，沒有副作用而且返回了它指的對象：
- (UINavigationItem *)navigationItem;
+ (UILabel *)labelWithText:(NSString *)text;
盡量分離兩者，比如，不要在操作數據的時候產生副作用，反之亦然。這會讓你的副作用包含到代碼更小的細分粒度裡面，讓調試變得非常困難。
結構
Pragma marks 是把你代碼分組的一個好方法，特別是在 view Controller裡。下面的結構可以適用於絕大多數 view Controller的工作：
#import "SomeModel.h" #import "SomeView.h" #import "SomeController.h" #import "SomeStore.h" #import "SomeHelper.h" #import static NSString * const XYZFooStringConstant = @"FoobarConstant"; static CGFloat const XYZFooFloatConstant = 1234.5; @interface XYZFooViewController () @property (nonatomic, copy, readonly) Foo *foo; @end @implementation XYZFooViewController #pragma mark - Lifecycle - (instancetype)initWithFoo:(Foo *)foo; - (void)dealloc; #pragma mark - View Lifecycle - (void)viewDidLoad; - (void)viewWillAppear:(BOOL)animated; #pragma mark - Layout - (void)makeViewConstraints; #pragma mark - Public Interface - (void)startFooing; - (void)stopFooing; #pragma mark - User Interaction - (void)foobarButtonTapped; #pragma mark - XYZFoobarDelegate - (void)foobar:(Foobar *)foobar didSomethingWithFoo:(Foo *)foo; #pragma mark - Internal Helpers - (NSString *)displayNameForFoo:(Foo *)foo; @end
最重要的一點是在你項目的類中保持一致性
其他風格指南
我們公司沒有任何公司級別的代碼風格指南，詳細看看其他開發者的 Objective-C 風格指南很有用，即使一些內容是公司相關的或者過於激進了。
GitHub
Google
The New York Times
Ray Wenderlich
Sam Soffes
Luke Redpath
九、診斷
編譯警告
推薦你盡可能多打開編譯警告，並且像對待錯誤一樣對待編譯警告。推薦 這個PPT。這個幻燈片覆蓋了如何在特定文件，或者特別代碼段裡面消除相關警告的內容。
簡單的來說，至少需要在 _“Other Warning Flags” 編譯設置裡面定義下面的值：
-Wall _(增加很多的警告)_
-Wextra _(增加更多的警告)_
同時打開 “Treat warnings as errors”
Clang 靜態分析
Clang 編譯器（Xcode使用的）有一個 靜態分析器 來進行你的代碼控制和數據流的分析，來檢測編譯器不能檢測的許多錯誤。
你可以通過在 Xcode 裡面手動運行 Product → Analyze 菜單項來手動執行代碼分析
分析器可以用淺或者深的模式允許，後者更加慢，但是可以從跨函數的控制流和數據流上分析更多問題
推薦：
打開 所有 分析器檢查 (通過在 building setting 中打開所有 “Static Analyzer” 選項)
在 release 的編譯設置裡面打開 “Analyze during ‘Build’” 來讓分析器自動在發布的版本構建的時候允許。(這樣你就不需要記住要手動運行了)
把 “Mode of Analysis for ‘Analyze’” 設置為 Shallow (faster)
把 “Mode of Analysis for ‘Build’” 設置為 to Deep
Faux Pas
我們自己的Ali Rantakari 創建的，Faux Pas 是一個極佳的靜態錯誤檢測工具，它分析你的代碼並且找出那些你自己甚至都沒發現的問題。在提交你的 App 到應用商店前用它吧！
調試
當你的 App 崩潰的時候，Xcode 不會默認進入到調試器裡面。為了調試，你需要增加一個異常斷點（在 Xcode 的 Debug 導航中點 “+”），來在異常發生的時候退出執行。在很多情況下，你需要看看觸發這些異常的代碼。它會捕捉任何異常，即使是已經處理的。如果 Xcode 在 一個第三方庫裡面中斷執行，比如，你可能需要通過選擇 Edit Breakpoint 並且設置 Exception 為 Objective-C.。
對於視圖 debug， Reveal 和 Spark Inspector 這兩個強有力的可視化檢查工具可以幫你省下很多時間，特別是在你使用 Auto Layout 並且希望定位出問題或者溢出屏幕的視圖的時候。Xcode 提供了免費的類似功能，但是只能適用於 iOS 8+ 並且不那麼好用。
分析
Xcode 有一個叫 Instruments 的分析工具，它包括了
許多分析內存，CPU，網絡通訊，圖形以及更多的工具，它有點復雜的，但是它的追蹤內存洩漏的時候還是蠻直觀的。只需要在 Xcode 中 選擇 Product > Profile，選擇 Allocations， 點擊 Record 按鈕並且用一些有用的字符串過濾申請空間的信息，比如你自己的app的類名。它會在固定的列中統計，並且告訴你每個對象有多少實例。到底是什麼類一直增加實例導致內存洩漏。
Instruments 也有自動化的工具來進行錄制並且運行UI交互以及JavaScript文件。UI Auto Monkey 是一個自動化隨機點擊、滑動以及旋轉你的app的腳本，他在壓力、滲透測試中很有用。
十、統計
強烈推薦使用一些統計框架，他們直觀地告訴你有多少人用你的應用。X 特性增加了用戶麼？Y 按鈕很難找到麼？為了回答這些問題，你可以發送事件，允許時間以及其他記錄的信息到一個聚集它們並且可視化它們的服務。比如， Google Tag Manager 。這個是一個比 Google Analytics 更加有用的地方是可以在app 和統計之間插入數據，所以數據邏輯可以通過 web 服務進行修改，而不用更新你的app。
一個好的實踐是創建一個簡單的 helper 類，比如 XYZAnalyticsHelper，處理 app 內部 model 以及數據格式 (XYZModel, NSTimeInterval, …)的變換，來適配字符串為主的數據層，
- (void)pushAddItemEventWithItem:(XYZItem *)item editMode:(XYZEditMode)editMode
{
NSString *editModeString = [self nameForEditMode:editMode];
[self pushToDataLayer:@{
@"event": "addItem",
@"itemIdentifier": item.identifier,
@"editMode": editModeString
}];
}另外的優點是，你在必要的時候可以替換整個統計框架，而不用改變 app 其他部分。
Crash Logs 崩潰日志
應該讓你的 app 向一個服務發送崩潰日志。你可以手動實現，通過 PLCrashReporter 以及你自己的後端。但是強烈推薦你使用現有的服務，比如下面的
Crashlytics
HockeyApp
Crittercism
Splunk MINTexpress
當你配置好後，確保你 保存了 the Xcode archive (.xcarchive) 對於每一個 app 放出的版本。這個 歸檔中包含了構建的app的二進制以及調試符號(dSYM)，你需要用每個版本特定的app把你的 Crash 報告符號化。
十一、構建
構建設置
每一個簡單的 app 都可以不同的方式構建，最基本的分離是 Xcode 給你 debug 和 release 之間的構建方案。後者在編譯的時候有更多的優化，可能會導致你需要多調試一些問題。 Apple 建議你在開發的時候用 debug 模式，在打包的時候用 release 設置。這是默認的 Scheme （Play 和 Stop 後面的下拉菜單），運行Run 的時候會 用 debug 設置而運行 Archive 的時候會使用 release。
然後，對於真實的 app 這似乎太簡單了。你 不該 設置多個為測試，staging和其他相關的開發活動。每一個可能有自己的 URL，日志級別，bundle ID）所以你可以一起安裝它們，以及描述文件。然後一個簡單的 debug/release 區別不能分離這些，你可以在你項目的設置中的 Info 選項卡做更多的編譯設置。
關於構建設置的 xcconfig 文件
通常構建設置是 Xcode GUI定義的，但是你同樣可以用 configuration settings files (“.xcconfig files”)，優點是：
你可以注釋
你可以 #include 其他構建設置文件, 能幫助你減少重復:
如果你有一些適用於所有構建設置的設置, 增加一個Common.xcconfig 並且在其他構建設置文件裡面 #include
如果你，比如，希望有一個 “Debug” 構建設置文件，允許編譯器優化，你只需要 #include "MyApp_Debug.xcconfig"來重載其他設置
沖突解決和合並變得更輕松
更多關於這個主題的信息請看這個 PPT。
Targets
一個 target 是處於比項目更低一級的級別。比如，一個項目可能有多個target，可能重載它的項目設置。簡單地說，每個 target 和一個 app相當。比如，你可能有幾個因為國家區分的 app （從同樣的代碼編譯）來提交到 App Store。每個會有 development/staging/release 的構建，所以最好通過構建設置而不是 target來區分。一個 app 只有一個 target 是很少見的。
Schemes
Schemes 告訴 Xcode 在你點擊 Run, Test, Profile, Analyze 或者 Archive 操作的時候應該怎麼做。它們把這些操作映射到一個 target 和一個構建設置中。你可以傳遞啟動參數，比如 app 需要允許的語言（為了測試本地化）或者一些了為了調試用的診斷標志。
一個建議的 Scheme 命名是 MyApp (
MyApp (English) [Development] MyApp (German) [Development] MyApp [Testing] MyApp [Staging] MyApp [App Store]
對於大多數環境來說語言部分是不必要的，app 會可能會以非 Xcode 的方式安裝，比如用 TestFlight， 啟動參數會被忽略。這個情況下，為了測試本地化需要手動設置設備的語言。
十二、部署
部署一個軟件到 iOS 設備上並不直觀。但是有一些核心觀點，只要理解了，對你有很大的幫助。
簽名
當你需要在真實設備上運行軟件的時候，你需要用一個 Apple 認證的 證書 簽名。每一個證書是連接到一個 公、私 密鑰對，私鑰會保存在你的 Mac 的 KeyChain 裡面，證書有兩種類型
開發證書: 每個組的開發者都有自己的證書，而且它通過請求特到。Xcode可以幫你完成，但是最好不用點擊 "Fix issue" 來完成，而是理解它到底做了什麼事情。在部署開發版本到設備上的時候需要這個證書。
發布證書: 可以有多個，但是最好每一個組織有一個，並且通過內部渠道共享。在提交 App 到 App Store 或者你的企業的內部 App Store的時候需要這個證書。
描述文件
除了證書，還有 描述文件， 它把設備和證書連接起來。而且，它分成開發和發布兩種類型。
Development provisioning profile: 開發描述文件， 它包含了一個包含所有能安裝這個 app 的設備列表。它連接了一個或者多個開發者允許這個描述文件使用的證書。描述文件可以確認特定的 app，但是對於大多數開發目的，它特別適合用一個通配符描述文件，也就是 Apple ID 以一個 星號 (*)結尾的。
Distribution provisioning profile: 發布描述文件 本身，對於不同使用目的也有不同的類型。每一個發布描述文件 鏈接到一個發布證書，並且在證書過期的時候失效。
Ad-Hoc: 就像開發證書一個，它包含了一個 app 可以安裝的設備的白名單。這個描述文件可以用來做 beta 版本，每年可以測試 100 個設備。為了做更細致的測試以及升級到 1000 個測試用戶，你可以使用 Apple 最近發布的 TestFlight 服務， Supertop 提供了一個 summary of its advantages and issues.
App Store: 這個 profile 沒有列出設備，任何人都可以通過蘋果官方的發布來安裝，所有 App Store 發布的 App都需要這個證書
Enterprise: 就像 App Store，沒有設備白名單，任何通過企業內部網絡的人都可以從內部“應用商店”安裝。應用商店可能只是一個帶連接的網站。這個描述文件只允許企業賬號使用。
想同步所有的證書和描述文件到你的機器，可以去 Xcode 的 Preferences 的 Accounts下，添加你的 Apple ID, 然後雙擊你的 Team 名稱。然後底部會有一個刷新按鈕，有時候你需要重啟 Xcode 來讓東西顯示出來。
調試描述文件
有時候你需要調試一個描述文件的問題。比如，XCode 可能拒絕安裝 app 到一個設備中，因為設備沒有在開發或者 Ad-doc發布的的描述文件設備列表中。這個情況下，你可以使用 Craig Hockenberry 的 Provisioning 插件，浏覽 ~/Library/MobileDevice/Provisioning Profiles，選擇一個 .mobileprovision 文件，並用空格鍵調用 Finder 的快速查看特性，它會告訴你關於設備，entitlements，證書以及 Apple ID的信息。
上傳
iTunes Connect 是你管理上傳到 App Store的 App 的後台網站。 Xcode 6 需要一個 Apple ID 作為開發者賬號來簽名並且上傳二進制。如果你有多個開發者賬號而且要上傳它們的 app 就需要一點技巧。 因為 一個 Apple ID 只能和一個 iTunes Connect 賬號關聯, 一個變通方案是為每個 iTunes Connect 賬號創建一個新的 Apple ID, 使用 Application Loader 取代 Xcode 來上傳應用。這樣有效地解除了上傳最終 .app 文件構建和簽名的耦合。
在上傳二進制後，耐心等待，可能要花上一個小時。當你的 App 出現後，可以鏈接到對應的App版本並且提交審核
十三、應用內購買
當驗證一個 App內購的 receipt的時候，記住做以下步驟：
Authenticity: receipt 是來自 Apple 的
Integrity: receipt 沒有被篡改
App match: receipt 的 App bundle ID 和你的 App bundle ID 一致
Product match: receipt 裡面產品 ID和你期望的一致
Freshness: 你之前沒有驗證一樣的 receipt ID
如果可能，把你的 IAP 存儲銷售相關的內容存儲在服務器端，並且只在一個合法的經過上述檢查的 receipt。這樣的設計避免了常見的盜竊機制，同時，因為服務器做了驗證，所以你可以使用 Apple 的 HTTP 驗證服務來取代你自己的 PKCS #7 / ASN.1 格式。
更多關於這個主題的信息可以看Futurice blog: Validating in-app purchases in your iOS app
