动态库（Unix类似系统中以 .dylib 结尾的文件）不同于静态库（ .a 结尾），静态库会在代码编译链接后打包进二进制可执行程序。而另一种库是在运行期才会加载，注意这里是加载没有链接的过程。加载意味着程序会在需要的查找该库。这也是为什么会有一些情况，当你很开心的双击打开一个程序却告诉你缺少xx库的原因。（翻译注：用Windows同学很容易碰到缺少 xx.dll , dll 文件类似这里的 dylib 库）。不同的是，静态库会把需要的部分编译进你的app，因此用户不会遇到这么多麻烦
为什么要使用动态库呢？
是因为文件大小！ 静态库要比同等功能的动态库大很多倍，举个例子我们比较一个下 OSX 下的 SDL 库，如果你用 homebrew 安装了 SDL 它的路径在 /usr/local/Cellar/sdl2/2.0.3/lib/
有两种方式添加一个第三方动态库到Xcode target:
1）安装库到系统
2）复制库到product
1 安装库到系统
对于大多数的第三方库可用安装到系统中，路径为 /usr/local/lib 或者 /usr/lib 。如果报头文件找不到需要把头文件的路径添加到 Xcode target > Build Setting 。最后在 Xcode target -> Build Phase -> Linked Libraries and Frameworks
但是这种方法并不能方便你的用户使用app，因为需要用户自己安装库文件。对于app来说没有比这更糟糕的。
2 复制 .dylib 到Product
显而易见一个更好的使用动态库的方法应该是把 .dylib 与 app 绑定起来。 让路径相对于自己比相对于系统要好很多。
程序是如何通知系统需要哪些库呢？
由于程序是从一个二进制文件开始运行，那么这个文件是唯一能够通知系统需要哪些库的。从另一个角度来看，这个二进制文件是开发者与用户系统之间的桥梁，编译器和链接器是建造者。因此我们可以通过 OSX 提供的 otool 问问二进制文件。
假设我有一个叫 Vivi 的项目，APP是 Vivi.app ,Vivi使用了两个我的库为 ViviSwiften.framework 和 Viviinterface.framework ，他们也在 Vivi 项目下，尽管你可以双击运行APP，但是它本身并不是真正的二进制文件。执行的二进制文件在 AppName.app/Contents/MacOS/AppName 路径下。
让我们来问一下这个 Vivi 二进制文件
看上去 otool 打印出所有链接的库和他们的版本信息
有很多的内容，你看，我找到了我自己的 framworks , ViviSwiften.framework 和 ViviInterface.framework 。现在我知道了 ViviInterface.framework/Versions/A/ViviInterface 是二进制程序的framework路径（与 .app 不同， framework 的二进制文文件位于 FrameworkName.framework/Versions/A/FrameworkName ），但是 @rpath 的含义是什么？
@excutable_path @loader_path 和 @rpath 的含义是什么?
参考 OS X Man Page:dyld(1) (也可以通过 man dyld ), Build Settings中的变量@rpath,@loader path,@executable path.
这三个变量的含义如下：
1) @executable_path 总是指向product中的二进制执行文件路径， AppName.app/Contents/MacOS/AppName .
2) @loader_path 与具体的加载的库有关，比如 Vivi.app 加载 ViviSwiften.framwork ，那么 @loader_path=/path/to/ViviSwiften.framwork/Versions/A/ （翻译注：该变量代表加载的库的二进制的路径，因此不同的库会解析成不同的路径，同样也适用于其他二进制的执行文件）和 @"executable_path=/path/to/Vivi.app/Contents/MacOS"
3) @rpath 是预定义的路径，你可以在 Xcode target > Build Setting > Runpath search Path 进行设置。对于App target 经常包含 @executable_path/../Frameworks , 对于一个 framework target 常用的有 @executable_path/../Frameworks 和 @loader_path/Frameworks , 对于单元测试一般用 @executable_path/../Frameworks 和 @loader_path/../Frameworks
现在我们知道 Vivi.app 使用的是我自己创建 Viviswiften.framework 和 ViviInterface.framwork 以及一些系统的 framwork 或者 libraries ,但是没有第三方的动态库文件。 Viviswiften.framework 引用了 libSwiften.3.0.dylib , 让我们来查看一下
可以看到 ViviSwiften.framwork 用了一个第三方的动态库 libSwiften.dylib ，路径是 @loader_path/Frameworks/libSwiften.3.0.dylib
系统是如何找到这些库或者framwork的呢？（以 Vivi 为例）
1) 用户双击打开 Vivi.app
2)Vivi.app 执行 Vivi.app/Contents/MacOS/Vivi
3)查找 Vivi.app 需要的动态库
4)找到 @rpath/ViviSwiften.framework/Versions/A/ViviSwiften , 然后拼成 @executable_path/../Frameworks/.. (翻译注：原文这里是@executable_path/../Frameworks/ViviSwiften/，应该是多了一个ViviSwiften),最后拼成 Vivi.app/Contents/MacOS/Vivi/../Frameworks/ViviSwiften.framework
5)查找 Viviswiften.framwork需要的动态库
6)找到 @loader_path/Frameworks/libSwiften.3.0.dylib ，然后拼成 ViviSwiften.framework/Version/A/Frameworks/libSwiften.3.0.dylib
这些信息是如何写入二进制执行文件的呢？
我们知道这些信息是在二进制文件中，但是他们是如何写到那里的呢？是两位辛勤的构建者：编译器和链接器。 编译器会把需要的标示符传递给链接器，链接器会负值查找你告诉它需要的标示符，如果你提供的是静态库，链接器会把整个文件写入二进制文件中，如果你提供的是动态库，只有库的路径会写进二进制文件。
链接器是如何找到这些路径的呢？
不幸的是，这个路径并不是APP的开发者提供的，而是由第三方库的开发者提供的。因此你不能够让 Xcode 使用相对于你自己的项目或者自己提供路径。
我们重新看一下 ViviSwiften.framwork :
我们从第一行可以看到 ViviSwiften 自己的路径。那就是他的路径。 描述自己的路径变量是 install_name ViviSwiften.framwork 提供了正确的路径。但是是不是第三方库都会按我们想的那样提供合适的路径呢？ 答案是NO。
编译第三方库会提供什么样的路径呢？
有两种方式：
1)使用 Homebrew 或者从源码编译如（ make install ）,库的路径会如下： /usr/lib/libxxx.dylib 或 /usr/local/lib/libxx.dylib .
2)你也可通过 ./configure && make 编译源代码, 这时候库的路径没有前缀只有 libxx.dylib
但是这两种解决方法都不是我们想要的。
把 install_name 更改成需要的
OS X 提供了另一个工具叫 install_name_tool 来改变 install_name 和链接库的 install_name
最终解决策略
1)添加库到 Build Phase , 添加头文件搜索路径，保证没有编译和链接错误。
2)让 Xcode 在编译后复制 .dylib 文件到product下，添加 New Copy Files Phase 并命名为 Copy Libraries
修改 Destination 为 Framworks ，添加 .dylib 文件
修改库的 install_name(如果你导入的是第三方frame库，有时也不用修改，如果以上步骤后有错误就继续修改)，如果手动导入的第三方.dlib库，要修改
$ install_name_tool -id @loader_path/Frameworks/libSwiften.3.0.dylib libSwiften.3.0.dylib