xcode5 arm64 armv7 armv7s arm6
"高大上" 名词整理
MVVM With ReactiveCocoa
利用NSProxy实现消息转发-模块化的网络接口层设计-原创
使用methodSignatureForSelector与forwardInvocation实现消息转发
在给程序添加消息转发功能以前，必须覆盖两个方法，即methodSignatureForSelector:和forwardInvocation:。methodSignatureForSelector:的作用在于为另一个类实现的消息创建一个有效的方法签名，必须实现，并且返回不为空的methodSignature，否则会crash。
forwardInvocation:将选择器转发给一个真正实现了该消息的对象。
作为开发者，你觉得Apple该如何改进开发者工具呢？
iOS项目的目录结构-原创
MVC，MVP 和 MVVM 的图示 阮一峰
iOS 开发中的争议（二） xib 纯代码
iOS项目架构 - 规范
所创建项目的文件夹目录结构和Xcode中的虚拟Group文件夹的结构须一致，便于代码文件的维护。
胖Model瘦Controller。
大部分业务逻辑放在Model中做，Controller只负责Model和View的调配。Model和View不可直接沟通。 Model->Controller，使用NSNotification传递消息。View->Controller采用Targt- action或者Delegate传递消息。ViewController终于从上千行代码的困境中解放出来了！
所有属性都使用Getter and Setter
不要在viewDidLoad里面初始化view然后再add，这样代码就很难看。在viewDidload里面只做addSubview的事情，然后在viewWillAppear里面做布局的事情
多target的选用，意在实现最大化重用代码。其经典情景是有多个类似的App，界面设计与业务逻辑有许多相似之处，仅仅有少数不同的业务逻辑，只需要在打包时将不同的配置文件打包好，就可以形成一个个不同的客户端。
移动App架构设计
iOS 多种架构
腾讯，研发团队的组织和管理
某家厂商对性能监控管理的内容 关于其加入锚点之后，针对程序性能分析的定位，是非常可视化和直观的
REST简介 good 例子
Web的技术架构包括了四个基石：
- URI
- HTTP
- HyperText（除了HTML外，也可以是带有超链接的XML或JSON）
- MIME
Rest Web Application开发
应用中的所有事物都被抽象为资源
Objective-C中的+initialize和+load
bridge
xcode4.5不再支持armv6即:iOS4.3.3以下的系统.
iOS应用架构谈 view层的组织和调用方案 good
软件开发的核心
电力项目需要复杂系统的目的，一是为了确保安全（Safety），二是为了提高效率（Efficiency）。
安全和效率的平衡，是所有工程技术的核心。
美团大众点评合并：背后技术力量的对比回顾
PayPal 高级工程总监：读完这 100 篇文献，就能成大数据高手
旧工程适配iOS 6和iPhone 5
前端开发工程师如何在新的一年里提升自己
iOS 应用架构谈 动态部署方案
web app一般是创业初期会重点考虑的方案，因为迭代非常快，而且创业初期的主要目标是需要验证模式的正确性，并不在于提供非常好的用户体验，只需要完成闭环 即可。早年facebook曾经尝试过这种方案，最后因为用户体验的问题而宣布放弃。所以这个方案只能作为过渡方案，或者当App不可用时，作为降级方案 使用。
Hybrid方案更加适合跟本地资源交互不是很多，然后主要以内容展示为主的App。在天猫App中，大量地采用了JS Bridge的方式来让H5跟Native做交互，因为天猫App是一个以内容展示为主的App，且营销活动多，周期短，比较适合Hybrid。
由于React-Native框架中，因为View的展示和View的事件响应分属于不同的端，展示部分的描述在JS端，响应事件的监听和描述都在 Native端，通过Native转发给JS端。所以，从做动态部署的角度上讲，React-Native只能动态部署新View，不能动态部署新 View对应的事件。当然，React-Native本身提供了很多基础组件，然而这个问题仍然还是会限制动态部署的灵活性。因为我们在动态部署的时候， 大部分情况下是希望View和事件响应一起改变的。
另外一个问题就在于，View的原型需要从Native中取，这个问题相较于上面一个问题倒是显得不那么严重，只是以后某个页面需要添加某个复杂的view的时候，需要从现有的组件中拼装罢了。
所以，React-Native事实上解决的是如何不使用Objc/Swift来写iOS App的View的问题，对于如何通过不发版来给已发版的App更新功能这样的问题，帮助有限。
lua的解决方案在一定程度上解决了动态部署的问题。实际操作时，一般不使用它来做新功能的动态部署，主要还是用于修复bug时代码的动态部署。实际操作时需要注意的另外一点是，真的很容易改错，尤其是你那个方法特别长的时候，所以改了之后要彻底回归测试一次。
在对app打补丁的方案中，目前我更倾向于使用JSPatch的方案，在能够完成Lua做到的所有事情的同时，还不用编一个JS解释器进去，而且会javascript的人比会lua的人多，技术储备比较好做。
其实JSON描述的View比React-Native的View有个好处就在于对于这个View而言，不需要本地也有一套对应的View，它可以依据 JSON的描述来自己生成。然而对于事件的处理是它的硬伤，所以JSON描述View的方案，一般比较适用于换肤，或者固定事件不同样式的View，比如 贴纸。
为什么不是React-Native或其他方案？
首先针对React-Native来做解释，前 面已经分析到，React-Native有一个比较大的局限在于View需要本地提供。假设有一个页面的组件是跑马灯，如果本地没有对应的View，使用 React-Native就显得很麻烦。然而同样的情况下，HTML5能够很好地实现这样的需求。这里存在一个这样的取舍在性能和动态部署View及事件 之间，选择哪一个？
我更加倾向于能够动态部署View和事件，至少后者是能够完成需求的，性能再好，难以完成需求其实没什么意义。然而对于 HTML5的Hybrid和纯HTML5的web app之间，也存在一个相同的取舍，但是还要额外考虑一个新的问题，纯HTML5能够使用到的设备提供的功能相对有限，JSBridge能够将部分设备的 功能以Native API的方式交付给页面，因此在考虑这个问题之后，选择HTML5的Hybrid方案就显得理所应当了。
在诸多Hybrid方案中，除了JSBridge之外，其它的方案都显得相对过于沉重，对于动态部署来说，其实需要补充的软肋就是提供本地设备的功能，其它的反而显得较为累赘。
我开发了CTDynamicLibKit这个库来解决动态库的调用问题，其实原先的打算是拿动态库做动态部署的，不过我用@念纪 的个人App把这个功能塞进去之后，发现苹果还是能审核通过的，但是下载下来的动态库是无法加载的。
主要原因是因为签名无法通过。因为Distribution的App只能加载相同证书打包的framework。在in house和develop模式下，可以使用相同证书既打包App又打包framework，所以测试的时候没有问题。但是在正式的 distribution下，这种做法是行不通的。
所以就目前看来，基于动态库的动态部署方案是没办法做到的。
微信内置浏览器的JsAPI(WeixinJSBridge续)