为何Xcode中Static Library与Framework的相关设置容易令人困惑

首先你的基础认知是准确的：

Framework = Library + Bundle
Static = Linking at build time
Dynamic = Linking at run time

仅补充一点：此处的Bundle为苹果生态下符合Framework规范的结构化目录，会统一封装库对应的头文件、资源文件、签名、多架构切片等配套内容。

问题1：为什么Xcode没有「Dynamic Library」创建选项？ #

这个限制是针对iOS平台的，macOS平台的Xcode模板里本身就提供了Dynamic Library创建入口，两者的差异来自苹果的平台管控策略：

• macOS允许第三方发布系统级共享动态库，所以需要单独的动态库模板生成.dylib文件。
• iOS不允许App使用自定义的系统级动态库，所有开发者自定义的动态库必须内嵌到App包内部，作为Embedded Framework存在，所以苹果直接把iOS端的自定义动态库能力整合到了Framework模板中，你只要把Framework的Mach-O Type配置项改为Dynamic Library，得到的就是iOS平台可用的自定义动态库，不需要单独提供模板。

问题2：既然已经可以静态链接Framework，为什么还需要「Static Library」？ #

静态Framework确实等价于静态库+符合规范的资源/头文件Bundle封装，但Static Library模板依然有不可替代的适用场景：

• 轻量需求更高效：如果你封装的能力只有纯代码逻辑，不需要附带资源、多架构拆分等复杂配置，直接用Static Library生成.a文件的编译速度更快，也不需要维护Framework的复杂目录结构，引入项目时的配置成本更低。
• 老项目兼容性：iOS 8才正式支持自定义静态Framework，在此之前的三方库几乎都是以.a静态库的形式分发，大量老项目的构建链路已经适配了静态库的引入规则，不需要调整构建配置就能直接兼容，改造成本更低。
• 资源管控更灵活：静态Framework会默认把资源打包进自身的Bundle中，多依赖场景下很容易出现资源重复打包的问题；静态库本身不处理资源打包，你可以自行控制资源的合并逻辑，方便多组件复用同一份资源，减少安装包体积。
• 跨平台适配成本低：.a是符合POSIX标准的通用静态库格式，如果你的库需要同时适配iOS、嵌入式等多个平台，静态库的跨平台适配成本远低于苹果独有的Framework格式。

内容的提问来源于stack exchange，提问作者user626776