蘋果開發——向App Store提交應用

標籤：android   des   blog   code   tar   ext   

原地址：http://zengwu3915.blog.163.com/blog/static/2783489720137410539278/

完成一個app應用後，肯定是要提交的，下面聊一下關於向App Store提交的一些問題。
我們都知道蘋果審核的過程就像是在“黑箱”操作，但這並不妨礙你為這個審核過程做一些事先的準備。蘋果的App Store審核指南已經告訴你哪些是允許的，哪些是不允許的。當你第一次提交你的應用到蘋果的時候，這是一個令人興奮而但又傷腦筋的過程。即使再有經驗的開發人員也會措手不及，畢竟這事不像寫代碼每天都幹。
1.你的應用已經準備好了嗎？

Step1.測試
寫完最後一行代碼或者執行完最後一個功能並不意味著你的App已經完成了，你是否讓你的應用在多個裝置上進行測試了？你的應用是否有記憶體泄露的問題？你的應用程式是否總是崩潰？這幾年，iOS裝置市場規模增長迅猛，你必須保證你的應用已經在儘可能多的裝置上通過測試。常見的問題比如你是否在iPhone 5的4寸螢幕到iPad Mini的7.9寸螢幕上都通過了測試。

iOS模擬器非常有用，但它是在Mac上啟動並執行，記憶體和處理能力要比你口袋中的手機強大很多，一款iPhone 3GS和iPhone 5的效能差別更不用多說。作為iOS開發人員，你可不能冒著風險長期使用一款過時的iOS裝置來建立和維護App，即便App可以在老的iOS裝置上很好地運行，但不代表也可以在新裝置上跑的順暢。

蘋果的審核是封閉的，但能減少不完善的效能表現給使用者帶來的糟糕體檢。如果你的應用時常崩潰，或者啟動後不久運行速遞變得緩慢遲滯，那在向App Store提交之前你還有不少工作要做。即便蘋果審核人員不能發現App存在的問題，但使用者會發現。如果使用者體驗很差，那麼使用者會給你的差評或者低分，進一步影響到應用的銷售和下載。

Step2.規則和指南
就像我前面所說的，蘋果為開發人員提供了很多文檔資料，開發人員尤其要注意iOS人機互動指南和App Store審核指南，不過不少開發人員沒有精力或者難以靜下心來認真研讀這些文檔，那麼你的應用將會因為這些文檔中列出的要求而被一再拒絕。

再退一步說，即便你沒有研讀iOS人機互動指南和App Store審核指南，但開發人員也要知道大家常說的那些規則，如下我列出了一些你的應用應該和不應該做的事情。

你的應用：
不能崩潰
不能使用私人API，
不能複製原生app的功能，
應該使用IAP（應用內付費）金融交易
不能在使用者不知情的情況下使用相機或者麥克風
應該使用有著作權的圖片

這些只是上邊所說的文檔內容中很小的一部分。iOS人機互動指南和App Store審核指南內容更多是非常瑣碎的。但有的小地方你也許會不經意的違反。比如，在蘋果使用啟用自家地圖之前，MapKit framework使用的是Google地圖，使用者也非常清楚Google的logo會放在每張地圖的左下角，如果你的應用的使用者介面覆蓋了Google的logo，那麼蘋果就會拒絕你的應用。雖然這非常瑣碎，但也是不少開發人員經常“犯錯誤”的地方。

2.預先準備

在你開始將程式提交到App Store之前，你需要有一個App ID，一個有效發布認證，以及一個有效Provisioning profile。下面來看看它們各自的作用。

Step 1: App ID（應用ID）
App ID是識別不同應用程式的唯一標示符。每個app都需要一個App ID或者app標識。目前有兩種類型的App標識：一個是精確的App ID（explicit App ID），一個是萬用字元App ID（wildcard App ID）。使用萬用字元的App ID可以用來構建和安裝多個程式。儘管萬用字元App ID非常方便，但是一個精確的App ID也是需要的，尤其是當App使用iCloud 或者使用其他iOS功能的時候，比如Game Center、Push Notifications或者IAP。

如果你不確定什麼樣的App ID適合你的項目，我推薦你讀下蘋果關於這一主題的文檔：Technical Note QA1713。

Step 2: Distribution Certificate(發布認證)
iOS應用都有一個安全性憑證用於驗證開發人員身份和簽名。為了可以向App Store提交app，你需要建立一個iOS provisioning profile 。首先需要建立一個distribution certificate（發布認證），過程類似於建立一個development certificate（開發認證）。如果你已經在實體裝置上測試你的App，那麼你對建立development certificate就已經很熟悉了。

如果對此不熟悉，我建議你讀下蘋果關於signing certificates和provisioning profiles的詳細指導。

Step 3: Provisioning Profile(設定檔)
一旦你建立了App ID和distribution certificate，你可以建立一個iOS provisioning profile以方便在App Store中銷售你的App。不過，你不能使用和ad hoc distribution相同的provisioning profile。你需要為App Store分銷建立一個單獨的provisioning profile，如果你使用萬用字元App ID，那麼你的多個app就可以使用相同的provisioning profile。

Step 4: Build Settings(產生設定)
配置App ID、distribution certificate 和provisioning profile已經完成，是時候配置Xcode中target的build settings了。在Xcode Project  Navigator的targets列表中選擇一個target，開啟頂部的Build Settings選項，然後更新一下Code Signing來跟之前建立的distribution provisioning profile相匹配。最近添加的provisioning profiles有時候不會立馬就在build settings的Code Signing中看到，重啟一下Xcode就可以解決這個問題。

 Step 5: Deployment Target(部署目標)

非常有必要說下deployment target，Xcode中每個target都有一個deployment target，它可以指出app可以啟動並執行最小版本。不過，一旦應用在App Store中生效，再去修改deployment target，你要考慮到一定後果。如果你在更新app的時候提高了deployment target，但是已經購買應用的使用者並沒有遇到新的deployment target，那麼應用就不能在使用者的行動裝置上運行。如果使用者通過iTunes (不是裝置)下載了一個更新過的app，然後替代了裝置上原先的版本，最後卻發現新版本不能在裝置上運行，這確實是個問題。

對此我有兩個方法
(1) 當你決定提高現有app的deployment target時，要在新版本的版本注釋中進行說明。如果你提前告知使用者，那麼至少有一點，你已經儘力阻止問題的發生了。

(2) 對於一款新app，我經常會把deployment target設定為最近發布的系統版本。因為新iOS版本發布後，滲透率的增長速度是令人難以置信的。很多人認為提高deployment target會失去大部分市場，這個說法並不準確，比如iOS 6，iOS 6發布後一個月，超過60%的裝置已經進行了更新。但對Android而言，就是另外一回事了，Android使用者並不會像iOS使用者那樣熱衷於更新作業系統版本。

3. Assets(資源套件)

Step 1: Icons(表徵圖)
Icon是App中不可分割的一部分，你要確保icon尺寸不會出現差錯。
iTunes Artwork: 1024px x 1024px (required)
iPad/iPad Mini: 72px x 72px and 114px x 114px (required)
iPhone/iPod Touch: 57px x 57px and 114px x 114px (required)
Search Icon: 29px x 29px and 58px x 58px (optional)
Settings Application: 50px x 50px and 100px x 100px (optional)

Step 2: 螢幕
螢幕的作用不言而喻，你可以為每個app上傳5張，雖然至少需要上傳一張，可能很少有人會只上傳一張圖片。另外，你還需要分別為iPhone/iPod Touch和iPad/iPad Mini準備不同的螢幕。這也是不小的工作量，但卻能展示應用的另一面。Shiny Development開發的一款售價6.99美元的Mac軟體Status Magic可以為你節省不少時間。Status Magic可以幫你把狀態列放在的正確位置。

螢幕和icon是應用給使用者的第一感覺，直接關係到使用者會不會購買。不過，你所上傳的螢幕也不一定非得是實際的，看看Where’s My Water? 可以通過使用此策略，更具吸引力和說服力。

Step 3: 中繼資料
在提交應用之前，要管理好app的中繼資料，包括1應用程式名稱、2版本號碼、3主要類別，4簡潔的描述，5關鍵詞，6.支援URL。如果你需要更新應用，你還要提供新增加的版本內容。

如果你的應用需要註冊嗎，你還得向蘋果提供一個測試賬戶或者demo賬戶，這樣審核人員就能很快進入app，而不用再註冊帳號。

4. 提交準備

Xcode 4以後，開發人員提交應用的過程就簡單多了，可以直接使用Xcode進行提交。首先在iTunes Connect中建立app，訪問iTunes Connect，使用你的iOS開發人員帳號登陸，點擊右邊的“Manage Your Apps”，點擊左上方的“Add New App”，選擇“iOS App”，然後完成表格。 

 

   

 

 

Step 1: 完成基本資料

出現在App Store中App的名字要做到獨一無二, 這個名字可以不同於主畫面icon下邊的名字，不過推薦使用相同的名字。

SKU Number是一個用來識別app的特殊字元串，這個也只是自己看看，沒有什麼太大的意義。一般使用app的bundle identifier。最下邊是app的Bundle ID，你可以從下來菜單中選擇萬用字元App ID或者準確的App ID。這個必須和發布的應用程式的plist中的Bundle ID一樣

 

 

 

Step 2:價格和有效性

下一步，確定app的價格和有效性。蘋果已經確定好了價格梯度，所以你不需要分別選擇各個國家中app售價，你只需要指定在哪個國家的市集出售即可。在App Store顯示這款應用之後，這一過程中填的資訊還可以被修改，也就是說你可以更改價格，並且不需要提交或更新。

 

 Step 3: 中繼資料

 

我們已經說過中繼資料了，不過還沒有說應用程式評等。根據應用的內容和功能，蘋果會給應用一定評級，比如很多應用是4+，500px是17+。除了告訴使用者app的內容和功能，也可以讓孩子的父母放心。

如果你的應用等級跟內容不符合，蘋果也會拒絕你的應用。

 

 

 Step 4: 準備上傳二進位檔案

 

提交完app的中繼資料後，你會看到關於app的一些摘要資訊，你應該在提交之前看看app的版本。點擊“View Details”按鈕，再點擊右上方的“Ready to Upload Binary”。然後系統會問你一個或幾個關於app的問題，完成後，你會看到提示資訊，告訴你準備上傳二進位檔案。app的狀態就變成“Waiting for Upload”。

 

  5. 上傳二進位檔案為了上傳程式，需要為程式建立一個archive。你只能在一台真實裝置上建立一個archive。如果你在active scheme中選擇了iOS Simulator，那麼在Xcode的Product菜單中Archive選項是灰色不可選的。串連一台iOS裝置到Mac機器上，然後在active scheme中選擇這台裝置，然後選擇Xcode中Product菜單裡面的Archive。 如果一切正常的話，現在你會獲得一個archive，並且Xcode的Organizer會自動開啟，並顯示出剛剛產生的archive。在列表中選中archive，然後點擊右邊的“Distribute”按鈕。在顯示出來的畫面中，選擇“Submit to the iOS App Store”。然後輸入你的iOS開發人員帳號進行認證。接著選擇Application 和Code Signing Identity。應用程式的二進位檔案會上傳到蘋果的伺服器中——在這個過程中，你的程式同樣需要被驗證。如果在驗證過程中遇到了錯誤，程式的提交流程就會失敗。驗證處理非常有用，如果程式中有一些錯誤，蘋果的 App Store評審團會告訴你具體原因。 使用Xcode對應用程式進行歸檔（Archiving） 把應用提交至iOS App Store 鍵入iOS開發人員
 選擇Application和Code Signing Identity
 驗證失敗會有錯誤提示
 6.等待上傳完成後，app狀態就變成“Waiting for Review”了。 總結新應用提交過程比較長，只是更新的話就很快了。如果你的應用需要進行本地化就會涉及到很多，因為一些基本的資訊都需要進行本地化。不過，這個過程是值得的，畢竟更多的使用者會給你帶來更多下載和利潤。 本文參考： http://www.cocoachina.com/newbie/tutorial/2013/0508/6155.html