iOS Framework修改PRODUCT_NAME报Objective C模块未找到错误咨询

开发自定义Framework时配置了两个共用同一套代码库的Target，二者仅最低部署目标版本存在差异：

• MyFramework-Debug：Product Name为MyFramework_Debug，Product Module Name为MyFramework
• MyFramework-Release：Product Name为MyFramework，Product Module Name为MyFramework

项目为C++/Objective-C/Swift混合代码架构，已将部分Objective-C头文件导入伞头文件MyFramework.h中，且已配置Defines Modules = YES。

编译运行Release Target时流程正常无报错，但编译Debug Target时会抛出如下错误：

<unknown>:0: error: underlying Objective-C module 'MyFramework' not found

反复核查构建目录，确认自动生成的modulemap文件中存在有效Module配置，伞头文件也已正确导出到MyFramework_Debug.framework/Headers路径下，且两个Target的PRODUCT_MODULE_NAME配置完全一致。按照原有预期，仅修改PRODUCT_NAME只会变更Framework产物的文件夹名称，不会影响代码层面的模块识别。

备注：若将Debug Target的Product Name也设置为MyFramework，构建全项目时会提示“multiple commands generate file”错误，是两个Target向同一路径写入Framework产物引发的冲突。

配置双Target的原因 #

项目使用Metal技术，大部分Metal类不支持iOS13以下版本的模拟器，但开发的Framework最低部署目标为iOS11，因此做如下拆分：

• MyFramework-Debug：支持真机+模拟器，最低系统版本要求iOS 13
• MyFramework-Release：仅支持真机，最低系统版本要求iOS 11

对接的客户端App最低支持版本为iOS11，该配置可保证团队其他开发者在模拟器运行App时，无需额外处理Framework的版本兼容问题。

报错的核心原因是Clang模块的默认加载规则和当前配置不匹配，和代码逻辑无关：
Clang搜索Framework模块时，默认要求声明的模块名必须和.framework包的文件夹名完全一致。虽然两个Target的PRODUCT_MODULE_NAME都设为MyFramework，但Debug Target生成的Framework文件夹名是MyFramework_Debug.framework，Clang按模块名MyFramework搜索时，只会匹配名为MyFramework.framework的包，自然找不到对应模块——哪怕包内的modulemap、伞头文件完全符合规范也会触发报错。Release Target的产物名和模块名完全一致，因此可以正常编译。

原有认知中「仅修改PRODUCT_NAME不影响模块识别」的判断不符合Clang的实际加载逻辑，这是问题的核心诱因，遗漏的配置点本质上是没有适配Clang的模块匹配规则。

按落地成本和维护性排序，可选择以下方案修复： #

方案1：迁移到XCFramework（最推荐） #

这是苹果官方针对多架构、多版本兼容场景推出的标准方案，完全不需要维护两个同代码库的Target：

1. 分别编译两个版本的Framework切片：iOS11仅真机版本、iOS13真机+模拟器版本
2. 执行命令将两个切片打包为XCFramework：

xcodebuild -create-xcframework \
-framework <path/to/ios11/MyFramework.framework> \
-framework <path/to/ios13/MyFramework.framework> \
-output <path/to/output/MyFramework.xcframework>

3. 客户端集成XCFramework后，Xcode会自动在模拟器运行时选取iOS13版本切片、真机发布时选取iOS11版本切片，无需手动切换Target，也不会出现产物重名冲突、模块找不到的问题。

方案2：保留双Target，自定义模块映射配置 #

如果暂时不想迁移到XCFramework，可以通过手动指定modulemap的方式绕开Clang的默认匹配规则：

1. 不依赖Xcode自动生成modulemap，手动创建modulemap文件放在项目目录下，内容如下：

framework module MyFramework {
  umbrella header "MyFramework.h"
  export *
  module * { export * }
}

2. 在两个Target的Build Settings中找到Module Map File配置项，填入上述手动创建的modulemap文件的相对路径
3. 为Debug Target单独添加OTHER_SWIFT_FLAGS配置，新增参数-fmodule-map-file=$(CONFIGURATION_BUILD_DIR)/MyFramework_Debug.framework/Modules/module.modulemap，强制编译器读取指定路径的模块映射
4. 检查所有Public头文件的Target Membership，确保Debug Target被正确勾选，避免构建时头文件缺失。

方案3：分离双Target的构建输出路径 #

如果希望两个Target的Product Name都保持为MyFramework，从根源上匹配Clang的模块命名规则，可以修改构建路径避免产物冲突：

1. 选中Debug Target，在Build Settings中找到CONFIGURATION_BUILD_DIR配置项，修改为独立的输出路径，比如$(BUILD_DIR)/Debug-simulator/MyFramework
2. Release Target保持默认构建输出路径即可
3. 调整客户端项目的Framework Search Paths，针对模拟器构建配置添加Debug产物路径、针对真机Release配置添加Release产物路径
   该方案下两个Target的MyFramework.framework产物会输出到完全不同的目录，不会触发「multiple commands generate file」冲突，同时因为产物名和模块名一致，Clang可以正常识别模块。

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