Struggling to constuct complete command line build

By the way, I tried using codesign but that just tells me that it is replacing the existing signature, presumably meaning that the bundle is already signed.

though I am unclear about the exportOptionsPlist and whether I created that correctly

That’s the most likely cause of this problem. Given that things work in Xcode, my advice is as follows:

1. In the Xcode organizer, select an archive that works.

2. Click Distribute App and follow the Developer ID > Export workflow.

The resulting directory contains an ExportOptions.plist that you can pass to xcodebuild.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks for responding.

Unfortunately, that's not the issue I had already tried that - I noted that while the main app got signed (so I didn't need to invoke codesign myself), a bunch of other stuff such as the sparkle framework did not seem to be signed - or at least the notarization failed with such messages as

    {
      "severity": "error",
      "code": null,
      "path": "GigPerformer4.zip/GigPerformer4.app/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/Autoupdate.app/Contents/MacOS/fileop",
      "message": "The binary is not signed with a valid Developer ID certificate.",
      "docUrl": null,
      "architecture": "x86_64"
    },


  {
      "severity": "error",
      "code": null,
      "path": "GigPerformer4.zip/GigPerformer4.app/Contents/Resources/grplscn",
      "message": "The signature does not include a secure timestamp.",
      "docUrl": null,
      "architecture": "x86_64"
    },

Yet, if I just archive from xcode and go through the "Developer ID (Distribute directly to customers)" process, I can upload to Apple notary service and the whole thing gets notarized properly

I might add that during that process I'm informed that no profile is required for sparkle, grplscn etc)

I'd be happy to pay someone a few hundred dollars to help me get this fixed but so far I haven't found anyone who seems to know how this all works.

a bunch of other stuff … did not seem to be signed

I suspect that part of this issue is that these code items are not placed according to the rules described in Placing Content in a Bundle. Some of that you can’t fix, but you should definitely fix grplscn.

Having said that, I would export -exportArchive to handle this as well as Xcode, and things are working on the Xcode side of things. I’m not sure what’s going on there. I recommend that you open a DTS tech support incident so that one of us can look into this in more depth.

I'd be happy to pay someone a few hundred dollars

We’re way cheaper than that (-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I suspect that part of this issue is that these code items are not placed according to the rules

Pretty sure everything is in the right place. But if they were not, why would everything work perfectly when archiving from Xcode?

Having said that, I would export -exportArchive to handle this as well as Xcode

Well, I have the entry

/usr/bin/xcodebuild -exportArchive -archivePath "$ARCHIVE_PATH" -exportOptionsPlist "$EXPORT_OPTIONS" -exportPath "$EXPORT_PATH" -allowProvisioningUpdates

but that doesn't seem to do anything.

I recommend that you open a DTS tech support incident

I did open a DTS tech support incident at the beginning of the week but never heard from anyone.

We’re way cheaper than that (-:

Unfortunately, my time isn't, so paying someone to help get this fixed would be worth it for me :-) This issue is a major distraction from the development work I actually need to do. It's something that an expert could probably fix in a few minutes but I've spent days on it.

I do however appreciate your continued responses.

what's the typical wait time before I should hear back?

DTS aims to send an initial response within three business days [1], although we usually do better than that.

Did you get an auto ACK with an incident number?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] You can find this and other tidbits on our page on the developer web site.

1. Thanks for all the help, specially from the Eskimo! I'm up and running properly now from the command line. I tried to make the process far more complicated than it actually needed to be.

2. Question about notarization. After I have archived/codesigned via xcodebuild, I make a zip file which is uploaded to Apple by xcrun notarytool. During the notarization process, does that zip file or any of its contents get modified? In other words, do I have to wait for the notarization to finish or can I extract the application from the zip file and continue building my installer?

I'm up and running properly now from the command line.

Yay!

After I have archived/codesigned via xcodebuild, I make a zip file which is uploaded to Apple by xcrun notarytool. During the notarization process, does that zip file or any of its contents get modified?

No. Notarisation is a read-only process. You submit a file to the notary service and the notary service generates a ticket and stores it on Apple’s servers. None of that modifies your original file.

Having said that, best practice is to staple the ticket to your product before you ship it, and so you generally want to wait for notarisation to complete before proceeding. This is one of the shiny new features in notarytool, namely the --wait option for the submit command.

and continue building my installer?

Hmmm, that’s a concern. Our general recommendation is that you notarise your outermost container. So, if you’re building an installer package (.pkg) that includes your app then we recommend that you notarise the package itself. The resulting ticket will cover the package and all its contents.

If you’re building some other type of installer, things get more nuanced (-:

So, what type of installer are you building here?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hmm, how do I "staple the ticket" to my product? Presumably this is not something done by the notarisation process (if it was, then notarisation would not be a read-only process"

Also, one thing to watch out for is warnings and references that are due to Xcode plugins that are no longer "supported"

I was getting bizarre warning messages mentioning a DVT framework which made no sense to me until I looked more closely and realized that they were due to some legacy plugins that were buried deep in an Xcode plugin folder (see below). Removing those plugins eliminated those warning messages.

2022-03-09 12:39:45.860 xcodebuild[46445:2278107] [MT] PluginLoading: Required plug-in compatibility UUID 7A3A18B7-4C08-46F0-A96A-AB686D315DF0 for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/XBookmark.xcplugin' not present in DVTPlugInCompatibilityUUIDs
2022-03-09 12:39:45.861 xcodebuild[46445:2278107] [MT] PluginLoading: Required plug-in compatibility UUID 7A3A18B7-4C08-46F0-A96A-AB686D315DF0 for plug-in at path '~/Library/Application Support/Developer/Shared/Xcode/Plug-ins/Alcatraz.xcplugin' not present in DVTPlugInCompatibilityUUIDs

how do I "staple the ticket" to my product?

Using a stapler (-:

Seriously though, my Packaging Mac Software for Distribution post shows how to do this and has links to the official docs for it. Ssee the Staple Your Product section, right at the end.

Presumably this is not something done by the notarisation process (if it was, then notarisation would not be a read-only process")

That’s absolutely correct.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"