欢迎到专业群（ uni-app 官方技术交流群 1 ） 咨询，群中有相关专业的管理员和群友。

感谢您的反馈。针对您提交的 Bug，官方人员评审意见如下：

1. Bug 反馈内容完整性分析

• BUG 描述：描述较为清晰，明确指出了在上传 IPA 到应用市场时触发 ITMS-90714 校验错误，官方人员可以看懂。
• 代码示例：缺失。由于该问题属于云打包与苹果应用市场校验环节的异常，通常不强制要求提供代码示例，但建议补充 manifest.json 中 App-iOS 相关配置截图，以便排查是否为某些权限或模块配置导致。
• 复现步骤：过于简略，仅写了“打包”。建议补充具体的打包方式（如：传统打包/安全打包）、使用的证书类型以及上传 IPA 所使用的工具（如：Transporter 版本或命令行工具）。
• 预期结果与实际结果：预期结果合理，实际结果符合报错信息描述，未发现误报迹象。
• 分类信息：包含了开发环境、HBuilderX 版本、手机系统及机型等信息，相对完整。
• 附件说明：系统限制我无法识别附件内容，请勿依赖附件提供关键信息，需在正文中详细描述。

2. Bug 是否成立及处理建议

结合知识库与社区历史反馈，该问题在近期其他开发者使用云打包上传 iOS 应用市场时也有出现（参考问答1、参考问答2）。由于苹果 App Store 的校验规则随系统更新日趋严格，此类校验失败通常与打包环境、原生插件或苹果侧的校验机制变动有关。

建议您尝试以下排查与解决方向：

1. 确认并更新上传工具：请确保您使用的 Mac 端 Transporter 工具已更新至 App Store 提供的最新版本，旧版工具可能存在兼容性校验问题。
2. 排查原生插件：根据社区反馈，部分 iOS 原生插件（如某些扫码、支付类插件）可能存在包含 Bitcode 或架构不全的情况，导致苹果判定二进制文件损坏。建议您检查 manifest.json 中是否勾选了原生插件，尝试暂时移除可疑插件后重新打包上传，以确认是否为插件导致。
3. 切换打包方式：在云打包界面，尝试切换“传统打包”与“安全打包”方式，重新生成 IPA 并上传测试。
4. 关注 SDK 版本要求：当前您的 HBuilderX 版本为 5.26，其云端打包环境对应的 iOS SDK 版本较高（查看云端打包环境）。请确认您的应用配置与苹果最新提审要求是否匹配。

如果上述步骤仍无法解决，建议您前往 DCloud 问答社区 发帖，并附上 manifest.json 的 App 相关配置及完整的打包日志，以便官方进一步排查。

使用开发证书打包后是否可以正常运行？
提供下提交appstore的安装包，我们验证确认下。

我也是同样的问题，我是MacOS 13.7.8，我用的Transporter。

楼主这个问题解决没？官方有没有回复

我解决了，办法就是 android 走 Mpaas-Scan-Module，打包 ios 走 uni 自带的 scan 扫码

这个是提示词

uni-app Android / iOS 原生插件差异化打包修复任务（方案 B 专用）

一、任务背景

当前项目是传统 uni-app 应用，使用 HBuilderX 进行 App 云打包，支持 Android、iOS 和 iPadOS。

项目集成了支付宝 mPaaS 原生扫码插件：

• 插件标识：Mpaas-Scan
• 模块名称：Mpaas-Scan-Module
• 原生类：MPScanModule
• 代理类：MPScanProxy
• 相关 SDK：TBScanSDK

具体配置名称以当前项目源码为准。

当前 iOS IPA 上传 Apple Transporter 时出现：

ASSET_SPI validation failed  
The app contains one or more corrupted binaries.  
Rebuild the app and resubmit.  

Error Code: 10  
Asset Type: ASSET_SPI  
State: FAILED

之前已经尝试通过修改：

"platforms": "Android"

限制插件的打包平台，但实际测试无效。

重要：方案 A 已经失败，禁止再次尝试通过修改 __plugin_info__.platforms 解决本问题。

本次任务直接执行方案 B：通过构建前的配置转换，控制 Android 和 iOS 实际集成的原生插件。

二、核心目标

Android

1. 完整保留 mPaaS 原生扫码插件。
2. 保留原有扫码逻辑、接口和回调。
3. 保留原生插件所需的权限和配置。
4. 保证 Android APK/AAB 可以正常构建。
5. 不破坏现有 Android 扫码功能。

iOS

1. 从实际参与云打包的 manifest.json 中彻底移除 mPaaS 插件配置。
2. 不向云打包服务提交该插件的选择信息。
3. 新生成的 IPA 不得包含该插件专属原生代码或 SDK。
4. 不影响其他原生插件。
5. 不影响 iOS / iPadOS 正常启动和运行。
6. 确保移除插件后，业务代码不会调用不存在的原生模块。

工程

1. Android 和 iOS 使用同一个 uni-app 工程。
2. 不需要长期维护两个独立项目。
3. Android / iOS 配置可以快速切换。
4. 配置切换可恢复、可验证、幂等。
5. 不覆盖用户尚未保存的修改。
6. 支持 HBuilderX 原有云打包流程。
7. 自动化处理尽可能简单。

三、第一阶段：检查当前工程

先读取项目，不得直接猜测配置文件结构。

检查：

• manifest.json
• package.json
• nativeplugins/
• uni_modules/
• 现有构建脚本
• 项目类型及 Vue 版本
• HBuilderX 云打包配置
• Git 工作区状态

全局搜索：

Mpaas-Scan  
Mpaas-Scan-Module  
MPScanModule  
MPScanProxy  
TBScanSDK  
mpaas  
requireNativePlugin  
nativePlugins

重点定位 manifest.json 中的：

app-plus.nativePlugins

在常规 uni-app 项目中，原生插件配置位于此对象内，而不是顶层 nativePlugins。

实际以项目配置为准。

分析该对象中所有插件，明确目标插件的真实配置键名。

不得删除其他插件。

四、第二阶段：实现动态配置切换

本任务不再尝试平台声明方案，必须实现真实的插件配置移除机制。

4.1 推荐架构

尽可能保留现有目录结构。

可以采用：

project/  
├── manifest.json  
├── scripts/  
│   ├── prepare-build.js  
│   ├── check-build.js  
│   └── restore-build.js  
├── package.json  
└── ...

允许根据真实项目调整文件名和目录。

推荐使用“单一配置来源 + 自动转换”的方式，避免长期维护两份完整 manifest 导致配置漂移。

4.2 Android 配置处理

执行 Android 准备命令后：

1. 确保目标插件完整存在于 app-plus.nativePlugins。
2. 保留原始插件版本、参数及授权信息。
3. 不改变其他原生插件配置。
4. 不改变 Android 包名及签名配置。
5. 对原有配置进行结构校验。
6. 输出明确的平台准备状态。

预期：

npm run prepare:android

输出类似：

Platform: Android  
mPaaS plugin: ENABLED  
Other native plugins: PRESERVED  
Manifest validation: PASSED  
Ready for HBuilderX Android packaging

4.3 iOS 配置处理

执行 iOS 准备命令后：

1. 从 app-plus.nativePlugins 中删除目标插件对应的完整对象。
2. 不是修改 platforms。
3. 不是仅仅修改业务代码。
4. 不是在运行时隐藏插件。
5. 不能保留能够重新触发该插件集成的配置。
6. 其他原生插件必须完整保留。
7. 不应修改无关权限、版本号和证书配置。

预期：

npm run prepare:ios

输出类似：

Platform: iOS  
mPaaS plugin: REMOVED  
Other native plugins: PRESERVED  
Manifest validation: PASSED  
Ready for HBuilderX iOS packaging

4.4 配置恢复

实现：

npm run build:restore

用于恢复完整插件配置。

恢复机制必须满足：

• 保留原有配置。
• 不重复添加插件。
• 不覆盖执行脚本后由用户新增的修改。
• 有冲突时停止并报告。
• 支持重复执行。
• 配置异常时不能静默覆盖。

重要：不能在 iOS 云打包任务读取配置之前自动恢复 Android 配置。

对于 HBuilderX 手动云打包，推荐在打包任务提交并确认使用正确配置后，再根据实际流程恢复。

4.5 配置检查

实现：

npm run build:check

并允许指定检查目标平台：

npm run build:check -- --platform ios  
npm run build:check -- --platform android

iOS 检查：

• 目标原生插件不存在。
• 其他插件没有被删除。
• 配置文件格式正确。
• 不存在其他路径重新引入该插件。
• 检查构建前实际生效的配置。

Android 检查：

• mPaaS 插件存在。
• 原有插件参数完整。
• 原生插件注册配置合法。
• 其他插件保持完整。

平台配置不符合预期时应立即返回非零退出码。

五、第三阶段：配置转换可靠性

5.1 JSON 处理

uni-app 的 manifest.json 可能包含注释。

根据实际文件格式，正确处理 JSON、JSONC 或 JSON5。

不允许直接使用简单字符串替换删除插件。

不允许通过全局正则删除整个插件配置块。

必须保证 JSON 的对象结构正确。

优先采用局部结构编辑，尽可能保留原有注释、缩进、顺序和格式。

5.2 文件安全

实现：

• 原子写入。
• 执行前校验。
• 必要的备份机制。
• 文件内容校验。
• 平台参数校验。
• 异常退出保护。
• 防止重复操作导致配置漂移。

不能因为脚本异常导致 manifest.json 变为空文件或不完整文件。

脚本不能删除与目标插件无关的文件。

5.3 防止配置污染

特别处理以下情况：

1. iOS 配置生成后再次执行 iOS 准备命令。
2. iOS 配置生成后切换 Android。
3. Android 配置生成后切换 iOS。
4. 连续多次打包不同平台。
5. HBuilderX 可视化界面重新保存 manifest。
6. 用户在两次打包之间修改其他配置。
7. Git 工作区存在未提交修改。
8. 打包失败后恢复原有配置。

不得因为当前配置已经处于 iOS 状态，就将缺少插件的配置误认为完整的 Android 配置来源。

六、第四阶段：处理业务代码

查找当前所有 mPaaS 调用。

重点检查：

uni.requireNativePlugin('Mpaas-Scan-Module')

需要保证：

Android

继续调用现有 mPaaS 接口。

不修改现有扫码结果处理逻辑，除非为了修复明确问题。

iOS

不能调用不存在的 mPaaS 原生模块。

如果 iOS 需要扫码：

• 优先检查项目已有的 iOS 扫码实现。
• 必要时采用 uni.scanCode()。
• 保持现有业务接口和回调语义。
• 正确处理扫码取消、失败和权限拒绝。

如果 iOS 不需要扫码：

• 按照原有需求隐藏或禁用入口。
• 不添加无意义的替代功能。

传统 uni-app 的普通 JS/Vue 文件中，不得错误依赖 APP-ANDROID / APP-IOS 条件编译来完成平台隔离。

使用项目实际支持的平台识别方式。

尤其需要避免在共享模块顶层无条件初始化 Android 原生插件。

不要为了该任务大规模重构扫码业务。

七、第五阶段：HBuilderX 云打包适配

本项目使用 HBuilderX 云打包。

必须确保配置切换结果真正被云打包使用。

检查：

1. manifest.json 是否位于正确项目根目录。
2. HBuilderX 是否读取最新修改。
3. HBuilderX 图形配置界面是否重新写入插件。
4. 云打包提交时是否使用正确插件列表。
5. 是否存在旧构建缓存。
6. 是否使用自定义基座。
7. 是否有其他插件配置文件覆盖 manifest。
8. 是否需要重新保存或重新打开配置界面。

禁止假设 npm 脚本会在 HBuilderX 云打包之前自动执行。

最终必须提供明确操作流程：

Android

准备 Android 配置  
    ↓  
检查插件完整  
    ↓  
HBuilderX 云打包 Android  
    ↓  
生成 APK/AAB

iOS

准备 iOS 配置  
    ↓  
检查 mPaaS 已移除  
    ↓  
HBuilderX 云打包 iOS  
    ↓  
生成 IPA  
    ↓  
检查 IPA  
    ↓  
Transporter 上传验证

如果构建工具无法可靠实现全自动提交，则采用“脚本自动准备 + HBuilderX 手动云打包”的方式。

不得使用未经证实的 HBuilderX 自动化接口。

八、第六阶段：验证 IPA 是否真正移除了插件

这是本次任务最重要的验收步骤。

如果可以访问新生成的 IPA，必须执行静态检查。

检查目标：

Mpaas-Scan  
Mpaas-Scan-Module  
MPScanModule  
MPScanProxy  
TBScanSDK

至少检查：

1. IPA 结构与 ZIP 完整性。
2. Payload/*.app/Info.plist。
3. dcloud_uniplugins 注册信息。
4. 主程序 Mach-O 可执行文件。
5. Frameworks。
6. 动态库依赖。
7. 插件特有原生 SDK。
8. 可用符号信息和二进制字符串。
9. 代码签名和包结构。

检查工具可以包括：

unzip  
plutil  
strings  
otool  
lipo  
codesign

检查规则：

• Info.plist 不存在 mPaaS 插件注册。
• 主程序不包含已确认的目标插件特有原生实现。
• 不存在只属于该插件的 Framework。
• 不存在目标插件的专属 SDK 链接依赖。
• 不存在其他已确认的插件集成残留。

不要仅凭 Info.plist 没有插件名称就断言已经完全移除。

同样，不能只根据字符串匹配就判断整个插件仍然存在；需要结合符号、依赖关系及原生文件综合分析。

如果当前环境没有新 IPA，生成可以在 macOS 本地运行的检查脚本，并明确注明尚未完成实包验证。

九、第七阶段：自动化测试

编写必要的测试用例。

至少验证：

1. Android 配置保留 mPaaS。
2. iOS 配置删除 mPaaS。
3. 其他原生插件不变。
4. 配置切换可以重复执行。
5. Android → iOS → Android 切换正常。
6. 不会丢失用户新修改的配置。
7. 配置解析错误时安全退出。
8. 缺少目标插件时处理正确。
9. 插件 ID 不符合预期时不误删。
10. 备份和恢复正常。
11. 不会打印配置中的敏感信息。
12. iOS 业务代码不会调用不存在的原生插件。

不需要为了这些测试引入大型测试框架。

十、第八阶段：Code Review

实现完成后，检查：

• 是否遗漏目标插件配置。
• 是否仍然依赖已经失败的方案 A。
• 是否删除了其他原生插件。
• 是否存在重复的平台处理逻辑。
• 是否存在配置覆盖风险。
• 是否存在文件读写异常。
• 是否有未经验证的自动化流程。
• 是否影响 Android 正常打包。
• 是否影响 iOS 正常启动。
• 是否存在不必要的依赖。
• 是否存在重复代码或复杂实现。
• 是否在不安全时机恢复了插件配置。

对于发现的明确问题，直接修复并重新运行相关测试。

不得在有明确失败项时宣称任务已完成。

十一、最终交付要求

直接修改当前项目，提交完整可用的本地实现。

至少交付：

1. 平台配置切换脚本。
2. 配置检查机制。
3. 配置恢复机制。
4. 必要的扫码业务兼容处理。
5. 自动化测试。
6. 简洁的使用文档。
7. 完整的修改和验证报告。

最终必须输出以下表格：

对于未实际执行的项目，必须标记为“未验证”。

还需输出：

• 修改的文件。
• 实际执行的命令。
• 测试结果。
• HBuilderX 云打包操作步骤。
• IPA 验证结果。
• 剩余风险与阻塞项。

十二、执行规则

1. 不再尝试方案 A。
2. 必须实现方案 B。
3. 先检查实际源码再修改。
4. 优先复用现有构建工具和脚本。
5. 不能使用简单正则替换删除 JSON 对象。
6. 必须保护现有未提交修改。
7. 不能覆盖其他原生插件配置。
8. 不得擅自修改应用标识、证书和版本信息。
9. 不允许修改无关业务模块。
10. 不允许擅自升级依赖。
11. 不允许删除用户的签名文件或其他资源。
12. 不允许只通过运行时平台判断实现原生插件排除。
13. 不允许将配置检查通过等同于 IPA 验证通过。
14. 不允许将 IPA 静态验证通过等同于 Apple Transporter 验证通过。
15. 如果新 IPA 仍出现错误码 10，要继续独立排查其他二进制问题，不能直接认为插件排除方案失败。
16. 未经授权，不得执行正式发布、Git Push 或破坏性操作。

十三、成功标准

最终实现：

Android 打包时，mPaaS 原生扫码插件完整保留。

iOS 打包时，mPaaS 插件配置从实际构建输入中移除，新 IPA 不包含该插件及专属原生 SDK。

两个平台共用同一套 uni-app 源码，支持自动切换配置，且不破坏现有业务。

十四、开始执行

现在直接检查当前工作区并实施方案 B。

不需要再解释方案 A，也不需要重新讨论已经确认无效的平台声明配置。

按照以下顺序执行：

项目扫描 → 确认插件配置位置 → 设计安全切换机制 → 修改代码 → 添加校验 → 运行测试 → Code Review → 修复问题 → 输出结果。

目标是提供真正可以长期维护的差异化原生插件打包机制，而不仅仅是一次性的手动删除操作。