閱讀底層庫本篇文章介紹蘋果系統iOS開發，和我八年以上的行業經驗分享，跟建議。，在給大家分享這個操作之前，小編推薦大家加一下這個群：680565220！大家遇到啥問題都會在里面交流！而且分享十年開發經驗牛人經驗分享課一整套！是個非常好的學習交流地方！也有程序員大神給大家熱心解答各種問題！很快滿員了。欲進從速哦！等大家加入學習交流基地哦關于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異常簡單，只需要在終端對象中輸入以下敕令：
Shell
1sudo gem install cocoapods
裝配完成后，回到所開辟應用的Xcode工程目次，不才面創建一個文件，稱號是PodFile：
Shell
1
2
platform:ios,"6.0"
pod'AFNetworking','2.0.2'
上述刻畫內容暗示通知 CocoaPods，該工程需要引入一個針對iOS6版本的“AFNetworking”。假定所援引的framework所懇求的最低iOS兼容版本高于工程所設置的最低iOS兼容版本，CocoaPods會給出照顧的提示。
運轉下面的敕令會主動獲得要援引的framework并添加到工程中：
Shell
1pod install
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網站也對比復雜，特別是想要注冊成為測試者的話，全數注冊流程很費事。
