使用静态库的好处
1，模块化，分工合作2，避免少量改动经常导致大量的重复编译连接3，也可以重用，注意不是共享使用
使用动态库的好处
1使用动态库，可以将最终可执行文件体积缩小2使用动态库，多个应用程序共享内存中得同一份库文件，节省资源3使用动态库，可以不重新编译连接可执行程序的前提下，更新动态库文件达到更新应用程序的目的。从1可以得出，将整个应用程序分模块，团队合作，进行分工，影响比较小。等其他好处，从2可以看出，其实动态库应该叫共享库，那么从这个意义上来说，苹果禁止iOS开发中使用动态库就可以理解了：因为在现在的iPhone，iPodTouch，iPad上面程序都是单进程的，也就是某一时刻只有一个进程在运行，那么你写个共享库，—-共享给谁？（你使用的时候只有你一个应用程序存在，其他的应该被挂起了，即便是可以同时多个进程运行，别人能使用你的共享库里的东西吗？你这个是给你自己的程序定制的。）—-目前苹果的AppStore不支持模块更新，无法更新某个单独文件(除非自己写一个更新机制：有自己的服务端放置最新动态库文件)至于苹果为啥禁止ios开发使用动态库我就猜到上面俩原因
深入理解iPhone静态库
在实际的编程过程中，通常会把一些公用函数制成函数库，供其它程序使用，一则提搞了代码的复用；二则提搞了核心技术的保密程度。所以在实际的项目开发中，经常会使用到函数库，函数库分为静态库和动态库两种。和多数人所熟悉的动态语言和静态语言一样，这里的所谓静态和动态是相对编译期和运行期的：静态库在程序编译时会被链接到目标代码中，程序运行时将不再需要改静态库；而动态库在程序编译时并不会被链接到目标代码中，只是在程序运行时才被载入，因为在程序运行期间还需要动态库的存在。
iPhone官方只支持静态库联编。
深入理解framework（框架，其实相当于静态框架，不是动态库）
打包framework还是一个比较重要的功能，可以用来做一下事情：（1）封装功能模块，比如有比较成熟的功能模块封装成一个包，然后以后自己或其他同事用起来比较方便。（2）封装项目，有时候会遇到这个情况，就是一家公司找了两个开发公司做两个项目，然后要求他们的项目中的一个嵌套进另一个项目，此时也可以把呗嵌套的项目打包成framework放进去，这样比较方便。
我们为什么需要框架（Framework）？
要想用一种开发者友好的方式共享库是很麻烦的。你不仅仅需要包含库本身，还要加入所有的头文件，资源等等。
苹果解决这个问题的方式是框架（framework）。基本上，这是含有固定结构并包含了引用该库时所必需的所有东西的文件夹。不幸的是，iOS禁止所有的动态库。同时，苹果也从Xcode中移除了创建静态iOS框架的功能。
Xcode仍然可以支持创建框架的功能，重启这个功能，我们需要对Xcode做一些小小的改动。
把代码封装在静态框架是被app store所允许的。尽管形式不同，本质上它仍然是一种静态库。
框架（Framework）的类别
大部分框架都是动态链接库的形式。因为只有苹果才能在iOS设备上安装动态库，所以我们无法创建这种类型的框架。
静态链接库和动态库一样，只不过它是在编译时链接二进制代码，因此使用静态库不会有动态库那样的问题（即除了苹果谁也不能在iOS上使用动态库）。
“伪”框架是通过破解Xcode的目标Bundle（使用某些脚本）来实现的。它在表面上以及使用时跟静态框架并无区别。“伪”框架项目的功能几乎和真实的框架项目没有区别（不是全部）。
“嵌入”框架是静态框架的一个包装，以便Xcode能获取框架内的资源（图片、plist、nib等）。
本次发布包括了创建静态框架和“伪”框架的模板，以及二者的“嵌入”框架。
用哪一种模板？
本次发布有两个模板，每个模板都有“强”“弱”两个类别。你可以选择最适合一种（或者两种都安装上）。
最大的不同是Xcode不能创建“真”框架，除非你安装静态框架文件xcspec在Xcode中。这真是一个遗憾（这个文件是给项目使用的，而不是框架要用的）。
简单说，你可以这样决定用哪一种模板：如果你不想修改Xcode，那么请使用“伪”框架版本如果你只是想共享二进制（不是项目），两种都可以如果你想把框架共享给不想修改Xcode的开发者，使用“伪”框架版本如果你想把框架共享给修改过Xcode的开发者，使用“真”框架版本如果你想把框架项目作为另一个项目的依赖（通过workspace或者子项目的方式），请使用“真”框架（或者“伪”框架，使用-framework——见后）如果你想在你的框架项目中加入其他静态库／框架，并把它们也链接到最终结果以便不需要单独添加到用户项目中，使用“伪”框架
“伪”框架
“伪”框架是破解的“reloacatable object file”（可重定位格式的目标文件， 保存着代码和数据，适合于和其他的目标文件连接到一起，用来创建一个可执行目标文件或者是一个可共享目标文件），，它可以让Xcode编译出类似框架的东西——其实也是一个bundle。
“伪框架”模板把整个过程分为几个步骤，用某些脚本去产生一个真正的静态框架（基于静态库而不是reloacatable object file）。而且，框架项目还是把它定义为wrapper.cfbundle类型，一种Xcode中的“二等公民”。
因此它跟“真”静态框架一样可以正常工作，但当存在依赖关系时就有麻烦了。
依赖问题
如果不使用依赖，只是创建普通的项目是没有任何问题的。但是如果使用了项目依赖（比如在workspace中），Xcode就悲剧了。当你点击“Link Binary With Libraries”下方的’+’按钮时，“伪框架”无法显示在列表中。你可以从你的“伪”框架项目的Products下面将它手动拖入，但当你编辑你的主项目时，会出现警告：
warning: skipping file ‘/somewhere/MyFramework.framework’ (unexpectedfile type ‘wrapper.cfbundle’ in Frameworks & Libraries build phase)
并伴随“伪”框架中的链接错误。
幸运的是，有个办法来解决它。你可以在”Other Linker Flags”中用”-framwork”开关手动告诉linker去使用你的框架进行链接：
-framework MyFramework
警告仍然存在，但起码能正确链接了。
添加其他的库/框架
如果你加入其他静态（不是动态）库/框架到你的“伪”框架项目中，它们将“链接”进你最终的二进制框架文件中。在“真”框架项目中，它们是纯引用，而不是链接。
你可以在项目中仅仅包含头文件而不是静态库/框架本身的方式避免这种情况（以便编译通过）。
“真”框架
“真”框架各个方面都符合“真”的标准。它是真正的静态框架，正如使用苹果在从Xcode中去除的那个功能所创建的一样。
为了能创建真正的静态框架项目，你必需在Xcode中安装一个xcspec文件。
如果你发布一个“真”框架项目（而不是编译），希望去编译这个框架的人必需也安装xcspec文件（使用本次发布的安装脚本），以便Xcode能理解目标类型。
注意：如果你正在发布完全编译的框架，而不是框架项目，最终用户并不需要安装任何东西。
我已经提交一个报告给苹果，希望他们在Xcode中更新这个文件，但那需要一点时间.OpenRadarlink here
加其他静态库/框架
如果你加入其他静态（不是动态）库/框架到你的“真”框架项目，它们只会被引用，而不会象“伪”框架一样被链接到最终的二进制文件中。
从早期版本升级即使是不成熟的尝试，也胜于胎死腹中的策略。
