使用Xcode创建framework的一些使用笔记

最近由于业务的拓展，准备开始开发Mac上产品，之前为IOS版本的产品设计过一套framework[创建你自己的Framework](http://www.cocoachina.com/ios/20150127/11022.html) 所以现在需要原先IOS上使用到的核心SDK进行升级移植。于是开始对原先代码繁琐的重构和移植工作，深切感受到一个良好的设计对一个项目的重要性。

一、平台无关性
对于一些核心的业务功能、如与后台服务器交互、认证的流程的设计需要考虑到普适性，比如针对IOS开发的SDK/framework，最初的目的只是为了IOS开发的便利，使用到了一些IOS平台的特性或第三方库，可到了需要移植到Mac上时，原先的代码的使用价值就变低，需要进行大量的代码重构工作。将核心业务去平台化。
二、UI与业务分离
拿到IOS版本的SDK后，简单查看发现最初的开发只是为了实现功能，将所有的业务交织在viewController中，与界面UI深度耦合，坏处显而易见：viewController臃肿不堪、大量代码冗余(不同UI界面相同的业务流程又是一遍重写)、调试bug困难重重。

对于目前发现的问题开始对原先的业务进行重新设计开发，首先将核心业务功能进行封装，其次使用封装的核心业务对SDK中的UI交互进行二次开发和封装。将核心业务功能分离封装，去平台化，方便业务的移植，不同系统下只需要对UI交互进行针对性开发即可。
三、framework开发与demo验证的实时同步
framework/SDK开发时，直接将SDK的xcode项目丢入demo的xcode项目中进行开发与验证，但是对于UI交互开发就存在一些不便，需要及时将SDK中修改过的资源文件(打包在bundle中)及时更换到demo下，才能看到最新的设计效果，但有时候难免忘记。昨天就出现一次，修改过了SDK一个xib界面，重新运行demo却看不到预想的效果，花了2、3个小时去找问题，查看了各个环节，才最后发现是bundle未及时更新。于是想到了以前看过一个郭冬临的小品，用勺子尝汤的咸淡，喝着同一勺子里的汤，却一直觉得汤不够味道，不断往汤里加盐。

  其实这是一个简单的问题，但是有时候却恰恰容易被忽略，需要写了一段见到sh命令，实时更新bundle资源：1.将原先的bundle删除；2.将最新编译出的bundle文件拷贝到demo路径下

rm -rf ../xxxFramerowkDemo/xxxFramerowk/xxxBundle.bundle
cp -r "$TARGET_BUILD_DIR/xxxBundle.bundle" "${SRCROOT}/xxxBundle.bundle"
mv xxxBundle.bundle ../xxxFramerowkDemo/xxxFramerowk