導讀：這是來自新加坡的 iOS 開發者 Kent Nguyen 發表在1月底的一篇博文。這篇吐槽文在 iOS 開發圈子裡流傳甚廣，從原文150多個評論就可見一斑，現翻譯如下。
讓我們開門見山吧：做一個iPhone應用需要花多少錢？
就是這個最常見的問題，我的很多朋友（大多是些西裝革履的商務人士），還有我那些個對技術一知半解的客戶們，他們都問過我這個的問題。通常，我會先給出一個大致的報價，這個報價並沒有細緻到需要籤合同確認每一個功能點的地步。即便是這樣，每當的我報價一出口，對方都毫無例外的給驚著了（當然不是因為便宜）。
說實話，我沒有獅子大開口。看看StackOverflow上這個著名的帖子吧，討論的是開發Twitterific這樣一款應用需要多少錢，後來討論範圍擴充套件到開發一個iOS應用的合理費用範圍。雖然這個帖子是在2008年釋出的，而帖子的最佳答案是由一名來自Twitteriffic的開發人員於2010年回答的，但是時至今日，帖子裡面討論的數字仍然是很靠譜的，而且我預計到2012年底依然有效。而我的報價和這個帖子裡面的數字比起來，簡直是小巫見大巫了。
現在的趨勢是，什麼公司什麼業務都想搞個iOS客戶端，並且這種趨勢在2012年看似依然火爆。所以我想起來寫這篇博文，我想說一下開發一個iOS應用會碰到的各種細節問題和橫生的變數，藉此解釋為什麼iOS應用開發成本這麼貴。如果你在考慮搞一個iOS應用，而你本身是搞業務而不是做技術的，如果你目前正在招標或者僅僅是想了解一下，那我這篇博會對你有幫助。當然，我說的東西並不侷限於iOS應用開發，對Android、Windows Phone或者是Blackberry（如果RIM還能活的話）等移動應用平臺基本上也是適用的。
（伯樂線上配圖）
開發之前需要仔細考慮的
別做拍腦瓜的決策，在開工之前你需要考慮的比你想象的要多。我通常會幫助或者指導客戶把以下幾個要素都過一遍：
一：和客戶談他們的移動應用，最讓我吃驚的是他們從來沒有想過支撐一個iPhone應用執行，背後需要涉及到的方方面面。他們想象中的iPhone是獨立存在於這個宇宙的，是如此的簡單，以至於他們要我很快就給出一個專案預算報價，而不用討論諸多細節。我問他們：“你們是否考慮過後臺伺服器的事情？你們的應用需要和後端伺服器做資料通訊？” 什麼，聽不懂？好吧，我用地球人的語言再把這個問題講 一遍：“你們的應用不是需要使用者註冊嘛，你們考慮過把使用者的資料存放在哪裡了嗎？我們需要一個地方去儲存這些以後會用到的資料。” 第一次碰到這樣的客戶時，哥簡直就怒了。後來我發現這不是客戶的錯：我是搞程式設計的，CS架構對我來說就像吃飯睡覺一樣是不假思索的東西，而我的客戶盡是些高富帥，他們懂個毛CS架構！
所以，如果你不大懂技術，那請仔細聽我說：如果你想做的移動應用需要使用者註冊和登入，或者你想隨時控制移動應用的一些輸出，甚至是你僅僅是需要一個使用者反饋意見調查表這麼簡單的功能，那麼，你得搞一臺後端伺服器。
二：好了，現在你知道你需要一臺後端伺服器。同時你還需要想辦法讓你的iOS應用和你的伺服器能夠對話，就是相互間接收資料什麼的。不，這個問題不是簡答靠什麼標準的即插即用的東東就能解決的，不是你們想象的那樣！所有的東西都需要定製化開發，這就好比發明一門語言：你希望你的伺服器和你的應用之間能夠通過一種語言溝通，但是你不希望其他人聽得懂這門語言。
用行話說這就是制定伺服器端API介面，或簡稱API。這些API應該在開發iPhone客戶端之前就到位了。為什麼？因為你必須先規定好一門語言的單詞和語法，然後才能用這門語言說話吧！？好了，這就帶出了第三點—如何開發這些API。
三：API的成功定製是專案成功的一半（反之亦然），所以千萬不要掉以輕心。你要考慮你的業務資料模型、業務流程、呼叫業務需要提供的引數、特定事件發生時資料間該如何互動等等。簡單來說，我們要做的就是開發一個網站，上面跑著你的業務流程，只不過這個網站的所有執行結果都不是通過網頁形式展現出來，而是呈現在一行行的文字和數字中。舉個例子：一個登入成功的反饋頁面僅僅包含YES一個單詞。
iPhone應用需要訪問這些預先定義好的介面，並且按預定義格式提供必要的輸入（比如使用者名稱和密碼），然後要對伺服器端的反饋（YES或者NO）做出解析處理。所以，沒有什麼移動應用能夠自動的含有使用者註冊和登入功能。
伺服器端開發需要考慮的問題太多了：選擇伺服器，選擇用什麼語言開發，主機放在哪裡才能增加訪問速度，等等，這裡我就不展開了。如果這一切對你來說很陌生，那麼你最好去問問團隊裡的技術負責人，或者乾脆讓開發人員做決策。
四: 所以，關於伺服器端API，你或者讓自己的技術團隊把它開發好，再將完善的API文件交給iPhone應用開發人員；或者你支付iPhone應用開發人員額外的報酬來搞定這些。你找的iPhone應用開發人員可能會伺服器端開發也可能不會。如果他會的話，我建議最好讓他也同時負責伺服器端開發，因為他最清楚iPhone應用中需要哪些伺服器端API。
如果你的伺服器端API已經存在了，那麼除了向iPhone應用開發人員提供相關文件之外，你還要考慮讓他能夠便捷的同伺服器開發團隊溝通，因為大多數情況下，iPhone應用需要在已有API基礎上增加一些新的介面。
現在我們來看看iPhone應用開發本身
扯了大半天，我們終於開始談iPhone應用開發本身了。一般來說，iOS平臺上做所有事情都不能隨心所欲。你最好在開發人員寫程式碼之前把所有的需求都確認好好。這和開發網站不一樣，按照實現簽訂的合同開發iOS應用，開發過程中對需求變更的容納度可能很低：
使用者介面：無論你打算採用iOS標準介面還是自定義元素，在開發開始前一定要確認清楚，因為應用的程式架構是根據介面和使用者使用流程來設計的。一個很好的例子就是在介面底部使用了iOS標準的標籤欄（Tab Bar），此後如果你想讓標籤欄裡面的圖示變成彩色的，這個程式碼改動量可沒你想象的那麼小！
程式碼之間的耦合：如果是開發網站，你可以隨意的新增一個頁面或者一處連結。做iOS應用就沒有那麼簡單了，很多東西一開始都要設計好，後期的一處改動會牽連很多東西，具體原因是你無法理解的。iOS應用的程式碼寫好之後，再改動行不行？行！但必須小心。 這就像設計電路板一樣， 如果你不小心把那根線搭錯了，整塊電路板就會不工作。有人說架構優良的程式可以有很高的延展性，那純屬紙上談兵。在About螢幕上新增一個電子郵件按鈕可能只需要幾行程式碼的工作量，而新增一個轉發到新浪微薄的按鈕（譯者注：原文是新增一個Facebook Like）就完全不是那麼簡單的事兒了！
讓一個iPhone應用同時也支援iPad：如果要評選最坑爹“需求變更”，那麼這個絕對是當之無愧的。理由很簡單：支援iPad根本不是TMD什麼附加功能！iPad應用基本上都比iPhone應用來得要複雜，介面設計和使用者體驗也大不一樣。我問你，製造一輛電動自行車，然後把它改裝成一部燒汽油的摩托車，這能是一回事兒嗎！？電動自行車跟摩托車看起來是很像，但是製造它們完全是兩碼事。
拿廣受歡迎的Facebook官方應用來說，它的iPhone和iPad版本看似相似，實際使用者操作流程完全不同。不僅僅是介面上的不同會帶來額外的工作，對後臺伺服器API的需求也可能不一樣。拿我熟悉的一個應用Denso來說（我熟悉它因為這是我開發的），它的iPad版本比iPhone多了幾個功能，這些都需要額外的伺服器端API來支援。記住，iPhone和iPad應用的使用者體驗需求是完全不一樣的。
準備好開始了嗎？
希望此文能夠幫助你和你的團隊瞭解移動應用開發幕後的方方面面。除非你們要做一個像計算器那麼簡單的單機應用，否則你們很難用極低的成本搞定。綜上所述，如果你覺得外包成本太高，那你只好招人自己開發。
當然，如果你決定了要外包移動應用開發，那麼我還要提醒一點：公司政治。如果你是在一家大公司或者有著嚴格制度的機構裡面幹活，那麼幫助合同開發者搞定那些個規章制度上的繁文縟節，對你來說是非常重要的一項工作，必要的時候甚至可以做一些政策上的變通。 我同幾個大型企業客戶接觸過，當我要求看他們的伺服器端資料介面的時候，他們流露出很不安的表情。我想這或許是因為他們受制於公司規定而不能透露資訊，這無可厚非；或者他們還沒有想好這種情況下該如何操作；或者他們的品牌制度蛋疼到需要在移動應用的每個螢幕上都擺著公司logo！最終我沒有和這樣的企業客戶合作，因為我無法想象如果有一天我需要增加一些伺服器端API介面的話，和他們的規章和流程折騰，那將會是多麼悲劇的事情。
PS：開發移動應用很耗費時間，你最好有耐心。