hubomat
MicroVector
| hubomat | MicroVector | |
|---|---|---|
| 1 | 1 | |
| 3 | 0 | |
| - | - | |
| 5.9 | 0.0 | |
| about 3 years ago | almost 3 years ago | |
| JavaScript | Swift | |
| - | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
hubomat
-
The Gates to Hell: Apples Notarizing
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 and notarize a release 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.
MicroVector
-
The Gates to Hell: Apples Notarizing
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 and notarize a release 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.
What are some alternatives?
corona - Solar2D Game Engine main repository (ex Corona SDK)
xcnotary - the missing macOS app notarization helper, built with Rust
gon - Sign, notarize, and package macOS CLI tools and applications written in any language. Available as both a CLI and a Go library.