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
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.
Just go to the build setting and do as it is your problem will resolve.
just Archive your build from Xcode right click on archive file -> show in finder -> right click -> show package content -> product -> appliction -> copy .app file generate payload & upload using Application Loader. It help in my case.
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
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)
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
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
Delete libswiftRemoteMirror.dylib
from the app bundle (this invalidates the signature)
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)
Re-sign the app bundle using codesign --entitlements <file>
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