“codesign”

I propose that we collectively build a list of most wanted XCode features. Those pain points that do make our life more difficult with XCode or less fun.The goal would not be to have a scientifically correct ranking of all those, but simply:- make visible many ideas that have probably been reported in improvement requests- expose in short why that would be a great evolution, what pain point it would solve (functional improvements, not bugs correction)- if possible, discuss the feasibility of each idea.I would agree to update this original post to include new inputs.To avoid a thread where new posts get smaller and smaller in width, would be great to post each new idea as an answer to this original post. Of course discuss an idea as a reply to this idea post itself.Rule of the game would be tolerance, not trying to argue indefinitely on one idea. And be concise in wanted feature descriptionThe ultimate goal would be to influence positively XCode development team to consider the most wanted proposals.At least,

Hi, I am brand new to Xcode and I keep on getting an error message saying Command CodeSign failed with a nonzero exit code. I am not enrolled in the Apple Developer Program. Does anyone know how to fix this?

Hello, I am trying without luck to create a .dmg or .pkg for my electron app that can be opened by any user on a mac. Every time I fail. All is happening by the same pattern. Here is the last try with creating a .pkg instead of .dmg. The app is built and it is signed correctly (I suppose) codesign --verify --verbose=1 dist/mac-universal/VIVIDTIME.app dist/mac-universal/VIVIDTIME.app: valid on disk dist/mac-universal/VIVIDTIME.app: satisfies its Designated Requirement I created a .pkg pkgbuild --root dist/mac-universal/VIVIDTIME.app --install-location /Applications/VIVIDTIME.app --identifier app.vividtime.mac --version 1.1.0 --sign Developer ID Installer: Pavel Bochkov-Rastopchin (2QKDCTR5Y3) dist/VIVIDTIME.pkg pkgbuild: Inferring bundle components from contents of dist/mac-universal/VIVIDTIME.app pkgbuild: Adding component at Contents/Frameworks/Mantle.framework pkgbuild: Adding component at Contents/Frameworks/VIVIDTIME Helper.app pkgbuild: Adding component at Contents/Frameworks/VIVIDTIME Help

Hi, I develop a Mac application, initially on Catalina/Xcode12, but I recently upgrade to Monterey/Xcode13. I'm about to publish a new version: on Monterey all works as expected, but when I try the app on Sequoia, as a last step before uploading to the App Store, I encountered some weird security issues: The main symptom is that it's no longer possible to save any file from the app using the Save panel, although the User Select File entitlement is set to Read/Write. I've tried reinstalling different versions of the app, including the most recent downloaded from TestFlight. But, whatever the version, any try to save using the panel (e.g. on the desktop) results in a warning telling that I don't have authorization to record the file to that folder. Moreover, when I type spctl -a -t exec -v /Applications/***.app in the terminal, it returns rejected, even when the application has been installed by TestFlight. An EtreCheck report tells that my app is not signed, while codesign -dv /Applications/***.app re

I am trying to get a PKG installer through the Apple codesign and notarytool process. When I submit the PKG installer I get a status message of Invalid and when I review the log file it has 2 errors. For status summary it says: Archive contains critical validation errors, and for message it says The binary is not signed. The installer contains a flat file that is installed in the Users/Shared folder via the PKG installer. Here are the steps I've taken to get the installer through the codesign and notarytool process. codesign the file that's placed in the Users/Shared folder: codesign --options=runtime --sign 'Developer ID Application: XYZ' -v /Users/.../Documents/folder/flat file which I get a message saying signed generic. Create the PKG installer with the signed flat file. Sign the PKG installer containing the signed flat file: codesign --options=runtime --sign 'Developer ID Application: XYZ' -v /Users/.../Documents/folder/flat file which I get a message saying s

I'm about at my wit's end trying to figure out why I can sign and notarize code, but am unable to staple the notarization, no matter what I do. I've reinstalled Xcode, reinstalled certificates, and tried about every suggestion that I can find, but still no luck. 2023 M3 MacBook Pro, OS X 15.3.1, Xcode 16.2. I have created a very basic Xcode app to test this with. I am building the project: codegen generate && xcodebuild -project SimpleNotarizationTest.xcodeproj -scheme SimpleNotarizationTest -configuration Release clean build (see attached file for build log) build-log.txt The signature and entitlements verify: codesign -d --entitlements :- ~/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-*/Build/Products/Release/SimpleNotarizationTest.app Output: Executable=/Users/minter/Library/Developer/Xcode/DerivedData/SimpleNotarizationTest-ecqihdiubptfnldimmjgnqpjr xun/Build/Products/Release/SimpleNotarizationTest.app/Contents/MacOS/SimpleNotarizationTest warning: Specifying ':' in the path

We have a MacOS application that we plan on distributing standalone (it'll be installed through MDM or directly, not through the app store). We utilize endpoint security and full disk access for this (enterprise) app. I have a makefile that uses codesign to sign the app inside-out. All that appears to work (i.e., when I try to run the app directly it functions as I expect it to). What's the recommended way to allow the developers in my team to also sign the app for local development so it functions as close as possible to production? My first thought is to distribute the developer identity to their machines using MDM. However, ideally i'd like to rule out the ability for a developer who has the MDM profile assigned to export the keys. That really only leaves a centralized solution in place or disabling SIP on their system (which I don't want to do). Alternatively, would creating a separate identity for production make more sense, so that in the case the developer certificate is revoked, the productio