IOS 错误“嵌入的二进制文件没有使用与父应用程序相同的证书进行签名”

这些是我在 IOS 应用程序开发中的第一步,我正面临着一些我无法解决的问题。

error: Embedded binary is not signed with the same certificate as the parent app. Verify the embedded binary target's code sign settings match the parent app's.


Embedded Binary Signing Certificate:    Not Code Signed
Parent App Signing Certificate:         iPhone Developer: Emil Adz (9QNEF95395)

我不明白,什么是 嵌入式二进制签名证书

我在这里用同样的错误检查了这些问题,但是没有一个与这里提出的问题(没有密码签署)相关。

我试图从苹果开发者会员中心撤销我的证书并请求另一个证书,但问题仍然存在。

有人知道如何修复吗?

72123 次浏览

嵌入式二进制文件指的是与应用程序一起部署的 小工具

在您的情况下,您没有使用任何签名标识对小部件进行签名(因为您的错误显示“ Not Code Signed”)。

若要解决此问题,请转到 Project 文件,找到小部件的目标,并在“生成设置”选项卡下找到“代码签名标识”值。选择与主应用程序目标相同的代码签名标识。

当您想要发布配置文件 专门为你的小部件设计的时,还需要创建和配置它。

当我在开发者门户中的所有应用程序 ID 上没有正确设置应用程序组时,我得到了这个错误。因此,应用程序中的应用程序组不能正常工作,扩展的二进制文件或 Watchkit 应用程序无法签名。

有时候 Stackoverflow 上的解决方案都不管用,

解决方案

  1. 确保 MainApp 和 EmbeddedApp 中的签名(调试)、签名(发布)和启用功能的任何部分都没有红色标记/问题
  2. 确保在登录/系统密钥链下安装了证书和供应配置文件。

enter image description here

  1. 确保证书的 永远不会设置为 永远相信。访问权限必须保持为 使用系统默认值

enter image description here

奇怪的是,为了修复这个错误,我不得不从项目中删除 products 文件夹。然后 Xcode 崩溃了,在重新开放后,像魔法一样工作!

当您的 Today 扩展的 部署目标比父应用程序更新时,也会显示此错误。一定是一样的。

我将 iOS 应用程序设置为10.0,并添加了 Today 扩展,该扩展自动设置为11.4作为最新版本。这导致出现错误。只需将扩展目标的 Deployment 目标更改为10.0即可解决问题。

在向主应用程序 Target 添加 Copy Files Build Stage 之后,我得到了这个错误。

复制文件
目的地: Absolute Path
路径: /Applications
档案: MyApp.app

我第一次运行这个应用程序时就成功了。

在随后的运行中,Xcode 开始抱怨证书不匹配。

删除“复制文件”生成阶段修复了证书不匹配问题。我仍在寻找一种方法来复制文件没有错误。

同样的问题链接:

似乎这个问题出现在 xcode 10中,并且解决方案与前面提到的不同。

我能够通过设置 Build 来修复(或者说绕过)错误 从系统到遗留系统(经文件 > 工作区设置)

另一个有趣的注意事项是,签名错误不会 如果我正在构建一个实际的设备(即在更改 方法生成系统时才会发生 模拟器,只能在 Xcode 10 beta 3,4和5上使用。

链接到原始线程: https://forums.developer.apple.com/thread/105537

当我迁移到 Xcode 10时,我遇到了这个问题,通过更新 注意目标 to 的“ Build Settings”> “ Valid Architecture”中的体系结构,我设法解决了这个问题

$(ARCHS _ STANDARD)

这个帖子帮了我很大的忙: https://forums.developer.apple.com/thread/107563

在我的代码中出现另一个编译时错误时,我得到了这个错误。

我的新目标以前从未建成过。

所以我想先修复这个错误。但结果是,修复其他错误使 Xcode 能够构建目标并修复其他错误本身。

快速5。简单的方法在我的情况下检查这个屏幕截图我完成了

enter image description here

检查你是否有更多的目标,如一个信号或其他,并检查如果你有同一个团队的主要目标。

我在尝试用 Xcode 11构建 WatchOS 应用程序时遇到了这个错误——我尝试了本文和其他 SO 文章中的各种建议,但最终成功的方法是将 Xcode 转换为使用遗留的构建系统。

转到: 文件 | 项目(或工作区)设置 | 生成系统

并选择遗留建设系统

假设

  • 我正在使用的应用程序名为 TestApp(为了保护隐私)
  • 下面的步骤在 Xcode 11.1中进行了测试
  • 我用来编译的方案是 临时的
  • 应用程序有 推送通知功能

问题

在我的案例中,这个问题是由两个目标签署之间的 差异引起的,问题在于:

  • TestApp目标(即错误中的目标称为 父应用程序签名证书)
  • 通知服务扩展目标(即错误中的目标称为 嵌入式二进制签名证书)。

targets

决心

在我的 即时支援计划中,在 TestApp 目标下,我禁用了自动签名,因为我想指定供应配置文件和证书。

我遵循的步骤是:

  1. Signing & Capabilities -> AdHoc -> Signing (section)
    1. 从选定的自动管理签名下删除刻度
    2. 选择了我想要使用的配置文件

signing&capabilities

  1. Build Settings -> Signing (section)
    1. Code Signing Identity下,为 AdHocAny SDK选择我想要使用的证书
    2. Code Signing Style -> AdHoc下,选择 手册
    3. Provisioning Profile -> AdHoc下,选择我想要使用的供应配置文件(即与步骤1.2相同)

build settings

之所以引发错误,是因为我没有对 通知服务扩展目标应用相同的设置(它仍然使用自动签名,因此使用另一个证书)。一旦我为这个目标重复了上面的步骤,错误就消失了。

我希望它可以帮助某人,因为这个错误把我逼疯了!

检查您的密钥链访问过期证书没有删除,这就是为什么它显示一个错误。

XCode 12.5

在我的情况下,我遵循 Shakeel Ahmed 的答案,但是我也需要在 Pod 文件上做这个修改。enter image description here

你可在此找到更多资料

enter image description here

检查您的排除体系结构

我在 Unity.iPhone 项目中也遇到过同样的问题。 我们嵌入了一个标签扩展的目标,我们与应用程序一起发布。

Stickers 扩展目标是抱怨代码签名设置与父应用程序不匹配的那个。

error: Embedded binary is not signed with the same certificate as the parent app. Verify the embedded binary target's code sign settings match the parent app's.


Embedded Binary Signing Certificate:    Software Signing
Parent App Signing Certificate:     Apple Distribution

这发生在标签扩展目标构建设置设置为 ARCHS _ STANDARD (arm7,arm64) ,而父应用程序设置为 arm64时。

我通过将扩展的 ARCHS 构建属性设置为 arm64来修复这个问题。

想想看,我怀疑这个输出捕获了一大堆不同的问题,只是没有在日志消息中指定任何细节。

在我的情况下,关键是删除“产品”文件夹。然后建造成功了。此外,之后我做了 git reset --hard并再次尝试,同样的成功结果。

我在遵循 SwiftUI 文档时遇到了一个问题,那就是将 iOS 应用程序与 watch OS 集成在一起。

问题是这个扩展不在同一个开发团队之下,所以当我们尝试编译它的时候它会失败。

没有关于架构的,也没有关于信任的。

解决方案: Xcode < br > 的屏幕快照

  1. 转到项目常规文件
  2. 查看侧边栏上的扩展文件夹(查看截图2)
  3. 切换到“签名和能力”选项卡
  4. 选择您的团队(需要匹配主项目的开发团队)

我有这个问题与 照片编辑扩展。我最终发现,这是由于我不寻常的项目结构。

  • 我的项目包括一个本地 Swift 包 ,其中包含了 appx (应用程序扩展)的所有源代码和资源。
  • 外接程序链接由 Swift 包创建的库。
  • 附录没有自己的源文件。“ Compile Source”构建阶段没有文件,也没有“ Copy Bundle Resources”构建阶段。

在一个干净的构建中,Xcode 构建了 apex 并成功地将其嵌入到应用程序中。

在增量构建中,即使没有对任何文件进行更改,Xcode 也会在“ ValidateMyEx.appx”步骤中失败。

原来,问题在于 Xcode 在每次构建 appx 可执行文件时都会重新链接它,即使什么都没有改变。Xcode 执行 没有然后签署新的 apex 可执行文件,除非在干净的构建过程中。

这意味着在增量构建之后,appx 可执行文件始终是无符号的,因此它永远不会与父应用程序使用相同的证书进行签名(因为 appx 根本没有签名)。

我的解决方案是向 appx 目标添加一个空文件 dummy.swift。这足以使 Xcode 只在需要时重新链接 apex,并且总是在增量构建期间链接后对 apex 进行签名。