让我们开门见山吧：做一个 iPhone 应用需要花多少钱？
就是这个最常见的问题，我的很多朋友（大多是些西装革履的商务人士），还有我那些个对技术一知半解的客户们，他们都问过我这个的问题。通常，我会先给出一个大致的报价，这个报价并没有细致到需要签合同确认每一个功能点的地步。即便是这样，每当的我报价一出口，对方都毫无例外的给惊着了（当然不是因为便宜）。
说实话，我没有狮子大开口。看看 * 上这个著名的帖子吧，讨论的是开发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：开发移动应用很耗费时间，你最好有耐心。
英文原文：Kent Nguyen编译：伯乐在线 – 陈远
转自:http://www.html5cn.org/article-2386-1.html
英文原文：Dear business people, an iOS app actually takes a lot of work!