什么是 libswiftRemoteMirror.dylib，为什么它包含在我的应用程序包中? [英] What is libswiftRemoteMirror.dylib and why is it being included in my app bundle?

问题描述

我有一个 iOS 应用程序，我最近将它切换到了 Xcode 8.作为其中的一部分，我们从 swift 2.2 切换到 2.3(swift 3 将在稍后推出).

我有一个自动构建管道，它基本上运行 xcodebuild 以在专用构建机器上生成一个发布二进制文件，在我整理好所有这些之后(Xcode 8 的自动代码签名真的把一切搞砸了)，现在当我将我的应用程序上传到 iTunes 连接时，它失败并显示此错误:

<块引用>

错误 ITMS-90171:无效的捆绑结构 - 不允许使用二进制文件‘MyApp.app/libswiftRemoteMirror.dylib’.除了受支持捆绑的 CFBundleExecutable 之外，您的应用不能包含独立的可执行文件或库.请参阅https://developer.apple.com/go/?id=bundle-structure 有关 iOS 应用程序包结构的信息."

果然，如果我解压 .ipa 文件并查看，libswiftRemoteMirror.dylib 就在那里.

如果我通过 Xcode 为 iTunes 存档/导出，那么它会生成一个没有 libswiftRemoteMirror.dylib 的应用程序包，但是我的应用程序的所有其他版本似乎都有它.即使只是在 Xcode 中进行调试构建，然后查看输出也会显示 libswiftRemoteMirror.dylib 位于我的应用程序包中，这表明 Xcode 本身肯定将它放在那里，而不是我的自动构建脚本的任何部分.

这个文件是什么，为什么放在那里，我该怎么办?我可以修改我的构建脚本以删除此文件以进行发布构建，但我担心这可能会影响代码签名过程.无论如何我都会尝试一下，看看会发生什么，但感觉这不太正确.

如有任何建议，我们将不胜感激.

解决方案

我永远无法让命令行 xcodebuild 与自动代码签名一起工作.我假设是因为自动构建机器作为一个不同的帐户运行，该帐户只能通过 SSH 访问 - 它从来没有以该用户帐户的身份运行过完整的"Xcode，并且它的登录钥匙串或类似的东西中没有任何证书.

我不想使用像shenzhen这样的东西，因为我过去除了这些东西的糟糕经历之外什么都没有.Xcode 构建系统足够复杂和脆弱，无需添加更多脚本和可能出错或过时的内容.

这是我最终解决问题的方法(这很可怕，但这是我能找到的唯一使它最终起作用的方法)

1. 在自动构建脚本中，编辑 .pbxproj 以搜索和替换 Provisioning Style = Automatic; 为 Provisioning Style = Manual;.还将 iOS Developer 替换为 iOS Distribution 以获取同一 pbxproj 文件中的代码签名内容.这两件事关闭自动签名

2. 运行 xcodebuild 以与我在 Xcode7 中所做的相同的方式构建(但不存档)项目.Xcode 编译应用程序并对其进行签名，但它还无效，因为它包含 libswiftRemoteMirror.dylib 并且由于某种原因还没有任何授权文件

3. 从应用程序包中删除 libswiftRemoteMirror.dylib(这会使签名无效)

4. 通过从配置文件中提取权利位，在应用程序包文件夹中生成一个 Entitlements.plist(例如 BlackBerry 的 SWSiOSResign.sh 脚本)

   5. 使用 codesign --entitlements

   重新签署应用程序包

   6. 从那里开始，使用与bq/package_ipa.sh 复制 SwiftSupport 文件夹，然后将文件压缩到 ipa.

我实际上无法使用 package_ipa.sh 文件，我需要重新实现类似的逻辑，因为我需要引用 Swift_2.3.toolchain 来获取来自我的应用程序的 SwiftSupport 仍然是 swift 2.3 - 不是 XcodeDefault.toolchain(这是 swift 3)

似乎我应该能够将 xcodebuild --archive 与其他一些东西结合使用，以避免其中的一些步骤.我永远无法让它在 Xcode7 下工作，但如果我有时间，我可能会用 XC8 再试一次

I've got an iOS app which I've recently switched to Xcode 8. As part of that we switched from swift 2.2 to 2.3 (swift 3 will come later).

I've got an automated build pipeline which essentially runs xcodebuild to produce a release binary on a dedicated build machine, and after I sorted all that out (Xcode 8's automatic code signing really screws everything up), now when I upload my app to iTunes connect, it fails with this error:

ERROR ITMS-90171: "Invalid Bundle Structure - The binary file 'MyApp.app/libswiftRemoteMirror.dylib' is not permitted. Your app can't contain standalone executables or libraries, other than the CFBundleExecutable of supported bundles. Refer to the Bundle Programming Guide at https://developer.apple.com/go/?id=bundle-structure for information on the iOS app bundle structure."

Sure enough, if I unzip the .ipa file and have a look, there's libswiftRemoteMirror.dylib sitting there.

If I archive/export for iTunes via Xcode, then it produces an app bundle which does not have libswiftRemoteMirror.dylib, however all other builds of my app appear to have it. Even just doing a debug build within Xcode, then looking at the output shows that libswiftRemoteMirror.dylib is sitting in my app's bundle, indicating that Xcode itself is definitely putting it there, not any part of my automated build script.

What is this file, why is it being put there, and what should I do about it? I can modify my build script to delete this file for release builds, but I'm concerned that might affect the code signing process. I'll try it anyway and see what happens, but it feels like that's not quite the right thing to be doing.

Any advice would be appreciated.

解决方案

I could never get command line xcodebuild to ever work with automatic code signing. I assume because the automated build machine runs as a different account which is only accessed via SSH - It's never had "full" Xcode run as that user account and it doesn't have any certificates in it's Login keychain or anything like that.

I didn't want to use something like shenzhen because I've had nothing but bad experiences from those kinds of things in the past. The Xcode build system is complicated and fragile enough without having to add in more scripts and things that could go wrong or out of date.

Here's what I ended up doing to fix the problem (it's horrible, but it was the only thing I could find that made it work in the end)

1. In the automated build script, edit the .pbxproj to search and replace Provisioning Style = Automatic; with Provisioning Style = Manual;. Also replace iOS Developer with iOS Distribution for the code signing stuff in the same pbxproj file. These two things turn off automatic signing

2. Run xcodebuild to build (but not archive) the project in the same way I did in Xcode7 . Xcode compiles the app and signs it, but it's not valid yet, as it contains libswiftRemoteMirror.dylib and also for some reason hasn't got any entitlements file

3. Delete libswiftRemoteMirror.dylib from the app bundle (this invalidates the signature)

4. Generate an Entitlements.plist in the app bundle folder by extracting the entitlements bit from the provisioning profile (Like what BlackBerry's SWSiOSResign.sh script does)

   5. Re-sign the app bundle using codesign --entitlements <file>

   6. From there, use a similar technique to what bq/package_ipa.sh does and copy the SwiftSupport folder, then zip the file into an ipa.

I couldn't actually use package_ipa.sh file, I needed to re-implement similar logic instead because I need to reference Swift_2.3.toolchain to get the SwiftSupport from as my app is still swift 2.3 - not XcodeDefault.toolchain (which is swift 3)

It seems like I should be able to use xcodebuild --archive in combination with some other things to avoid some of these steps. I could never get that to work under Xcode7, but I might try again with XC8 if I have time

这篇关于什么是 libswiftRemoteMirror.dylib，为什么它包含在我的应用程序包中?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！