When i want to make archive to upload app on apple Store in the end of archive i get this error /bin/sh -c /Users/aneeq/Library/Developer/Xcode/DerivedData/Runner-hfzveethzxphozduylnhsnbtzzct/Build/Intermediates.noindex/ArchiveIntermediates/Runner/IntermediateBuildFilesPath/Runner.build/Release-iphoneos/Runner.build/Script-9740EEB61CF901F6004384FC.sh
and also this waring
None of the architectures in ARCHS (arm64) are valid. Consider setting ARCHS to $(ARCHS_STANDARD) or updating it to include at least one value from VALID_ARCHS (x86_64).
can someone kindly help me with this and also its run fine on emulator.
Its flutter Application not Native.
The problem is that you need the latest version of MacOS and Xcode, in this case, Xcode 12.5.1 and MacOs Big Sur 11.5.2.
Generally, that can be a problem that you do not have the most recent version of MacOS and Xcode, you can try updating or checking if you have any update, then check if you have your linked libraries correctly.
Had this issue, Fixed by opening XCode using rosetta.
I see many people experiencing this problem - and many different possible solutions. For me, I had accidentally messed with the certificates in Keychain Access. To fix, I deleted those, signed out of my account in Xcode (preferences), and then signed back in. Then in signing and capabilities, I'd select my account, Xcode would prompt me to revoke the old certificates (no longer found) and then create a brand new set. Then my app would build.
For me, clean derived data was required.
~/Library/Developer/Xcode/DerivedData
just delete import 'dart:html';
Related
After updating to Xcode 13.x on Monterey, I've started getting numerous Code sign error(s): Command usr/bin/codesign failed with a nonzero exit code when building my project.
Cleaning Build Folder and deleting derived data are NOT working as a fix. Any suggestions?
I found a solution to delete the Apple Worldwide Certificate in my Keychain Access. It seems to recreate when building and fixes the codesign error. Sometimes there are 2 certificates and I just delete the older one:
For me, xcode13.4 / monterey osx, iOS 15.0 device. I recently upgraded to monterey and for some reason was the certificate not trusted in the keychain. I had to manually trust the keychain and then it worked. See this also. https://support.apple.com/guide/keychain-access/change-the-trust-settings-of-a-certificate-kyca11871/mac
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.
/Users/Alex/Library/Developer/Xcode/DerivedData/MyProject-ehabmnclpzlywhabrefntacibonm/Build/Intermediates.noindex/ArchiveIntermediates/Fuego/InstallationBuildProductsLocation/Applications//MyProject.app/Frameworks/Alamofire.framework: unknown error -1=ffffffffffffffff
Command /bin/sh failed with exit code 1
I got this issue when I Archive my project. When I run app on simulator it works ok without such issue above.
Also it works ok with Xcode 8, but now when I try to Archive it on Xcode 9 I have this issue. But maybe this is not the case as I reinstall Mac OS from scratch, so it maybe cocopods version issue I am not sure.
Also two // here in the example above is also strange for me /Applications//MyProject.app
I believe it's a Xcode's bug. Restart your Mac and try to build again. Xcode would ask permission to access your Keychain before build Alamofire, then just allow it.
Hm it's very strange after some search on the Web I found that this is actually signing issue.
I used Xcode to generate new distribution certificate and maybe this leads some problems for me.
What I did to solve my issue.
I removed all certificates on my Mac and in my apple account.
I removed all prov profiles as well on my Mac and in my apple account.
I requested certificate and save it on the disc manually (not via Xcode )
I recreated certificate and profile. Downloaded it manually and double click on it.
After that I faced with keychain issue when I can not enter password to allow signing my certificate. I use this link to move certificate form login to system section.
Finally I get it work.
I recently upgraded to Xcode 9 from 8.3.3.
Our project is written in Objective-C as are all the other frameworks we use. I have added a framework which is written in Swift (version 3.0). In Xcode 8, I am able to build and run the project without problem in simulator and on device. In Xcode 9 I am unable to run the project on simulator or device due to the error:
dyld: Library not loaded: #rpath/libswiftCore.dylib
Referenced from: .../libraryname
Reason: image not found
After downgrading, I was able to run the project again.
My configuration has:
ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES;
STRIP_SWIFT_SYMBOLS = NO;
SWIFT_VERSION = 3.0;
After battling for several hours with this error and trying various solutions, my solution turned out to be different than others here so I'm adding it for others who may benefit.
I tried:
- ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES
- LD_RUNPATH_SEARCH_PATHS = $(inherited) #executable_path/Frameworks
No luck. Turned out the issue was more basic. My project has multiple build targets and somehow the setting for Host Application had gotten unset.
The Swift framework has to be built with the same version of Swift as your project (in this case Swift 4 inherantly since you upgraded and are running through Xcode 9).
Rebuild and re-add/replace the framework with the new version and it should work.
Are you using Carthage and have multiple XCode_s on your machine? I had an issue recently when I ran
carthage update --use-ssh --platform iOS while xcode8.3.3 was selected in the command line. Then included built frameworks into the build.
For it to work in XCode9 you will need to run switch command
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer for your Xcode.app and run carthage again.
Hope it helps.
Had the same problem. I'm using Xcode 9.2, Swift 4 and my device runs in iOS 11.1.
Solution:
I deleted Apple Worldwide Developer Relations Certificate Authority in Keychain Access and replace it with a new one (you can download certificate here)
After that, I have changed "Trust"(double-click the certificate) from "Always Trust" to "System Default".
Try restarting Xcode. I tried everything else and this is what stopped the problem.
It mainly occurs if your certificate trust settings is set to "Always Trust". Change it to "System Defaults" and recreate the build. This should solve the issue: https://egeek.me/2017/10/21/code-signing-blocked-mmap-on-ios-device/
I faced the same problem (on Xcode 9.4.1) but couldn't solve it with any of the help. I faced a problem where Xcode kept on prompting me to use my keychain but couldn't complete the request—although I gave my password. The app built successfully and installed. However, it crashed upon running on the device immediately.
Here's what solved my issue.
Deleted my Certificate & public/private key pair
Created a new Certificate (via a CSR) and installed it on my computer
Linked the new certificate to the provisioning profile and installed the profile on Xcode
Cleaned the build and deleted the existing build on the device
Hurray!!!
Hope this helps someone who is searching through the planet!
Just clean and built solve this problem. Tested in Xcode 9.2 and Swift 4
I am trying to archive my first iOS 4.3 Application for iPhone and I always encounter this error:
Command /usr/sbin/chown failed with exit code 1
I have searched through various forums, trying solutions such as changing the Alternate Install Group (which I don't know what to change to), and turning on 'Skip Install'.
As dumb as it sounds, in XCode 5.1.1, all I had to do was quit out and restart XCode just now. I know it's not much of an "answer" but it just worked for me.
Edit: this is still working as of July 2018 for folks.
Edit: this is still working as of January 2019 xcode 9.4.1
Edit: this is still working as of February 2023 xcode 14.2
I was having difficulty with the SetOwnerAndGroup part of Archiving - I was getting /usr/sbin/chown failed, and it was getting 'operation not permitted' on each file it tried to 'chown'.
This was easily tested in the terminal - 'chown' doesn't work, but 'sudo chown' does. Since I had no need to be changing file permissions, the simplest solution was to not do the chown.
The screenshot above shows - I just blanked out Install Owner/Group, and that did it.
When I got this error, rebooting my computer fixed it.
I have tried all the other solutions but none of them worked for me. So I have run this on a terminal to change the owner to me on every file in my project:
sudo chown -R my_username:my_group ./my_project_folder
where "my_username" is you username, "my_group" is your group (this is usually staff) and "my_project_folder" your project's folder.
None of the other solutions worked for me on Xcode 4.5. What I had to do was the following:
The fix is by removing the armv6 architecture from both your project and the CordovaLib project, clean
both projects, and rebuild.
Source
To it works in my environment I cleaned all information about permission, as +adalle said, complemented by Tom and Phil
I emptied the fields Install Group, Install Owner, Install Permission including the Cordova SubProject
I had the same issue with Xcode . It started working after restarting Xcode.
In the screenshot , Xcode ->build settings , installed group was empty after restarting Xcode .the group id it has showed as some number.
Not sure if this is the same problem you are having, but this fixed it for me:
When I created my XCode project, my app name had a space in it, so trying to deploy my app always failed. I was able to fix this by using a Custom Archive Name.
In XCode 4...
Edit the Deployment Scheme
Click on the Archive tab
Then specify an Archive Name that doesn't have spaces in it.
I tried all possible variants and they didn't help me. So I downloaded old XCode 4.4.1 and voila - application archived successfully :)
Select the target that's giving you the error
Change Build Active Architecture Only from Yes to No
That worked for me.
For me reboot my mac fixed it. OS High Sierra, xCode 9.2
When this happens to me on Xcode 8, I do "Clean build folder" 2 times (the first time it throws an error, but the second time succeeds) and then archive again.
Note: The "Clean build folder" option is under "Product" Menu, hold the alt button and you will see the "Clean" option changing to "Clean build folder".
Clean your project.
Clean your build Folder. (Product > ⌥ > Clean Build Folder)
Set the target device to Generic iOS Device .