I'm trying to build a continuous integration's script on my xcode project, but I'm stuck trying to archive my xcode project using xcodebuild command. When trying :
sudo xcodebuild -scheme MyScheme -archivePath builds/XXX.xcarchive archive DEVELOPMENT_TEAM=YYY CODE_SIGN_IDENTITY='iPhone Distribution' CODE_SIGN_STYLE='Manual' PROVISIONING_PROFILE_SPECIFIER=ZZZ
XXX is my project name
YYY is my development team identifier, like ABC123DEF, it's a string
ZZZ is my provisionning profile name, not a code but a string, like "My Provisionning Profile"
I always get this error :
error: No profile for team 'YYY' matching 'ZZZ' found: Xcode couldn't find any provisioning profiles matching 'YYY/ZZZ'. Install the profile (by dragging and dropping it onto Xcode's dock item) or select a different one in the General tab of the target editor.
However, when opening manually the XCode project and trying to archive, it works perfectly.
What am I missing? How can I get the full list of team/provisionning_profile installed on my Mac?
What I have tried so far :
I tried to remove the part where I specify the development team and provisionning profile, leaving only the scheme identifier. Same result considering the scheme is defined with the same informations.
I tried to go in my mobileprovision folder to check if the provisionning profile exists (it exists)
I tried to display the xcode archive command lines in the editor (On the Report navigator tab). Actually it never shows the xcodebuild command directly but a bunch of subcommands. However I could find out that my XXX team identifier and YYY provisionning profile that I am using are using in this script
Does anyone know how I can solve this issue?
I finally found the problem, it came from the sudo before xcodebuild.
The sudo command will run the following action under the root user by default, which doesn't have any provisioning profile installed, as I always registered them under my user profile.
here is what I did :
sudo -u myuser xcodebuild -scheme MyScheme -archivePath builds/XXX.xcarchive archive DEVELOPMENT_TEAM=YYY CODE_SIGN_IDENTITY='iPhone Distribution' CODE_SIGN_STYLE='Manual' PROVISIONING_PROFILE_SPECIFIER=ZZZ
and the error disappeared.
Hope this can help someone.
Provisioning profiles are in ~/Library/MobileDevice/Provisioning Profiles/
You could add -allowProvisioningUpdates to allow xcodebuild to "solve" the problem itself, but... ¯_(ツ)_/¯ for how safe/good the result will be. You've specified "manual" so I assume you don't want to do this.
I suspect you are trying to archive the project but only have a development profile installed. Build a Release build of the project from within Xcode and that should get it to download a release (distribution) provisioning profile for you which you can then use from the command line.
Related
I have developed an application for MacOS. I am including notarization process as part of its distribution. I have followed all the steps and I have run:
xcrun altool --notarize-app --primary-bundle-id "${APP_BUNDLE_ID}" --username "${APPLE_DEV_ID}" --password "${DEV_APP_SPECIFIC_PASSWORD}" --file "${DMG_PATH}"
Then I check notarization progress using:
xcrun altool --notarization-info "${notarize_uuid}" -u "${APPLE_DEV_ID}" -p "${DEV_APP_SPECIFIC_PASSWORD}
Output of it is:
RequestUUID: =<Request>
Date: 2019-05-26 09:40:34 +0000
Status: success
LogFileURL: <Log file>
Status Code: 0
Status Message: Package Approved =~ success ]]
Then I launch staple command:
xcrun stapler staple -v <dmg file>
It also ends with success:
The staple and validate action worked!
However when I extract the .app file and run:
spctl --assess --verbose ./macos/MyApp.app
./macos/MyApp.app/: accepted
According to the docs I have read it should say something like: “source=Notarized Developer ID”, right?
I am running this on MacOS Mojave 10.14.5
What am I missing??
Could someone help me?
Thanks in advance
In case someone faces the same problem I will post the solution to this:
First of all you must staple .app file not the dmg. This means you must extract the binary and staple it
Also in order to check if application has been notarized, in
`System Preferences - Security and Privacy`
Option Allow apps downloaded from: must have Apple Store and identifier developers option checked
Hope this helps
Both the app and the dmg may be notarized and stapled, seperately, one after the other. Try doing that and the error should go away.
Short answer
It could be due to an RPATH referencing a path outside the App bundle. Removing this RPATH would resolve the issue.
Inspecting log files
You can find extra information about the rejection (after trying to launch the blocked app) in the Console.app. Note that you should open the Console.app, before trying to open your blocked app, otherwise not all messages may be logged. You should look for process XprotectService in the logs of your device (i.e. choose your device in the left side bar of the Console.app). If the RPATH is indeed the problem, you should find a record like this:
XprotectService: [com.apple.xprotect:xprotect] File /path/to/your/executable/or/library failed on rPathCmd /rpath/causing/the/problem (rpath resolved to: (path not found), bundleURL: /path/to/your/bundle.app)
Inspecting these log files may give you a key to solve other issues too.
Note that I received the following information from an Apple engineer:
Gatekeeper does not inform users via UI about the specifics of the
error, though it is in the logs for developers to look at. The
notarization process is purely about a detecting malicious software
and does not replicate Gatekeeper enforcement. You still need to get
software notarized and test with Gatekeeper.
We are looking to provide better tooling for developers in the future
to pre-flight some of these common errors.
Contact Apple
If you are not able to solve your issue with the above information, you may want to contact Apple itself using the Feedback Assistant. They do not respond very quickly (~1-2 weeks), but the answers are rather to the point.
Since upgrading to Xcode 8, when I do a build with fastlane, I get the following error message:
There does not seem to be a CURRENT_PROJECT_VERSION key set for this project
If I go to Xcode > Build Settings and go down to Versioning, there is a Current Project Version key, as shown below:
The help text says to enter an integer or floating point number, but when I click on the field, there is no opportunity to enter a number in either the Debug or Release field. This is different from the screen shot shown in this apple tech Q&A so there appears to have been a change in Xcode since the Q&A was released.
Don't. Modify the values in your app's info.plist file instead.
This means not using agvtool (as I learned).
Why? Over the years, Apple has come up with several manners of changing version and build numbers. Many of them are now outdated and poor practice. Changing CURRENT_PROJECT_VERSION modifies values within your project's project.pbxproj file and if you are running a distributed team, this will cause merge conflicts if the other half of the team tries to update and while they were asleep, you updated this internal value. If you are using pods, you'll get several more merge conflicts per pod that you add to the project.
So, CURRENT_PROJECT_VERSION?
Don't use it.
Within the info.plist file are these keys.
CFBundleVersion
CFBundleShortVersionString
Use CFBundleVersion for your app's build number.
Use CFBundleShortVersionString for your app's version number.
Use Plistbuddy to do it.
<key>CFBundleShortVersionString</key>
<string>3.0.7</string>
<key>CFBundleVersion</key>
<string>934</string>
</dict>
</plist>
Try the script below.
#!/bin/sh
# To make executable, use: chmod u+x Build-Versioning-Scripts/Increment_Build_Number.sh
# to locate your target's info.plist use
# ${PRODUCT_SETTINGS_PATH}
echo "----"
echo "Info.plist for target: ${PRODUCT_SETTINGS_PATH}"
buildNum=$(/usr/libexec/Plistbuddy -c "Print CFBundleVersion" "${PRODUCT_SETTINGS_PATH}")
echo "Current build #: $buildNum"
if [ -z "$buildNum" ]; then
echo "No build number found in $PRODUCT_SETTINGS_PATH"
exit 2
fi
buildNum=$(expr $buildNum + 1)
echo "Build # incremented to: $buildNum"
/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNum" "$PRODUCT_SETTINGS_PATH"
echo "----"
exit 0
By adding this script to your build or archive process on your build machine, this will automatically update the app's build number.
If you wish to increment your app's version number, change CFBundleShortVersionString (Bundle versions string, short) in the info.plist manually.
Currently when you get that fastlane error, terminal logs redirects you to
Automating Version and Build Numbers Using agvtool
to understand what you need to do.
Summary
Enable agvtool.
Build Settings > Current Project Version > $(CURRENT_PROJECT_VERSION)
Build Settings > Versioning System > Apple Generic
Set up your version and build numbers.
Target > Info > Bundle versions string, short (CFBundleShortVersionString) > "your init
version"
Target > Info > Bundle version (CFBundleVersion) > "your
init value"
That helps me a lot.
you may try change project format ?
I suggest you can change this xcode format version.
I've updated recently to XCode 6.3 and started having some strange code signing issues. Occasionally XCode will start complain about the code signing issues. And either will have issue like :
invalid or unsupported format for signature ... Command /usr/bin/codesign failed with exit code 1
or
... Command /usr/bin/codesign failed with exit code 11
Can not find pattern yet, but looks like issue with XCode code sign, as sometimes after cleanup and restart of XCode it will work.
I did not change any settings regarding code signing. Project structure is quite complicated, it has referenced projects and pods.
Any help appreciated.
** Update **
It did not help for me to remove derived data or restarting XCode.
But it did work if i removed the project and downloaded fresh from git. This removed XCode files which are not committed to git.
Again after clean it has stopped working. And in the console logs i've got something like this:
codesign[4111]: Internal error unloading bundle CFBundle 0x7fb44a40adc0 <(null)> (framework, not loaded)
** Another Update **
Found on twitter someone who has the same issue.
Looks like the issue is caused by --deep option in code signing.
https://github.com/atom/atom-shell/issues/1396
Solution is to not code sign app and frameworks inside with --deep. But rather code sign each framework separately.
http://furbo.org/2013/10/17/code-signing-and-mavericks/
Just had this happen to me as well after the latest X-Code update. But X-Code had been advising me to update my project settings for a while now, I just hadn't got round to it. The link you provide explains it well.
It actually shows up as an issue in the navigator, and X-Code will offer to fix it automatically for you when you select the issue. You just need to remove the --deep option from your Build Settings yourself.
This worked with my 2 3rd party frameworks, Sparkle and Syphon.
Problem was caused by --deep code signing option and entitlements.
To solve it i had to manually code sign the frameworks.
This required adding new run script build phase, and running script similar to this one:
IDENTITY="HEX_IDENTITY"
export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate"
FRAMEWORKS_LOCATION="${BUILT_PRODUCTS_DIR}"/"${FRAMEWORKS_FOLDER_PATH}"
EXECUTABLES_LOCATION="${BUILT_PRODUCTS_DIR}"/"${EXECUTABLE_FOLDER_PATH}"
codesign --verbose --force --deep --verify --sign "$IDENTITY" "$EXECUTABLES_LOCATION/MY_HELPER_APP.app"
codesign --verbose --force --deep --verify --sign "$IDENTITY" "$FRAMEWORKS_LOCATION/MY_FRAMEWORK/Versions/A"
HEX_IDENTITY can be obtained by using shell command:
security find-identity
This will display list of signing identities with their hex numbers.
After exporting application as the app I verified the code signing with command:
codesign --verify --verbose --deep MyApp.app
spctl --verbose --assess --type execute MyApp.app
References:
http://furbo.org/2013/10/17/code-signing-and-mavericks/
https://developer.apple.com/library/mac/technotes/tn2206/_index.html
So I would like to use xcodebuild in Terminal to create a build from a test application (called RunTeszt1). The app is an iOS single view application with nothing in it, just created and closed.
When I this from the Terminal, the build fails.
xcodebuild -target "RunTeszt1" -sdk "$iphoneos5" -configuration Debug
The error is:
Unable to read diagnostics from file "/var/folders/6s/cjw35hhs5lb6wpnx9m8lr2km0000gn/C/com.apple.Xcode.501/SharedPrecompiledHeaders/RunTeszt1-Prefix-eqntxoxxhhlzvieuipqbxfumbpxb/RunTeszt1-Prefix.pch.dia" (Invalid File): Bad header in diagnostics file
Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide.
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1
When I run the app from XCode (4.4.1), the build completes and everything is ok. However, If I run the Console app and inspect the results after hitting build button in XCode, I see the same error message in the console. Nevertheless the build succeeds and opens the simulator.
Is this really a bug in xcodebuild which should be sent to apple? If it is I imagine a bunch of people already sent it.
How can I either make the error go away, or stop it from cancelling the building process, so circumvent it like XCode does?
Turns out the problem was code signing. Even though I put Don't code sign in the build settings, it still hanged up on it. Also it seems "-sdk xxx" was also at fault (no matter what sdk I specified).
Running this command resulted in a successful build:
xcodebuild clean build CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO -target RunTeszt2
I'm trying to get my application, which does not appear in the Dock, to have an option to launch at login. This is tricky, and involves creating a second, helper application which you add as a startup item. This helper app is only responsible for launching the main app and then exiting.
I've followed the instructions here and here and it works like a charm - the problem is, of course, code signing. I have two targets; the helper app target is copied to the Contents/Library/LoginItems subdirectory of the main bundle at compile time. Each bundle has its own bundle identifier and own deployment provisioning profile, but when I validate my archive for the app store, I get the following error:
Invalid provisioning profile. The provisioning profile included in the bundle BUNDLE NAME [BUNDLE NAME.app] is invalid. For more information, visit the Mac OS Developer Portal.
If I remove the helper bundle from my main target, there's no problem. It looks like the presence of another provisioning profile is setting off the error.
How can I include two signed bundles and pass the validation?
I was finally able to resolve this problem by using codesign on a coworker's computer (there must have been something wrong with my Keychain) and deleting the embedded.provisionprofile file from the helper app by adding the following run script:
if [ -f "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Contents/embedded.provisionprofile" ];
then
rm "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Contents/embedded.provisionprofile"
echo "Removed embedded provisioning profile."
else
echo "No profile found"
fi
You should use the same Mac App Store Production Certificate to sign both the helper app and the main application. I haven't tried this in Xcode — we have a helper app that's a bundle resource, but our code signing is a command line script. We didn't have any problems with the app store system.
I'm not sure why you're ending up with a provisioning profile in the built product, and I don't think this is required for app store submission. You can try using codesign manually:
codesign -f -s "3rd Party Mac Developer Application: My Company" \
-i "com.mycompany.loginitem" \
--entitlements path/to/loginitem.entitlements" \
path/to/appname.app/Contents/Library/LoginItems/loginitem.app
codesign -f -s "3rd Party Mac Developer Application: My Company" \
-i "com.mycompany.appname" \
--entitlements path/to/app.entitlements" \
path/to/appname.app
I had the same problem. Instead of removing embedded.provisionprofile from the helper app I've just disabled provisioning (Provision profile: None) leaving code signing identify and entitlements in place. Submitted my app for review without any issues.