iPhone 应用程序二进制文件无效

发布于 2024-07-04 01:48:17 字数 405 浏览 9 评论 0原文

我正在尝试将应用程序上传到 iPhone App Store,但从 iTunes Connect 收到以下错误消息:

您上传的二进制文件无效。 签名无效,或者不是使用 Apple 提交证书签名。


注意:原始问题的详细信息已被删除,因为此页面已变成一个存储库,其中包含有关该特定错误消息的可能原因的所有信息。

有关向 App Store 提交 iPhone 应用程序的一般信息,请参阅步骤将 iPhone 应用程序上传到 AppStore

I'm trying to upload an application to the iPhone App Store, but I get this error message from iTunes Connect:

The binary you uploaded was invalid. The signature was invalid, or it was not signed with an Apple submission certificate.


Note: The details of original question have been removed, as this page has turned into a repository for all information about possible causes of that particular error message.

For general information on submitting iPhone applications to the App Store, see Steps to upload an iPhone application to the AppStore.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(30

您的好友蓝忘机已上羡 2024-07-11 01:48:17

我遇到了同样的问题,在尝试了几件事之后 - 我从代码签名权利中删除了 .plist 权利(只是将其留空),它构建得很好并最终上传。

祝大家好运:-D

I had the same issue and after trying several things - I removed the .plist entitlements from the Code Signing Entitlements (just left it blank) and it built fine and uploaded FINALLY.

Good luck all :-D

明月松间行 2024-07-11 01:48:17

同样的问题,不同的解决方案。

就我而言,我使用 zip -r myapp.zip myapp.app 压缩文件
事实证明,zip 命令搞砸了捆绑包。 从取景器中压缩它就可以了。

Same problem, different solution.

In my case, I was compressing the file using zip -r myapp.zip myapp.app
Turns out, the zip command screwed the bundle. Compressing it from the finder made it work.

山色无中 2024-07-11 01:48:17

嗯,重复了几次步骤之后,我终于成功上传了我的应用程序。

我不知道具体是什么修复了它,但在成功尝试之前,我关闭了 Xcode 和 Firefox 并重新启动了它们。 我猜其中一个应用程序有一些不好的juju。

Well, after repeating the steps several times, I was finally successful in uploading my app.

I don't know exactly what fixed it, but prior to the successful attempt, I closed Xcode and Firefox and restarted them. I guess one of those apps had some bad juju.

燕归巢 2024-07-11 01:48:17

我也遇到了同样的问题,在构建时我注意到配置没有添加到构建中。

对我来说,修复方法是将构建设置为 iPhone 设备,就像我通常使用模拟器一样,但它不会包含配置文件...

这可能是一个菜鸟错误。 通常,您无法构建到设备,但当您进行分发时,您可以。

I had the same problem aswell, when building I noticed the provisioning wasn't added in the build.

The fix for me was to set the build to the iphone device as where I normally use the simulator, but then it won't include the provisioning profile...

This might be a noob mistake. Normally you can't build to device, but when you do it for distribution you can.

初心 2024-07-11 01:48:17

在阅读了包括上述内容在内的各种帖子后,我尝试了各种方法。 最终对我有用的是完全重新开始! 我删除了与我的应用程序关联的每个证书和配置文件。

我重新创建了新的开发证书和新的分发证书。 我再次下载了中级证书。 然后我重新创建了开发配置文件和分发配置文件。

安装三个证书(我注意到这次发行版同时具有私钥和公钥)和两个配置文件(我的发行版配置文件没有被标记为没有有效证书!)后,一切正常。

当我决定撤销所有内容并重新开始时,只花了大约 5 分钟就创建了新内容并重新安装。

I tried various things after reading various posts including those above. What finally worked for me was starting completely over! I deleted every certificate and provisioning profile associated with my app.

I recreated a new development certificate and a new distribution certificate. I downloaded the intermediate certificate again. Then I recreated both the development profile and the distribution profile.

After installing the three certificates (I noticed the distribution had both private and public keys this time) and the two provisioning profiles (my distribution profile didn't get flagged as not having a valid certificate!), everything worked.

Once I made the decision to revoke everything and just start over, it only took about 5 minutes to create the new stuff and re-install.

小清晰的声音 2024-07-11 01:48:17

这是我遇到的一个问题:我在上传之前将二进制文件添加到 Subversion。 然后比较/压缩二进制文件,包括隐藏的 .svn 目录,这会扰乱代码签名。

Here's an issue I ran into: I added the binary to Subversion before uploading. Comparessing/zipping the binary then included the hidden .svn directories, which messed up the code signing.

烦人精 2024-07-11 01:48:17

我只是想提一下,我也遇到了命令 zip 的问题
线也。 问题在于它默认处理符号链接的方式。 使用:

zip -y -r myapp.zip myapp.app

解决了这个问题。

I just wanted to mention that I too had the problem with zip from the command
line as well. The problem lies in the way it handles symlinks by default. Using:

zip -y -r myapp.zip myapp.app

Solved that problem.

我遇到了同样的问题,并以这种方式解决了它:

属性证书安装在我的开发计算机上,并且 mobileprovision.embedded 包含在分发存档中。 经过一个小时左右的谷歌搜索和挖掘,我找到了错误的根源。 在 Xcode 中,我复制了发布配置并创建了新的分发配置,然后将签名身份更改为我的分发证书。 但是,即使在 GUI 中进行了更新,项目文件也未正确更新。

如果您遇到相同的错误,请在 [ProjectName].xcodeproj 目录中查找 project.pbxproj 文件,然后在您喜欢的编辑器中将其打开。 查找“分发”部分。 我的损坏的看起来像这样:

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Developer: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Developer: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
};
name = Distribution;
};

您可以看到第二部分中的签名身份和配置文件不正确。 编辑它以匹配第一部分,重建,然后你就可以开始了。 最后一个看起来像这样:

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Distribution: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “F00D3778-32B2-4550-9FCE-1A4090344400″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
};
name = Distribution;
};

改变指南以保护无辜者

I had the same issue and solved it this way:

The property certificates were installed on my development machine and mobileprovision.embedded was included in the distribution archive. After an hour or so of Googling and digging I found the source the error. Inside Xcode I had copied the Release configuration and created a new Distribution configuration and then changed the signing identity to my distribution certificate. However, even though it was updated in the GUI the project file was not updated correctly.

If you come across the same error, look in your [ProjectName].xcodeproj directory for the project.pbxproj file and open it in your favorite editor. Look for the Distribution section. My broken one looked like this:

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Developer: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Developer: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “DB12BCA7-FE72-42CA-9C2B-612F76619788″;
};
name = Distribution;
};

You can see the signing identity and provisioning profile are incorrect in the second section. Edit it to match the first section, rebuild, and you should be good to go. The final one looked like this:

C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = “iPhone Distribution: Edward McCreary”;
“CODE_SIGN_IDENTITY[sdk=iphoneos*]” = “iPhone Distribution: Edward McCreary”;
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = “F00D3778-32B2-4550-9FCE-1A4090344400″;
“PROVISIONING_PROFILE[sdk=iphoneos*]” = “F00D3778-32B2-4550-9FCE-1A4090344400″;
};
name = Distribution;
};

guids changed to protect the innocent

贪了杯 2024-07-11 01:48:17

根据我的经验,Xcode 偶尔会对使用哪个签名证书感到困惑。 我养成了在更改代码签名设置(并进行干净构建)后退出并重新启动 Xcode 的习惯,以解决此问题。

It's been my experience that Xcode occasionally gets confused about which signing certificate to use. I got into the habit of quitting and restarting Xcode after any change to the code signing settings (and doing a clean build) to work around this problem.

妄想挽回 2024-07-11 01:48:17

看来这个问题有很多原因。 这是我的解决方案:

这适用于属于多个开发团队的任何人(例如您自己的应用程序和您的公司)。

如果您使用一组凭据构建构建并使用另一组凭据重新签名(例如,对于临时/应用程序商店分发),则必须确保构建最初是构建的,并且是在构建时使用的。 使用属于您重新签名的分发凭据所属的同一 iOS 开发团队的凭据进行签名

因此,不要使用“Indy Dev Inc”凭据进行构建,然后尝试使用“Company Inc”凭据进行部署。 确保您设置了“Company Inc”开发和分发凭据,并使用它们。

我在我的博客上发布了有关此内容的更多信息: http://omegadelta.net/2011/06/09/fiendish-ios-code-signing-invalid-binary-issue/

It seems this issue has many causes. Here's the solution to mine:

This applies to anyone who belongs to multiple development teams (e.g. your own apps, and your companies).

If you building the build with one set of credentials and re-signing it with a different one (e.g. for adhoc/appstore distribution), you must ensure that the build was originally built & signed with credentials belonging to the same iOS development team that the distribution credentials you are re-signing with belong to.

So don't build with "Indy Dev Inc" credentials then try to deploy with "Company Inc" credentials. Make sure you setup both "Company Inc" dev, and distribution credentials, and use them.

I posted more info about this on my blog: http://omegadelta.net/2011/06/09/fiendish-ios-code-signing-invalid-binary-issue/

隱形的亼 2024-07-11 01:48:17

我有一个类似的问题,但在 Monotouch 中。 我发现我的发布配置文件设置为使用开发人员证书。 它应该看起来像这样:
在此处输入图像描述

I had a similar issue but in Monotouch. I found that my Release profile was set to use developer certs. It should look like this:
enter image description here

め七分饶幸 2024-07-11 01:48:17

我有同样的问题。 我本来准备在这个问题上认输,但当我使用 Murky 检查我的代码时我发现了这一点。 我总是在签入之前浏览更改的文件的差异。这次这样做时,我注意到 project.pbxproj 文件已更改......并且在“分发”部分中的“PROVISIONING_PROFILE[sdk=iphoneos*] 条目” 一片空白。

退出并重新启动 Xcode 对我来说不起作用。 相反,我进入了我的项目和目标设置,并更改了代码签名以直接选择我的分发配置文件,而不是依赖于自动选择功能。 这样做会导致 project.pbxproj 文件填充正确的值,即使自动选择功能应该选择与我手动选择的配置文件完全相同的配置文件。

我需要一杯啤酒...

I had the same problem. I was ready to throw in the towel on this problem but I figured it out when I went to check in my code using Murky. I always skim the diffs on the files that changed before I check in. When doing so this time I noticed that the project.pbxproj file had changed....and in the Distribution section the entry for “PROVISIONING_PROFILE[sdk=iphoneos*]” was blank.

Quiting and restarting Xcode didn't work for me. Instead, I went into both my project and target settings and changed the code signing to directly select my Distribution profile rather than relying on the auto-select feature. Doing this caused the project.pbxproj file to populate with the correct values even though the auto-select feature supposedly selected the exact same profile that I selected manually.

I need a beer...

深爱不及久伴 2024-07-11 01:48:17

在尝试了此处列出的所有其他修复后,我们向 Apple 记录了 TSI。 遵循 中的所有步骤技术说明 TN2250 我们的问题是由于密封资源丢失或无效而引起的。 在我们的例子中,它是._.DS_Store

“..” 称为 Apple Double 文件,是将 Xcode 项目文件夹(*解压缩*)复制到不正确支持 HFS+ 的“资源分支”(用于代码签名)的文件系统并从该文件系统复制回来的结果。 这些额外的“..” 文件结果并导致代码签名验证失败。

要从 Xcode 项目文件夹中清除有问题的 Apple Double 文件,请在 Xcode 项目文件夹上运行 dot_clean 命令,执行全新构建,然后重新存档并重新尝试提交。

dot_clean /the/path/to/xcode/project

注意:您只需将项目文件夹拖到终端中即可自动填充路径

运行命令时不会出现任何消​​息,但项目构建可能会在您下次构建时显示有关该文件的警告。 您可以忽略这一点,应用程序将验证并成功提交。

After trying all of the other fixes listed here we logged a TSI with Apple. Having followed all the steps in Technical Note TN2250 our problem was caused because a sealed resource was missing or invalid. In our case it was ._.DS_Store.

The ".." is called an Apple Double file, and is the result of copying the Xcode Project folder, *unzipped*, onto and back from a file system that doesn't properly support HFS+'s 'resource forks' (used for code signatures). These extra ".." files result and cause code signing verification failure.

To clean the problematic Apple Double files from your Xcode project folder, run the dot_clean command on your Xcode project's folder, do a clean build, and then rearchive and reattempt your submission.

dot_clean /the/path/to/xcode/project

Note: You can just drag the project folder into the terminal to automatically populate the path

There is no message when you run the command but the project build might show a warning about the file when you next build. You can ignore this, the app will validate and submit successfully.

再可℃爱ぅ一点好了 2024-07-11 01:48:17

我尝试了所有其他建议的解决方案,但没有任何帮助。

我最终创建了一个新的 Xcode 项目并将所有代码和资源复制到其中。 这成功了,我的应用程序被放入审核队列中。

我还可以推荐 Apple 关于代码签名的技术说明进行调试/确认。

I tried all other proposed solutions, but nothing helped.

I ended up creating a new Xcode project and copy all my code and resources into it. That did the trick, and my app got placed into the review queue.

I can also recommend Apples technical notes on code signing for debugging/verification.

墨落画卷 2024-07-11 01:48:17

如果应用程序不使用远程推送通知,我会收到无效的二进制文件,但我将用于注册推送的代码和用于注册/接收远程通知的回调委托保留为未注释,即使该代码没有被使用。

这是最近的。 我上周的最后一次提交很好。 本周,它返回无效的二进制文件。 幸运的是,有一封电子邮件解释了该错误。

I received an invalid binary, if the app does not use remote push notification, but I left the code for registering push and the callback delegates for registering/receiving remote notification uncommented, even if the code does not get used.

This is recent. My last submission last week was fine. This week, it returns invalid binary. Luckily, there is an email that explains the error.

小猫一只 2024-07-11 01:48:17

我遇到了类似的问题,但我不使用 entitlements.plist。 然而,在十几次上传失败之后,我检查了我的 info.plist 并发现了一些东西。 我的 CFBundleIconFiles 数组有一个空条目。 我把它删除并重新提交,终于被接受了!

说真的,苹果要揭露这类验证错误有多难?

编辑:CFBundleIconFiles 的位置并不明显,因为它们使用不同的名称。 在项目信息视图中,Ctl 单击并选择“显示原始键/值”,然后您将看到对 CFBundleWhatever 的引用。 在这位编辑的例子中,他试图使用不存在的 [email protected] 文件。

I was having a similar problem, but I don't use entitlements.plist. However, after a dozen failed uploads, I checked my info.plist and discovered something. My CFBundleIconFiles array had an empty entry. I removed that and re-submitted, and it was finally accepted!

Seriously, how hard would it be for Apple to expose those kind of validation errors?

Edit: It's not immediately apparant where the CFBundleIconFiles are because they use a different name. In the project info view, Ctl click and select "Show Raw Keys/Values" and then you will see the references to CFBundleWhatever. In this editor's case, he was trying to use a non-existent [email protected] file.

開玄 2024-07-11 01:48:17

通过清理 myProject.xcodeproj 文件(右键单击,打开包)解决了这个问题,该包包含来自共同开发者的文件,删除这些文件后问题就解决了

Resolved this by cleaning up the myProject.xcodeproj file (right click, open package), the package contained files from co-developer, after deleting these the problem was solved

末が日狂欢 2024-07-11 01:48:17

对我来说,解决方案是在以下位置创建分发认证:
Apple 开发者配置门户

For me the solution was creating a distributing certification at:
Apple Developer Provisioning Portal.

季末如歌 2024-07-11 01:48:17

不管怎样,我想补充一下为我解决这个问题的内容。 我曾有一个 ? (问号)在我的应用程序标题中导致了错误。

For what it is worth, I want to add what it was that fixed this issue for me. I had a ? (question-mark) in my app title that was causing the error.

最笨的告白 2024-07-11 01:48:17

另一个数据点:有一段时间,我的应用程序出现了故障。 现在我添加了对应用内购买的支持,突然它因“无效二进制/无效签名”问题而失败。 仔细查看,发现entitlements plist文件中application-identifier的值是off的。

这很可能与我将配置文件从通配符替换为应用程序特定的配置文件(应用程序内购买所需)这一事实有关。 在旧配置文件下合格的应用程序 ID 错误。 它与 info.plist 中的应用程序 ID 不匹配,但显然 iTunes 原谅了这一点。

因此,回顾一下:

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.*

是可以的,而

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.foo

会导致“无效的二进制文件”。

Another data point: for a while, my app went through. Now I've added support for in-app purchases, and suddenly it fails with an "Invalid binary/invalid signature" problem. Upon careful looking, I found out that the value of application-identifier in the entitlements plist file was off.

This, most likely, had to do with the fact that I've replaced the provisioning profile from a wildcarded one to a app-specific one (required for in-app purchases). The wrong app ID qualified under the old profile. It did not match the app ID in the info.plist, but apparently iTunes forgave that.

So, to recap:

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.*

is OK, while

info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.foo

causes "Invalid binary".

囚我心虐我身 2024-07-11 01:48:17

我对此和 4.3 GM SDK 都存在问题。 我们的一款应用程序无法通过收到的上传。 事实证明这是一个配置文件问题。 我重新生成了应用程序商店配置文件,效果很好。

I had a problem with this and the 4.3 GM SDK. One of our apps would not make it past upload received. It turned out to be a provisioning profile issue. I regenerated the app store profile and it worked fine.

剩余の解释 2024-07-11 01:48:17

我的解决方案涉及创建一个新的应用程序 ID。 我不确定为什么会修复它,但我怀疑它可能与捆绑标识符不匹配 - 创建新的应用程序 ID 迫使我确保我的应用程序和 iTunes 期望相同的事情。

My solution involved creating a new App ID. I'm not sure exactly why that fixed it, but I suspect it may have been mismatched Bundle Identifiers — creating the new App ID forced me to make sure my app and iTunes were expecting the same thing.

深者入戏 2024-07-11 01:48:17

另一个解决方案:

对我来说,只需在“代码签名”下设置“发布”证书即可解决此问题。 他们最初被设置为“不编码签名”。

Another solution:

For me simply setting the 'Release' certificates under 'code signing' fixed it. They were initially set to 'Don't code sign'.

清晰传感 2024-07-11 01:48:17

对我来说,问题是通过使用非隔行选项重新保存 PNG 图像来解决的。 在以前的版本中,允许使用隔行扫描 png,但要知道此图像可能会导致无效的二进制文件。

我的苹果留言:
图标文件损坏 - 图标文件 [电子邮件受保护] 似乎已损坏。 您的图标不得是交错的 PNG 文件。

您可以使用终端中的“file”命令查看 PNG 是否是交错的:
Eva-Madrazos-MacBook-Pro-2:GQ 7 集成广告 Eva$ 文件 *.png
Default.png:PNG 图像数据,320 x 480,8 位/彩色 RGB,非隔行

祝你好运,
伊娃

For me the problem was solved by resaving a PNG image with the non-interlaced option. In previous versions interlaced png were allowed, but know this images can cause the invalid binary.

My apple message:
Corrupt Icon File - The icon file [email protected] appears to be corrupt. Your icon must not be an interlaced PNG file.

You can see if the PNG is interlaced using the command "file" in the terminal:
Eva-Madrazos-MacBook-Pro-2:GQ 7 integracion ads Eva$ file *.png
Default.png: PNG image data, 320 x 480, 8-bit/color RGB, non-interlaced

Good luck,
Eva

生活了然无味 2024-07-11 01:48:17

我想指出可以向 Apple 发送电子邮件并要求他们检查日志。 在先尝试了很多事情之后,我就这么做了。 近四个星期后才需要提醒他们,但最后他们回复了并指出了问题的具体位置。

我的问题是,我之前尝试过其他应用程序图标,并且对旧图像的引用仍然保留在“CFBundleIcons”中。 我使用拖放功能来设置图标,但我没有注意到在添加新引用之前旧内容并未完全清除。

要查看错误引用,需要展开箭头以查看 plist 文件中的每个子元素。 一个技巧是右键单击文件并选择用于查看原始内容的选项。 这样你就不需要扩展任何东西。

I want to point out the possibility to email Apple and ask them to check their logs. I did just that, after having tried loads of things first. It was necessary to remind them after almost four weeks, but finally they replied and pointed to the exact spot of the issue.

The problem in my case was that I had previously tried other app icons, and a reference to the old image still remained in 'CFBundleIcons'. I used the drag and drop functionality to set the icon, but I didn't notice that the old content wasn't completely cleared before the new reference was added.

To see the faulty reference it was necessary to expand the arrows to view each and every sub element in the plist file. One tips is to right-click in the file and select the option for viewing the raw content. In that way you will not need to expand anything.

沧桑㈠ 2024-07-11 01:48:17

不允许使用 uuid。
我通过删除所有 [[UIDevice currentDevice] uniqueIdentifier]; 来修复它

uuid is not allowed.
I fixed it by remove all [[UIDevice currentDevice] uniqueIdentifier];

就此别过 2024-07-11 01:48:17

应用程序上传后,我收到了无效的二进制文件,但没有电子邮件跟进说明失败的原因。 我尝试同时执行几件事,但不确定以下哪一项实际上修复了该问题:

  1. 重新启动 Macbook Pro
  2. 将我的项目的源代码从 NTFS 驱动器移至 HFS+ 驱动器并重新编译。

I received an Invalid Binary after an app upload, with no e-mail followup as to why it failed. I tried doing a couple things at once, and I'm not sure which of the following actually fixed it:

  1. Restarted Macbook Pro
  2. Moved the source code for my project from an NTFS drive to an HFS+ drive and recompiled.
月朦胧 2024-07-11 01:48:17

我的两分钱:

下载最新版本的应用程序加载器。 我刚刚更新,现在收到不同的错误消息。

My two cents:

Download the latest version of the Application Loader. I've just updated and now get a different error message.

又爬满兰若 2024-07-11 01:48:17

我刚刚(再次)经历了这个麻烦,但这次我发现我的分发配置文件的状态为“无效”。 如果您认为其他一切都正确,请仔细检查门户中的状态并续订/重新下载不处于活动状态的任何内容。

I just went through this hassle (again) but this time I found that my distribution profile had a status of "Invalid". If you think everything else is right, double-check the status in the portal and renew/re-download anything that isn't in the Active state.

像极了他 2024-07-11 01:48:17

请参阅此链接以获取解决方案:

http://greghaygood.com/ 2010/09/04/invalid-binary-message-from-itunesconnect

简短的回答是“最终我仔细检查了我的 info.plist 并发现了一些东西。我按照新指南添加了 CFBundleIconFiles,但有一个我删除了数组列表中的空条目并重新提交,它终于被接受了!”

See this link for the solution:

http://greghaygood.com/2010/09/04/invalid-binary-message-from-itunesconnect

The short answer is that "Eventually I double-checked my info.plist and discovered something. I added CFBundleIconFiles per the new guidelines, but there was an empty entry in the array list. I removed that and re-submitted, and it was finally accepted!"

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文