What is libswiftRemoteMirror.dylib and why is it being included in my app bundle?

Recently started using Swift for our project and got same error.

To find a root cause, I just did 'grep -Ril "libswiftRemoteMirror" .' in XCode.app (I have 10.1 currently) and found ./Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/XCLanguageSupport.xcplugin/Contents/Resources/swift-stdlib-tool.xcspec file. It says:

     // SWIFT_RESOURCE_DESTINATION and SWIFT_RESOURCE_LIBRARY allow us to copy
    // libswiftRemoteMirror.dylib into place so that memory debugging tools have access to it
    // on device.
    // We disable these options in "DEPLOYMENT" modes, so that the libswiftRemoteMirror.dylib
    // does not make its way into archives submitted to the App Store.

So solution is simple - in XCode target settings set Deployment Postprocessing to Yes for your Release configuration (or whatever you use for build)

I ran into the same problem after installing Xcode 8, by building via shenzhen.

I decided to look at Fastlane as an alternative, and their gym program produces an ipa that can be submitted to Apple.

It was reasonably easy for me to replace the call to ipa (shenzhen's executable) with a call to gym, and the rest of my build-and-upload scripts worked without modifications.

If you prefer to build directly, I lifted the following from the gym readme. It produces an .xcarchive containing an .app file without the libswiftRemoteMirror.dylib. I don't use that kind of flow myself, so I can't say how you would proceed from there.

xcodebuild \
  -scheme Scheme \
  -workspace Project.xcworkspace \
  -configuration 'Release' \
  -destination 'generic/platform=iOS' \
  -archivePath './Output.xcarchive' \
  archive

In my case I got ERROR ITMS-90171 because I am using custom frameworks.

"Invalid Bundle Structure - The binary file 'MyFramework.framework/libswiftRemoteMirror.dylib'

(I didn't get it for my application.)

I tried gym but it got stuck at xcrun. So I tried doing rm -rf libswiftRemoteMirror in the build phrase (with a custom run-script) for every custom framework I have and interestingly I didn't break anything: it worked.

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