iOS開發建議和技巧：第一部分

我是個熱衷於iOS平臺的開發者，最早開發iOS app是在2009年中，當時打算做一個關於荷蘭Lowlands音樂節的應用，雖然最後沒有完成，但是我學會了如何開發一款iOS App。從那開始，我想了許多值得做成應用的點子，有些還用部落格記錄下來。到了2010年，我做了一款供朋友間交流使用的論壇應用，我給它取名為‘Yert’。之後的2011年，我利用空閒時間和我的叔叔(Jos Jong)還有兄弟(Jim van Zummeren)一起合作開發了一款叫做EasyCalendar的應用，

這個應用給我們帶來了不錯的收入。在製作這款應用的過程中，我學到了很多。後來我又為Trifork開發了iOS客戶端，為The New Motion開發了Love to load應用，還有一款為GeriMedia開發的用於幫助醫生記錄自己工作時間的應用Ysis Mobile。差點忘了，還有一款iPad應用：Learn to write with Tracy，這個應用主要是用來學習如何高效的為孩子們創作有意思的故事。

釋出完這一系列的app之後我又在不同的專案上埋頭苦幹，雖然最終沒有釋出，但是每一個專案都讓我有所提高。接下來我就和下家分享一些開發iOS app的貼士&技巧，其中會涉及我最近在用的工具，一些值得推薦的framework和一些釋出app的方式。

 

IDE：AppCode

首先要推的是我認為最好的IDE：AppCode。我在我的部落格中已經很詳盡的介紹過它了，我認為它是Objective-C世界中的IntelliJ。經過兩年多的使用，我堅定不移的認為：如果開發iOS app，AppCode是最好的IDE。雖然Xcode也越來越好，但是我覺得還是不敵AppCode。到底AppCode好在哪裡，建議大家看看我之前寫的博文。而且，如果你用過IntelliJ，我估計你可以理解我所指的那種好。因為IntelliJ相較於Eclipse的那些優點，恰好就是Xcode所不及AppCode的方面。

AppCode不是Xcode的替代品，完全是增強版。使用AppCode開發的工程，在Xcode內是完全相容的，可以隨時切換到Xcode繼續開發。所以使用AppCode不存在風險可言。比如，雖然AppCode中沒有Interface Builder設計器，如果需要建立storyboard可以去Xcode，然後再切回AppCode編碼。最重要的是，如果Xcode有什麼大的更新或者針對開發語言有什麼新特性新變化，幾周之後AppCode就能將這些變化和特性整合。

依賴關係管理：CocoaPods

下面說一說依賴管理。坦白的說，和java應用開發相比，iOS需要管理的依賴關係通常不多。iOS的SDK本身所涵蓋的內容已經相當豐富。但是如果你確實需要管理一些依賴關係，那麼強烈推薦你使用CocoaPods。不只是iOS平臺，包括Mac平臺在內，CocoaPods都是一個相當受追捧的依賴管理工具。

安裝CocoaPods非常簡單，只需要在終端工具中輸入如下命令：

安裝完成後，回到所開發應用的Xcode工程目錄，在下面建立一個檔案，名稱是PodFile：

上述描述內容表示通知 CocoaPods，該工程需要引入一個針對iOS6版本的“AFNetworking”。如果所引用的framework所要求的最低iOS相容版本高於工程所設定的最低iOS相容版本，CocoaPods會給出相應的提示。

執行下面的命令會自動獲取要引用的framework並新增到工程中：

CocoaPods會基於原有的工程MyCoolProject.xcodeproj建立一個名稱為MyCoolProject.xcworkspace的workspace檔案。後續的工程維護只需要開啟workspace檔案即可，其中即包含了原有的工程檔案同時又新增了所依賴的framework。

還可以更簡單一點

AppCode最近增加了對CocoaPods的支援！可以通過AppCode來建立PodFile，完全可以拋棄終端命令了。

系統內還沒安裝CocoaPods也不要緊，AppCode可以幫忙安裝。再也不需要去命令列鼓搗“gem”了。

pods打哪來？

所有的pods都在Github：https://github.com/CocoaPods/Specs。可以fork也可以PR自己的pod。我提了幾次PR，一般在一天之內就會接受合併，有的時候幾個小時就完成了合併。

持續整合

一般java開發者都比較熟悉整合工具Jenkins。其實Jenkins也適用於Xcode工程。直接在Jenkins上安裝iOS編譯外掛即可（.hpi外掛點此下載），注意Jenkins需要執行在Mac伺服器上。

特性：

• 支援CocoaPods
• Code signing
• 打包
• 配置簡單

 

其他的整合工具：

• Xcode continuous integration，這個雖然安裝配置比較簡單，但是我發現它有一些侷限性。但是這是蘋果官方支援的整合工具。所以值得一試。
• Travis CI，這是一個可以基於Github程式碼倉庫來進行線上整合的方案，同樣支援CocoaPods，不過我還沒有用過。

釋出

在開發iOS應用的過程中，肯定是需要一些專業的測試或者是一些親朋好友來驗證應用。怎麼將應用釋出給這些人呢？除了去蘋果app store上面釋出，蘋果本身提供了其他的釋出應用的策略，比如“AD-HOC”。AD-HOC可以最多向100個裝置授權使用應用，被授權的裝置直接訪問app的所在URL即可進行下載安裝。具體來說，可以簡單的架設一個Apache伺服器，將應用安裝包ipa和必要的描述資訊整合在HTML頁面中，然後部署在伺服器上，接著就可以將相關下載頁面的連結地址釋出出來供授權的裝置下載安裝。這種方式有一點比較麻煩，就是每次想要更新ipa，都得重新部署一次。

另外，測試人員在測試的過程中可能會遇到諸如app崩潰等情形，這時候開發者最想得到的就是崩潰日誌以便輔助debug這些問題。最直接的做法是，讓測試者將裝置與itunes連結，然後從裝置裡拿到崩潰日誌，再交給開發者。即便是拿到了測試使用者的崩潰日誌，在iOS平臺，還需要藉助使用者使用的安裝包當初在編譯時所生成的dSYM檔案，才能還原崩潰日誌的堆疊資訊。

總結一下具體的流程和步驟：

• 將應用釋出給測試者
• 收集崩潰日誌
• 記得儲存dSYM檔案

TestFlight

現在有線上服務來替代以上的複雜流程。我最初使用的是TestFlight

• 支援iOS和安卓
• 將測試人員分組，例如不同組的人負責不同的app
• 為開發者提供了便利的桌面客戶端來上傳 IPA和dSYM檔案
• 提供SDK來自動化上傳崩潰日誌並且能夠對其進行分析
• 提供了一種機制，使得測試人員可以在應用內進行直接反饋
• 完全免費

當然，通過一段時間的使用，還是發現了一些TestFlight的缺陷：崩潰日誌不是很可靠，有時候在終端查不到已經生成的崩潰日誌。另外，TestFlight網站也比較複雜，尤其是想要註冊成為測試者的話，整個註冊流程很麻煩。

HockeyApp

最近，我開始使用HockyApp服務。雖然名字聽起來怪怪的，但是處理起釋出和崩潰日誌非常不錯且更簡單。下面是我總結的HockyApp優於TestFlight的地方：

• 擁有我所知道的所有的TestFlight的功能
• 應用一旦崩潰就會生成日誌
• 會自動詢問使用者是否傳送崩潰日誌
• 會將崩潰日誌按照型別和頻率進行分組
• 雖不免費但不貴（5美元一個月，使用上限5個app）

綜上所述，個人HockyApp。

後續：

本文重點推介了一些iOS開發可以用到的比較好的工具，後續的文章中，我會介紹一些framework中值得推介的程式碼。稍後奉上。