Oh, thank you so much 
This has all been very helpful. Thanks! However, I am wondering about distributing updates. What does notarization make “note” of? If I distribute a MyAmazingApp.app v1.0.0 properly code signed and notarized, how do I release v1.0.1 and yet still allow v1.0.0 to be distributed and run?
Versions shouldn’t cause any problems. When you staple your app, the ticket that’s stapled to it contains a hash of all its executables as calculated from the upload, and Gatekeeper will compare that with what it presumably calculates itself.
How and when any other checks are done is unknown at this stage, and will probably (a) change and (b) be purposely kept obscure.
Further to the question of versions, this is what of the Apple team wrote on their developer forums:
We encourage developers to upload all the macOS software they distribute, including versions previously released. This helps users of older versions of your software and helps us improve as well.
I have a problem that stops me from beginning with notarization. It is maybe a bit off topic for this thread – but a would appreciate any suggestions.
I have två apple-id:s: One is my private account, which all my devices including my workplace computer is logged into, and another that I use as developer ID in my work. That’s the way I want it to be. Since my workplace Mac is connected to my private account, my keychains, my files on iCloud Drive and so on are always in synch between work and home. I don’t want to merge the two accounts into one, and I think it would also be some technical obstacles in doing that.
Now notarization demands app specific passwords, which in turn demands the Apple ID uses two factor authentication. But – as I understand it – two factor authentication demands that at least one Apple device is connected to iCloud with that Apple ID. When I’m logged in at my Apple ID account page with my developer ID, the alternative to create two factor authentication is not present. Two step verification is the only available choice, and the reason seems to be that I have no device connected to iCloud with that account.
So my fear is that I can’t begin to notarize my apps unless I mix my private and professional world – ether use my developer ID for iCloud och vice versa – which Is really unwanted. Or did I misunderstand something? Is there a workaround?
(BTW, thanks for that tool, Shane.)
According to Apple you need a trusted device: “A trusted device is an iPhone, iPad, or iPod touch with iOS 9 and later, or a Mac with OS X El Capitan and later that you’ve already signed in to using two-factor authentication.”
And: “Once signed in, you won’t be asked for a verification code on that device again unless you sign out completely, erase the device, or need to change your password for security reasons. When you sign in on the web, you can choose to trust your browser, so you won’t be asked for a verification code the next time you sign in from that computer.”
To be clear, the actual notarization process uses the app-specific password, so there’s no authentication involved at that point. So perhaps you can set it up by changing iCloud accounts temporarily, perhaps even on another Mac at work.
Thanks for the clarification, Shane. Considering that, your suggested solution should work.
A quick note: SD Notary will need an update to work properly with 10.14.5. It’s in the works.
1 Like
And released as version 1.0.1:
Here’s a script to automate the submission process from Script Debugger. Note that if you are going to notarize an app, there’s no need to turn codesigning on in Debugger — notarizing requires a deeper form of code-signing.
set docNumber to 1 -- change for testing
tell application id "com.latenightsw.ScriptDebugger7" -- Script Debugger.app
set theDoc to file spec of document docNumber
-- build file object for run-only version
set newDoc to my makeRunOnlyFile(theDoc)
-- export run-only version
save document docNumber as script application in newDoc with run only and bundle run only
end tell
tell application id "com.latenightsw.Script-Notary" -- SD Notary.app
try
with timeout of 1 second -- we just want to get it started, so we can get on with other things
-- submit try notarizing
submit app newDoc with showing dialogs -- dialogs will let us know when it's done
end timeout
end try
end tell
-- Handler to take file of open document and create file for run-only version. Modify to suit your naming convention.
on makeRunOnlyFile(theDoc)
set docPath to theDoc as text
set {saveTID, AppleScript's text item delimiters} to {AppleScript's text item delimiters, {":"}}
set theParts to text items of docPath
set AppleScript's text item delimiters to {"."}
set oldStubName to text 1 thru text item -2 of (item -2 of theParts)
set newName to oldStubName & " Run-Only.app" -- !!! Choose your own scheme here
set theParts to items 1 thru -3 of theParts & newName
set AppleScript's text item delimiters to {":"}
set newPath to theParts as text
set AppleScript's text item delimiters to saveTID
return (newPath as «class furl»)
end makeRunOnlyFile
Obviously you will need to modify the makeRunOnlyFile() handler to suit. My personal style is to save editable versions with an underscore before the extension, and remove it for the distribution version.
The only limitation is you can only have one file being notarized at once.
Thanks for the update. As I hate Apps without an icon I created one myself. 
Feel free to use it.
SD Notarize.icns.zip (558.8 KB)
Thanks for the icon! We are working on a few ideas for an SD Notary icon and I’ll add this to the mix.
As an applescripter not acquainted with programming in general, there are a lot about notarization that I don’t fully understand. I therefore have som questions of practical interest, that I would be happy for any clarification about:
• Using SD Notary there is a “Staple Only…”-choice. When is it useful to use that button? Is it only necessary to submit a first version of an applet?
• How is the files that are created along with the notarized applet – the RequestUUID file (ticket?) and the Entitlements.plist – intended to be used? Do I have to somehow attach them when distributing the applet? Must I keep them in place?
(In my case the applets I make is for in-house use only, and they are not distributed using disk images but copied using deploy tools.)
You use it if you have submitted an app but the process has been interrupted. You might have shut down the computer, or lost your connection, or Apple’s server might be having a bad day. So you use it to staple a copy that has already been submitted.
The RequestUUID is not the ticket, but it’s a number Apple uses to refer to your app. If you press Fetch History, you will see your submissions listed by Request UUID; having it recorded in a file lets you make sense of the history list.
The entitlements file is used in the code-signing, and is based on which of the checkboxes you checked in the Entitlements tab view. It’s kept as a record, in case you want to check what you allowed for an app.
1 Like
Thank you for this tool. It works perfectly with the relatively simple AppleScript apps I tested. One thing that may be useful for other people: If your script apps include unix binaries, it seems necessary to codesign them separately before using SD Notary. If I don’t codesign the unix binaries separately, then the script app won’t get notarized – even though SD Notary says it is signing the unix binaries.
I don’t pretend to understand why this is necessary, or whether I’m misreading the situation.
You shouldn’t have to, if they’re stored where code should be stored in a bundle. Could you email me an example where it fails (an unsigned version)?
An Enhanced applet is a good example — the Sparkle framework also includes an extra executable.
Apologies: I got confused about what my problem was. Everything I said about having to sign binaries was mistaken - I was muddling up two scripts. The actual problem I’m having seems to be that one of my scripts uses a unix binary that requires various dylib files in the same folder. I have all of these in the Contents->Resources->Files folder. The log tells me that all of these are unsigned. I’ll be glad to send this, but is there any chance that SD Notary can sign dylib files in the same folder with binaries? (And how would I send you the script if you want it?)
Email me and I’ll have a look.
Hello Shane, I just realized that I tried to e-mail at a “noreply” address. Is there some way I could find a direct address? Thank you again for offering to look at this.
OK, I’ve had a go at notarizing your app. SD Notary 1.0.1 doesn’t sign .dylib files, but the next version will. However, your app still fails with this error:
"logFormatVersion": 1,
"jobId": "047fd535-f78d-4d93-96af-4567200a7d06",
"status": "Invalid",
"statusSummary": "Archive contains critical validation errors",
"statusCode": 4000,
"archiveFilename": "WPExport.zip",
"uploadDate": "2019-05-23T12:21:19Z",
"sha256": "9c377f34d5227b0ce476146b0b63ec04fcb73a386eca663399fe1a988b7cc771",
"ticketContents": null,
"issues": [
{
"severity": "error",
"code": null,
"path": "WPExport.zip/WPExport.app/Contents/Resources/Files/rsvg-convert/libxml2.2.dylib",
"message": "The binary uses an SDK older than the 10.9 SDK.",
"docUrl": null,
"architecture": "x86_64"
},
{
"severity": "error",
"code": null,
"path": "WPExport.zip/WPExport.app/Contents/Resources/Files/rsvg-convert/libiconv.2.dylib",
"message": "The binary uses an SDK older than the 10.9 SDK.",
"docUrl": null,
"architecture": "x86_64"
}
Apple won’t notarize code built on very old SDKs.
The other thing you might look at is where you store your libraries. Look up apple’s tech note TN2206: code shouldn’t really be in /Contents/Resources. It doesn’t produce an error at this point, but I’d be inclined to follow apple’s guidelines where possible.