做SDK开发很久了，这里备注下日常开发中的几个常规项。对于有经验的开发都来说，这篇文章没有任何意义。如果你不小心走进来了，请出门右转，这里就不招待了。
关于库
iOS平台现在提供两种形式的SDK库类型：静态库、动态库。在实际使用过程中却存在三种形式的库：静态库、动态库、以动态库形式存在的静态库。
制式
这个概念是相对于终端机型来说的，每一种型号的iPhone/iPad都会对应一种型号的CPU，而CPU又对应着不几种arm架构。具体来说有armv6/armv7/armv7s/armv64这样几种。当然armv6/armv7/armv7s的机型现今市面上已经不常见了，armv64是最主流的机型了。制式在Xcode中对应着一组配置项：Architectures。一般来说，开发者在XCODE中使用其默认配置即可，如下图所示：
制式的作用是告诉编译器以机型的具体架构对代码作一定的优化，使应用在机器上运行的更为流畅。因此可执行文件必然包含了所有市面上主流机型的cpu制式。但这对于开发者来说就比较痛苦了，我们平台开发测试时只会用到一种制式，犯不着编译所有的CPU制式，浪费时间啊。因此xcode提供了上图中Build Active Architecture Only选项，在Debug模式下只编译一种当前测试机型的制式，在Release模式下编译所有配置的制式。
开发者可以使用lipo命令来查看、合并、提取制式，参考如下：
这里备注下i386/x86_64是模拟器的制式，因为这里我们的主体是SDK，因此模拟器制式还是需要提供给其它开发者使用的。
静态库
最常见的SDK库类型，最终生成的库文件后缀名为.a类型。静态库实际上是编译生成的.o文件的合集，我们可以通过ar/nm命令来提取/查看具体的.o文件信息：
动态库
库文件后缀为.framework。苹果在IOS8开放了动态库功能，但并不允许开发者使用其来实现动态更新的功能。因此该形态的库在业界并没有得到广泛的使用。
伪动态库
该方案实质上是静态库，但它使用了动态库的文件组织形式。具体点讲是这样的：静态库有一个缺点，整个SDK提供给开发者的是一个文件夹，开发者需要将文件夹中的.h/.a等代码文件、.bundle资源文件引用到工程，这样很容易导致错误，而动态库就不存在这个问题，开发者可以直接将framework导入工作即可。这样便有了伪动态库这个将二者结合起来的方案。具体实现方案这里就不在介绍。
关于包体大小
相信开发SDK的程序猿都会碰到缩小包体大小的需求。私下里我觉得这个需求不可理喻，但上级要求、市场上有些商务同事无脑的宣传，没办法，想办法达成吧！
最无脑最简单的方法是合并类了，这样就会少生成一个.o文件，这样就能够减小一个文件的大小。当然这也不太现实，合并太多了，会导致代码可读性变差。
可以修改Xcode的Generate Debug Symbols选项，将Release版本的值修改为NO。这样可以将生成的.a文件的大小缩减1/3左右。
关于资源文件
SDK开发一般会将所有的资源文件打包成一个bundle文件后和.a/.h文件一同发布。如果SDK只用到了图片音乐等资源文件，可以使用文件夹直接改后缀名的方式生成bundle。如果用到nib、storyboard等布局文件，用上面那种方式生成bundle会导致布局文件找不到。
布局文件必须编译成nib文件后才能够使用，因此开发者可以在workspace创建一个制作mac平台bundle文件的target，在target中引用所有要使用到的资源与布局文件。
使用Bundle文件中图片资源时一般会用到imageWithContentsOfFile接口，该接口要求传入图片的完整路径，因此如果你的图片带有@2x/@3x这样的机型适配后缀时，请完整的带上后缀。
关于打包
SDK的整个打包流程通常不会发生太大的变动，比较适合自动化。Github上也有较多的自动打包开源项目，基本原理都是通过xcodebuild命令并依赖于当前xcode工程中的target来编译生成最终文件。
关于CocoaPods
CocoaPods能够大幅地减小开发者接入SDK的学习成本，也是如今业界比较主流的第三方开源方案的集成方案。申请个代码托管账号，放心使用它作为你的SDK发布方式吧。
关于前景
现今移动开发受前端挤压比较严重，尤其是移动App开发，从长远来看，被前端取代可能近在眼前了。而SDK一般是面对企业的服务，一般来说会较少的涉及到界面，因此相对来说受到的影响会比较少一点。但危机依然存在着，抓紧时间，提高自己的竞争力方为上策。
