楼主偏激了，写一两句实在的介绍语，不算过分的。

@ydhydh 我说的就是这个意思:)
CoreData有些重，不喜欢

@myrual
@alexrezit
@PrideChung
刚学的两个中文术语，我是指Reflection/Introspection，详见：
http://www.mirageapps.com/whats-new/articles/introspection-reflection-and-swizzling-in-objective-c

Model的例子，可以看看这个（需要你手写每个Model的类，这样才有compile time的checking）：
https://github.com/MugunthKumar/MKFoundation

@notedit
补充一下，上面我说的第四种方案，是最“酷”的方案。很多时候，这种方式非常方便（尤其是维护阶段）。
但它最大的问题就是不直观，而且对工程师水平要求较高（大概比例是每100个Objective-C工程师，20个听说过这种方法，敢碰的不到5个，真正用好的能有一个就不错了）。

楼主既然练手，就都试试，没坏处。

@notedit
iOS的开发要设计先行，先把UI、交互、体验设计好。
如何请求数据，如何设计数据层是之后的事情。

关于代码结构：
一般来说数据层只负责获取数据，UIController是负责交互行为的，视图一般使用标准控件或者第三方组件这些可重用的组件，很少直接写UIView。

关于数据层内部的结构：
猜楼主是做网络应用吧。一般api请求返回的都是json/plist这些结构化的数据。
几种思路(由易至难)：
一、直接使用NSDictionary/NSArray（稍复杂的产品不推荐）
二、无Model相关的类，完全在api request的callback里面更新UI部分（限制太多了，写到后面经常发现搞不定）
三、自己使用NSObject定义一套同构的类来表示数据（好处：编译器的类型检查；坏处：写一堆代码）
四、使用ObjC Runtime，利用反射/自省的机制，动态生成property（好处：少写很多无聊的代码；坏处：运行时才发现property存在问题）

我倾向的方案是三；如果Model太复杂，建议写一个脚本，根据api的规则，编译期自动生成Objective-C的Model类；

PS: @Livid推荐的Parse，做做原型还好，挺方便的。这种平台会把服务器端绑死，而且第三方的SDK能少则少。App不是Web，bug上线了就是上线了；审核至少要7天吧...

@ergatea MongoDB可以根据数据量作cap

@lushnis
Drapache 怎么绑自己的域名？CNAME不行么？

同 @alexrezit
其实proj没问题，说明很可能不是版本的问题。4.5.2我也遇到过，清了derived data就ok了

@luyiyuan129 重启后好了，用mac都用傻掉了...

@luyiyuan129 是哦，我1年没重启过了

@falamche 一直在那里了，App Store里又没有可以更新的

@mtglichking 我也不知道怎么搞的，反正恢复不了了，图标是透明的，只有一个虚线，删除无效

跟一个移动广告平台咨询业务，对方在德国，说我工作努力。说了10多分钟英文，对方最后说你会说中文么？惊了，中文说了5分钟，weibo互粉，发现是妹纸。

感觉好复杂，还是Markdown简单。
rst表格挺不错的。

@Livid Markdown会有新标准么？

@aq82997289 每日还是每月？独立IP么？

@Livid 你们做VPS了？有官网地址么？

选任何一样做好就ok了。先解决可行性的问题，再解决选择的问题。很多时候根本没得选的。

PS: 做老板就那么好么？费心费神，搞不好还一场空从头再来。

@SURVIVOR 什么是内销？IAP?
App Store每个月的市场情况都不一样。不要以现在的眼光看过去，也不要反过来。

@Livid 肉身翻了么？