A new SD Notary 2 BETA build is available. You can download it here:
http://www.latenightsw.com/archives/beta_for_script_debugger/SDNotary2-2.0-101.zip
1 Like
Wow, it’s like you’re a mindreader. I have a package of AppleScript apps that I want to distribute to users in a single folder, via a disk image. I was trying to figure out how to notarize all of them but now it looks like Notary 2.0 will do exactly that.
Big thanks!
My plan is to test notarizing each app individually, then the entire dmg first, then try just notarizing the dmg and see if that works.
Let me know if there’s anything in particular you want me to look out for.
in general, you only need to sign the apps first, then copy to dmg, then notarize the dmg. no need to notarize each app separately.
that’s, again, in general - i don’t know how it fits into SD Notary workflow.
That’s correct. Once the .dmg is notarized, all apps on it are covered.
This thread reminded me of what pain it was to figure out how to notarize dmgs back when Apple introduced “notarization” several years ago. Apple’s convoluted endless disjointed instructions on notarization didn’t mention the terms “dmg” and “disk image” even once. That’s while disk image is the most common way of distribution for Mac apps.
I had to score the Internet for pieces of information on dmg notarization posted by other developers who somehow managed to figure it out. Well, at least that was my experience.
Apple improved since then and the usage of the new notarytool was pretty straightforward and easy to understand. Much better than this do-it-yourself IKEA-style pile of disjointed tools and methods that Apple dropped on us in the beginning.
(Sorry for being off-topic as this rant isn’t related to SD Notary in any way).
It would be great if SD Notary 2 wouldn’t launch Xcode.
1 Like
@alldritt:
I get sometimes the error message that Xcode was not found (Suitable Xcode Not Found), although it was started by SD Notary 2 self.
MacBook Pro 2019 - Ventura 13.4 - Xcode 14.3
MacBook Air 2017 - Monterey 12.6.6 - Xcode 14.2
This does not happen at SD Notary.
Otherwise, the beta is already working perfectly fine for me and the process is much faster than before.
Great Job!
Thanks, this will be fixed in the next beta.
Is there a particular reason you don’t want it launched?
The issue is that a lot of the target audience never actually use Xcode, and the launch is to ensure it’s at least been launched at some point and the tools downloaded/updated.
1 Like
I don’t want it launched as it is a memory hog and it slows down my Mac at launch. It also fills up my Dock. I also don’t use Xcode and if it should be launched sometimes, then SD Notary should do it only when needed (outdated tools, first launch, once a year …). It’s also not clear that I can quit Xcode when SD Notary is running.
1 Like
I agree. @ShaneStanley… If Xcode opens too slow it causes an error on Notary, I was just going to report. It just slows the process down. I would have Xcode open if I wanted to use it. The new Notary tool is sooo much faster now! Kill opening Xcode 
I’m not sure what’s required, but I am assuming just Xcodes command line tools would be enough?Couldn’t u check for them or whatever part is required? Just suggestion for an awesome tool!
Also just FYI, it is reporting Xcode 13 is needed sometimes when opening too slow or not open. I have Xcode 14.13 I think it just times out and reports that.
Not without been able to read the future.
The problem is that there are people who use this who never run Xcode, and that means even if gets updated, the tools don’t. And if they don’t, the typical error is not going to be very helpful.
The next beta will check the Xcode build number, and only launch it if there’s been a change.
2 Likes
Just a couple notes.
I like this new version, it seems less fragile than previous. Not as finicky. With the previous version I had given up trying to get it to work on two of my three macs, now it seems to work on all three. (But tested mostly on just one)
I have an applet that lives in a folder, and inside the folder are any number of scripts and applets that the user may run. The user may add scripts to that folder beyond what’s installed, or remove installed scripts. With the previous version of Notary I could not figure out how to distribute this with all the apps notarized in the folder and ready to run.
Notary 2 solved this, pretty easily.
Step one: I signed the applications in the folder. That put them in sub folders, but I put them back in the main folder and discarded the subfolders.
Step two: I made the folder into a dmg (using DropDMG).
Step three: I submitted that with Notary 2
A few notes:
I had to create an appSpecific password twice to get Notary working
I had a couple fail to submit and was a little confused by the UI. The note on the screen said to check the log for the details, and the window on the screen is the log. The Notary process also created a log file that actually had the details I needed. Maybe when it fails the note on the screen should refer users to the log file?
There’s no help file, but maybe just put the release notes in there instead? There is a link to the SD forums, which is nice, but maybe a link to the Notary release notes topic? Or maybe create a Notary help topic?
Bottom line for me is this is an elegant solution to a problem that was more complicated than it needs to be, and the whole thing seems to be working better.
Much thanks!
–>SD Notary 2-- Version 2.0 (101)
The error information is usually the same, apart from some formatting issues. The log file is useful because it doesn’t get cleared, and because it includes a lot more context, such as the actually commands being run.
Roughly speaking, the log on screen should tell you all you need to know when a problem happens, but the log file is useful if you need to consult us, so we can see the context, or if you want to look back later.
OK, when there is an error the user is told to see the log for more detail.
There really are no details in the log in the window (at least for the errors I had). It simply said something like:
“Submission to Apple was unsuccessful.”
I was able to figure out that the problem was an unsigned app in the dmg.
The point is that a user seeing the “more detail in the log” message is not really helped if there’s no helpful details in the log. (Maybe other errors provide more detail?)
Hopefully.
Unfortunately we’re in the hands of Apple, and errors from command-line tool historically tend to the curt. All we can do is pass them on.
How did you figure it out?
Reread the release notes, then looked though the folder and found the unsigned app.
Looked though the logs and plists and stuff and nothing pointed to why it failed.
I’m wondering if it’s possible to pre-flight notarizing via appleScript.
What I’m thinking is a droplet that will examine the contents of a folder, look for all un-signed apps, tell SD Notary to sign them, then make a dmg from the folder and tell SD Notary to submit.
The first question, is there a way to tell if an app is unsigned?
Second question, is signing an already signed app a problem?
Ed, if by “signed” you mean “notarized,” then you can find the way to check whether an app is notarized by looking at this Notarize-Check script:
on run
tell application "Finder" to set f to choose file
processFile(f)
end run
on open f
processFile(f)
end open
on processFile(f)
set filePath to POSIX path of f
-- if filePath ends with "/" then set filePath to text 1 thru -2 of filePath
activate
try
if (do shell script "spctl -a -t exec -vvv " & quoted form of filePath & space & "2>&1") contains "Notarized" then
display dialog filePath & return & return & "is notarized." with title "Success" buttons {"OK"}
else
display dialog filePath & return & return & "is NOT notarized!" with title "Failure" buttons {"OK"}
end if
on error err -- we do nothing with err
display dialog filePath & return & return & "is not notarized." with title "Failure" buttons {"OK"}
end try
end processFile
EDIT: Signing an already-signed app is not a problem.