2015-03 iOS最佳實踐
1、爲何閱讀本文檔html
跳 進了 iOS 的坑真是麻煩。不管是 Swift 仍是 Objective-C， 都沒有在其餘地方普遍使用，並且這個平臺對每一個東西都幾乎有它本身的命名方式，而且連要在真機上調試都充滿了坎坷。不管你是剛剛入門 Cocoa 仍是想糾正本身開發習慣的開發者，都能從本文檔獲益。不過下面寫的僅僅是建議，因此若是你有一個更好的方案，那就試試吧！vue
2、入門react
Xcodeios
Xcode 是大多數 iOS 開發者的選擇，而且是 Apple 惟一官方支持的IDE。有一些其餘的選擇，好比 AppCode 是最有名的，可是除非你是經驗豐富的開發者，不然就使用 Xcode 吧。不要管它的一些小缺點啦，它如今已經蠻好用咯。git
要安裝 Xcode，只須要下載 Mac App Store 中的 Xcode。它會同時下載最新的 SDK 和模擬器，同時你能夠從 Preferences > Downloads 下載更多的內容。github
項目初始化web
開始iOS開發的時候，一個常見的問題是用代碼寫全部的 view 仍是使用 Interface Builder（Storyboards 或者 XIB ）。兩種方案都久經考量。可是，有下面幾個考慮：objective-c
爲何使用代碼？express
-
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 到最新版本，你能夠用大量 符號 來定義你指望的版本需求。
3、項目結構
爲了組織目錄裏面的上百個源代碼文件，最好根據你的架構來設置一些文件結構。好比，你能夠用這樣的：
├─ 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
4、經常使用庫
總 得來講，來把一個第三方庫加入到你的項目中須要慎重考慮。確實，一個靈巧的庫或許能幫助你解決如今的問題，可是可能在以後陷入維護的噩夢，好比在下一個系 統版本改變一些東西以後，或者一個第三方庫的場景變成了官方的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 架構
-
這是 Apple 默認的架構（MVC），經過擴展一表示 Model 實例的存儲層以及處理網絡，緩存等內容。
-
每個存儲經過 RACSignals 或者 void 返回值的自定義 block 方法來返回。
-
經過 "massive view controllers": MVVM 認爲 UIViewController 子類是vuew的一部分，而且保持精簡，經過在 viewmodel裏面維持狀態。
-
值得在大型項目中一看的架構，在 MVVM 都顯得複雜，並且須要關注測試的時候。
5、事件模式
這裏有一些通知其餘對象的經常使用方法：
-
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];
6、網絡
傳統的方式：使用回調 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) {
// :(
}
];
它容許經過信號和其餘信號的結合，在展現它們以前作一些改變。
7、Assets 資源
Asset catalogs 是 管理你全部項目可視化資源的最好方式，它們能夠同事管理通用的以及設備相關的iPhone 4-inch, iPhone Retina, iPad,等)資源，而且會自動經過它們的名字分組。告訴你的設計師如何添加它們（Xcode有內置的 Git 客戶端）能夠節省不少時間，不然你會話不少時間來在從郵件或者其餘渠道複製到代碼庫裏面。它可讓設計師立刻嘗試資源改變的樣子，而且反覆實驗。
Using Bitmap Images 使用位圖
Asset catalogs 僅僅暴露了圖片的名稱，圖片集裏面的抽象的名字。這能夠避免資源名字的衝突，就像 button_large@2x.png 的文件的命名空間在它的圖片集裏面。遵照一些命名規則可讓生活更美好：
IconCheckmarkHighlighted.png // Universal, non-Retina IconCheckmarkHighlighted@2x.png // 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能夠自動地根據它們生成位圖。這減小了你的工程的複雜性（管理更少的文件）。
8、代碼風格
命名
儘管命名約定很長，可是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 風格指南頗有用，即便一些內容是公司相關的或者過於激進了。
9、診斷
編譯警告
推薦你儘量多打開編譯警告，而且像對待錯誤同樣對待編譯警告。推薦 這個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的腳本，他在壓力、滲透測試中頗有用。
10、統計
強烈推薦使用一些統計框架，他們直觀地告訴你有多少人用你的應用。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 以及你本身的後端。可是強烈推薦你使用現有的服務，好比下面的
當你配置好後，確保你 保存了 the Xcode archive (.xcarchive) 對於每個 app 放出的版本。這個 歸檔中包含了構建的app的二進制以及調試符號(dSYM)，你須要用每一個版本特定的app把你的 Crash 報告符號化。
11、構建
構建設置
每 一個簡單的 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 () [Environment]:
MyApp (English) [Development] MyApp (German) [Development] MyApp [Testing] MyApp [Staging] MyApp [App Store]
對於大多數環境來講語言部分是沒必要要的，app 會可能會以非 Xcode 的方式安裝，好比用 TestFlight， 啓動參數會被忽略。這個狀況下，爲了測試本地化須要手動設置設備的語言。
12、部署
部署一個軟件到 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版本而且提交審覈
十3、應用內購買
當驗證一個 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
- 1. [iOS]轉：iOS最佳實踐
- 2. iOS Deep Linking 最佳實踐
- 3. 最佳實踐
- 4. iOS應用開發最佳實踐
- 5. iOS圖像最佳實踐總結
- 6. iOS 解藕、組件化最佳實踐
- 7. JAXB最佳實踐
- 8. require.js 最佳實踐
- 9. Django 最佳實踐
- 10. Dockerfile 最佳實踐
- 更多相關文章...
- • Thymeleaf項目實踐 - Thymeleaf 教程
- • XML DOM 實例 - XML DOM 教程
- • PHP Ajax 跨域問題最佳解決方案
- • TiDB 在摩拜單車在線數據業務的應用和實踐
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. [iOS]轉：iOS最佳實踐
- 2. iOS Deep Linking 最佳實踐
- 3. 最佳實踐
- 4. iOS應用開發最佳實踐
- 5. iOS圖像最佳實踐總結
- 6. iOS 解藕、組件化最佳實踐
- 7. JAXB最佳實踐
- 8. require.js 最佳實踐
- 9. Django 最佳實踐
- 10. Dockerfile 最佳實踐