I have an App that integrates Framework A that I have developed.
Framework A has two (optional) weak-linked third-party dependencies, Framework X and Framework Y.
If I add both optional frameworks, everything works fine.
I don't need Framework Y in my App, so I'm adding to MyApp only Framework A and X.
Run on device works fine, upload to TestFlight works fine, but then I'm getting this email from App Store Connect, and build is marked as an Invalid Binary on App Store Connect.
App Store Connect Dear Developer,
We identified one or more issues with a recent delivery for your app,
Please correct the following issues, then upload again.
ITMS-90562: Invalid Bundle - One or more dynamic libraries that are
referenced by your app are not present in the dylib search path.
ITMS-90562: Invalid Bundle - The app submission can not be
successfully recompiled from bitcode due to missing symbols during
linking. You can try to reproduce and diagnose such issues locally by
following the instructions from:
https://developer.apple.com/library/archive/technotes/tn2432/_index.html
Best regards,
The App Store Team
I have tried editing Build Settings, but nothing happened, the error stays.
How I removed that error was by disabling Bitcode. Build Settings - Enable Bitcode - NO.
But that is not a solution for me.
I saw the same question on the Apple Developer forum. https://developer.apple.com/forums/thread/88814
After that, I tried to Validate App in the organizer, which went well. After that, I tried to export IPA for AdHoc distribution. But then I got an error:
ipatool failed with an exception: #<CmdSpec::NonZeroExitException: $ /Applications/Xcode.app/Contents/Developer/usr/bin/python3 /Applications/Xcode.app/Contents/Developer/usr/bin/bitcode-build-tool -v -t /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin -L /var/folders/cy/n0fltmsx671_s97kbtqvhcw80000gn/T/ipatool20220308-33623-uqn6vl/thinned-out/arm64/Payload/MyApp.app/Frameworks/FrameworkY.framework -L /var/folders/cy/n0fltmsx671_s97kbtqvhcw80000gn/T/ipatool20220308-33623-uqn6vl/thinned-out/arm64/Payload/MyApp.app/Frameworks/FrameworkX.framework --sdk /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS15.2.sdk -o /var/folders/cy/n0fltmsx671_s97kbtqvhcw80000gn/T/ipatool20220308-33623-uqn6vl/thinned-out/arm64/Payload/MyApp.app/Frameworks/FrameworkA.framework/FrameworkA --generate-dsym /var/folders/cy/n0fltmsx671_s97kbtqvhcw80000gn/T/ipatool20220308-33623-uqn6vl/thinned-out/arm64/Payload/MyApp.app/Frameworks/FrameworkA.framework/FrameworkA.dSYM --strip-swift-symbols /var/folders/cy/n0fltmsx671_s97kbtqvhcw80000gn/T/ipatool20220308-33623-uqn6vl/thinned-in/arm64/Payload/MyApp.app/Frameworks/FrameworkA.framework/FrameworkA
I saw a similar error in this post: https://developer.apple.com/forums/thread/663112
If at export I disable Bitcode, I'm able to export the IPA file.
I'm not sure if I'm doing something wrong or is there a bug on Apple's side with Bitcode, but I hope that maybe someone had the same problem.
Removing Bitcode is not a good approach since it will not slim the ipas for installation.
What I'm doing at the moment is to use Xcode 13.2.1 for the upload of my project.
An app signed with a codesign version provided on an older macOS, like Catalina (10.15) will not run on iOS 15 because the lastest version you can install is Xcode 12.4.
Xcode 12.5 seems to change the behavior of codesigning. When installing you get the error message:
The code signature version is no longer supported
Is there a workaround?
Notice
This answer is mostly for people using older versions of Xcode. My build farm was for a time stuck at Xcode 12.4 because some Mac minis couldn't be upgraded past Catalina. If you are using a recent Xcode 13+ this is not your issue. Probably cruft of some kind in your project.
If you're still using an Xcode 12 release it is time to let go. The only reason to use 12.4 would be because you're stuck on Catalina and new problems are cropping up that will not be worked around so easily.
codesign --generate-entitlement-der
Apple has changed the codesign signature to include DER encoded entitlements in addition to the plist encoded entitlements. This additional DER encoded entitlements section is required in iOS 15 and becomes the default behavior of codesign in the latest Xcode. To use codesign on an older machines with an older version of Xcode add the --generate-entitlement-der flag to your call to codesign.
If signing through Xcode, you can add this flag to the OTHER_CODE_SIGN_FLAGS setting in the Build Settings tab.
If codesigning at the command-line:
CODESIGN_ALLOCATE=$( xcrun --find codesign_allocate ); export CODESIGN_ALLOCATE
xcrun codesign --generate-entitlement-der ...
The source of this information was the Apple Forum thread and the answer from Matt Eaton in DTS at Apple.
In the Xcode 12.5 Release Notes there is also a reference to the new signature format. However, it seems the information is not entirely correct.
General advice
If you have a non-trivial setup like CocoaPods, you should probably de-integrate and re-integrate and of course do a project clean. These sorts of 'me too' answers really just add noise to the signal and anyone doing this sort of development should have already tried this.
Here are some visual directions to #CameronLowellPalmer's answer.
I got the steps from
#WayneHenderson's comment underneath the accepted answer.
Follow the red arrows steps 1 - 11 (there is no 8, I made a mistake and went from 7 straight to 9).
The most important thing is step 4, make sure to select All or you won't find the Other Code Signing Flags options.
For step 5 just enter Other Code Signing Flags into the search container.
Steps 9 - 11 is where you enter --generate-entitlement-der
You will need to add the --generate-entitlement-der to your OTHER_CODE_SIGN_FLAGS under Build Settings.
Xcode > Target > General
Section "Embedded Framework, Libraries and Embedded Content"
Set all frameworks in the Embedded field to "Do not Embed"
For people who use Xcode13 like me, the problem may not be because of the code signature of our apps (To check the code signature of apps, see https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format), but due to the code signature of one of the dependencies, and removing the dependency solves the problem.
In my case, I remove the dependencies one by one, and eventually found that the culprit is FirebaseAnalyticsOnDeviceConversion. remove dependencies
I have spent 2 days to find this issue, Finally i got the solution here from the person Lance Samaria. I would like to share it.
Target-> Build Settings -> Other Code Signing Flags
Add this code --generate-entitlement-der to both Debug and Release
After that Go to Target-> General->Frameworks, Libraries, and Embedded Contents -> Change to "Do not Embed"
Also I renewed Provisioning Profile and IOS Distribution Certificates.
Now Clean Build Folder and Run Your Project.
Thank you so Much for Lance Samaria
I want to share my solution. This worked for me using XCode 12.3, macOS Catalina, and tested using Adhoc distribution.
Build, archive, export ipa as usual using XCode.
Now you have the IPA file, then rename it to zip extension. (make a backup if needed)
Extract it. There should be a Payload folder.
Open terminal, cd to your IPA directory, then run command:
codesign -s "CERTIFICATE_NAME" -f --preserve-metadata --generate-entitlement-der ./Payload/YOUR_APP.app
CERTIFICATE_NAME is your certificate name located in keychain. It maybe looks like this: Apple Distribution: XCompany (XXXXXX)
YOUR_APP is your .app file name located in Payload folder.
This warning showed up, I ignored it.
Warning: default usage of --preserve-metadata implies "resource-rules" (deprecated in Mac OS X >= 10.10)!
Then run zip command:
zip -ru myapp_resigned.ipa Payload
Done. You can redistribute the new IPA.
After testing all solutions, Only one worked for me. Because XCode adds sign signature automatically when you add Framework, Any Framework that needs to Embed & Sign should remove, and add again. Xcode will add the new sign signature automatically.
Go to YourTarget>Frameworks, Libraries, and Embedded Contents.
Remove all frameworks that are Embed & Sign, except CocoaPods.
add removed frameworks again and set to Embed & Sign.
check that pods framework set on Do Not Embed
Now clean and run your app on your device.
What helped in my case was pod deintegrate and pod install. That's all.
I had this problem with the newest Xcode version (13.4.1). As the installation on an iOS device actually stoped working out of nowhere (it did install successfully 10 min ago before I downgraded one dependency), I doubted the proposed solutions relate to my problem.
Just my two cents.
As pointed out in other responses, now to sign ios app (compatible with ios and ipados 15) with codesign command on MacOS prior to Big Sur add the --generate-entitlement-der flag. I can sign my app with Xcode 10.3 using this python 2.7 (tried both on MacOS Mojave 10.14 and MacOS Catalina 10.15) snippet code:
from fabric.api import local
local('cp %s "%s"' % ("/path/to/embedded.mobileprovision", app_full_path))
local('xattr -rc %s' % app_full_path)
local("codesign -f --generate-entitlement-der -vv -s \"%s\" --entitlements \"%s/Entitlements.plist\" %s" % (
env.code_sign_identity, app_full_path, app_full_path)
)
Output example log:
[localhost] local: cp /path/to/embedded.mobileprovision "/path/to/Payload/appname.app"
[localhost] local: xattr -rc /path/to/Payload/appname.app
[localhost] local: codesign -f --generate-entitlement-der -vv -s "iPhone Distribution: COMPANYNAME S.p.A." --entitlements "/path/to/Payload/appname.app/Entitlements.plist" /path/to/Payload/appname.app
/path/to/Payload/appname.app: replacing existing signature
/path/to/Payload/appname.app: signed app bundle with Mach-O universal (armv7 arm64) [com.name.reverse.dns]
Some additional tips...
MacOS keychain should contains the Apple certificate used to create the mobile provisioning profile, which is also utilized to distribute the app we’re signing. You can check it using the command security find-identity -p codesigning:
$ security find-identity -p codesigning
Policy: Code Signing
Matching identities
1) AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA "iPhone Distribution: COMPANYNAME S.p.A."
...
13) CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC "iPhone Developer: Name Surname (DDDDDDDDDD)"
13 identities found
Valid identities only
1) AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA "iPhone Distribution: COMPANYNAME S.p.A."
...
13) CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC "iPhone Developer: Name Surname (DDDDDDDDDD)"
13 identities found
After the ipa zip archive creation, you can use the Gem ipa_analyzer (https://github.com/bitrise-io/ipa_analyzer) to verify if the app is correctly signed:
$ zip -9 -y -r /path/to/appname.ipa /path/to/Payload
$ gem install ipa_analyzer --user-install
$ PATHAPP="/path/to/appname.ipa"
$ ~/.gem/ruby/2.6.0/bin/ipa_analyzer -i ${PATHAPP} -p --info-plist --prov | grep -E "ExpirationDate|CFBundleIdentifier|DER-Encoded-Profile"
"DER-Encoded-Profile": "#<StringIO:0x00000f0000000008>",
"ExpirationDate": "2022-09-18T12:15:25+00:00",
"CFBundleIdentifier": "com.name.reverse.dns",
...
Here a complete output example.
As additional references about this issue, you can read also this Apple documentation page and this Apple forum post.
EDIT: this procedure it's working also with MacOS Monterey (version 12.6.1) and Xcode Version 14.1 (14B47b).
The following changes solved my problem
Go to Project Target and select General
Scroll down to Frameworks, Libraries, and Embedded Content
Turn any Embed & Sign to Do Not Embed
My issue was I was using custom framework, and when I embed it in my app. it showing me error
The code signature version is no longer supported.
i spend whole day to struggle with it. Finally resolved it by adding user-defined settings. In new Xcode 13 which supports arm 64
Project target->Build Settings-> + sign to add user define setting and add a setting. then add VALID_ARCHS as a field under this add the value $(ARCHS_STANDARD). Automatically it will convert it arm64 arm 7.
see the attached image for more reference.
When nothing else works, try turning your device off and back on again. Strangely this finally fixed it for me.
My issue was I was using custom static framework target, and I embed it in my app, Finally resolved it by don't embed it or change static to dynamic framework target
Maybe it will help somebody one day, but the solution for me was connected with the pods and their framework.
When I switched settings to Do not embed everything worked.
While Building the app for iOS Distribution in flutter I faced the below issue with the build, I tried many things available on google related to this issue but no resolution yet.
How am I supposed to deploy flutter application to iOS Appstore?
Warning: unable to build chain to self-signed root for signer "iPhone Distribution: Mark Davids (*********)"
/Users/mark/Downloads/chat_app-master 2/build/ios/Release-iphoneos/Runner.app/Frameworks/App.framework/App: errSecInternalComponent
Command PhaseScriptExecution failed with a nonzero exit code
note: Using new build system
note: Building targets in parallel
note: Planning build
note: Constructing build description
Encountered error while building for device.
This is a vague error, however my guess is its 1 of two things.
There is Flutter detritus that is blocking your build, which you can fix by running the flutter clean command
Your certificate is invalid. When dealing with this in the past I have found the easiest way to fix it is to open XCode, set the signing to none, purge your certificates and keys from your system, and then re-add them to the keychain.
I want to test the release build version on my iOS device directly using this command:
cordova run --buildConfig=build.json ios --release --device
But not working, is anybody here manage to test the release build version running on device? Thanks in advance.
Or let say the worst case, we can't do it. Is there any guarantee that below command:
cordova build --buildConfig=build.json ios --release
will build the release version of our app, when we open the xcode project on xcode?
My point is I need to get the release version build by cordova, not by Xcode.
Likely not guaranteed, but that's just a guess.
I'm not sure why you need Cordova to put together a release build—in order to submit to the app store you will want to use Xcode to archive your app. I have no idea if Cordova can do a proper archive but personally I wouldn't rely on it because at least Xcode should be up to date on what Apple demands from the build. Especially with automatic code signing. Cordova may lag in its implementation when Apple changes things.
One little thing, when a .ipa is signed for distribution through the app store, you cannot side load it onto a device. You can only side load .ipas that are signed for development.
I am trying to install an iOS application in my iPad running in iOS 5.1.1. When i launch it with Xcode with the development profile, i am getting the following errors :
Xcode cannot install or launch applications supporting the 64-bit
architecture on devices running iOS versions prior to 6.0. This
configuration is supported for distribution through the iOS App Store,
but cannot be used during development with Xcode. To continue, edit
the Run scheme action and select a build configuration that does not
include the 64-bit architecture.
I have tried to change the building architecture by removing the arm64 but i have the same error.
I have tried to install it with testflight by building an ipa with an adhoc provision profile but the same error repeats.
How i can test my application in real device running iOS 5.1.1, building with Xcode 5
You need to make a test target that has no arm64 within valid architectures.
See screenshot, check that you don't have arm64.
Changing the Build Active Architecture Only to Yes for the Debug scheme fixed this for me. This is shown in the screen shot of the accepted answer and it's possible that is the real solution, rather than what the accepted answer describes.