What does HackerNews think of gon?

Sign, notarize, and package macOS CLI tools and applications written in any language. Available as both a CLI and a Go library.

Language: Go

#4 in Maven
#56 in Go
#60 in macOS
Sickcodes/Docker-OS X: Run macOS VM in a Docker | Jan 2023
Expand Context ↕
It might be less effort to use something like this: https://gregoryszorc.com/blog/2021/04/14/pure-rust-implement...

Might even be able to modify `gon` to use that instead of Apple's `codesign` and then you'll have notarization too: https://github.com/mitchellh/gon
Achieving an open-source implementation of Apple Code Signing and notarization | Aug 2022
I’ve always used gon ( https://github.com/mitchellh/gon ) for this, which is open source golang, but I don’t think it supports mach-o embedding. I’ll have to try this tool out.
Apple’s Notarizing | Apr 2021
My advice from years of notarizing my apps is to make sure you do it at least once per day for each of your apps. If you only notarize once every release (say, every month or so), you are almost guaranteed to encounter some new cryptic error that you've never seen before, either due to some glitch in signing your app or frameworks, or else some server-side error such as new terms & conditions that you are being "encouraged" to agree to. It will take you hours to research and resolve them if they aren't spotted right away.

As others pointed out, https://github.com/mitchellh/gon is a great tool for doing this on your local machine (e.g., with a cron job). In addition, if you are building your app using a GitHub action (which I highly recommend if it is open-source), you can use my https://github.com/hubomatic/hubomat action to package, notarize, and staple a release build in one shot. The sample/template app does this automatically on every commit as well as once per day: https://github.com/hubomatic/MicroVector/actions.

So when this fails from a scheduled job, you at least know that something has changed on the Apple side and can investigate that right away. And if it fails as a result of a commit, then at least you can start looking at what changes you may have made to your entitlements or code signing settings or embedded frameworks or any of the other million things that can cause it to fail.

Apple’s Notarizing | Apr 2021
And, not mentioned in the article... you have to have an Apple Developer ID which costs £79/year ($99). Presumably if your subscription lapses any previously released software will stop working?

That is the part I find most offensive, if it was just difficult and buggy I would suck it up and work around it. But having to pay for the privilege is too painful, particularly if you're offering free software.

For my case (non GUI app) I can at least distribute via Homebrew and have the user build from source in a more or less automated way.

Another notarization helper tool is here https://github.com/mitchellh/gon