Congratulations on your hard work coming to a good stage!
One thing that I think is important to accommodate, this early in your game, is the separation of development environments and build/release environments.
Right now you’re probably using your personal development machine for all the coding, building, and production of a distributable.
Take some time at this point to step back, and build yourself another environment, which you only use for producing customer-targeted distributables.
The way you should do this (imho) is to get yourself two VM’s - one for MacOS builds, and one for Windows builds. Set them up to do one thing, and one thing only: build, package, sign and notarize your plugin. Join your development environment with the ‘builder’ environment through a git repository - that way, you can develop freely and independently from the distributable/packaging environment, and your VM’s will be ready to deliver to customers.
This might seem like a lot of work, but it will let you separate concerns - development and release - in a clean and productive manner.
This might also mean you have to convert your project to use CMake, and then do all the things to get CMake builds working properly on your builder VM’s for both MacOS and Windows. Do not be daunted by the effort to do this - it can be done, and its actually quite simple if you take each step methodically. Convert the project to CMake, add platform-specific configuration to your CMake, get your development environments set up in the builder VM’s, get them building the plugin successfully, and then move on to packaging.
You can learn a lot from @sudara’s github actions in his pamplejuce project (GitHub - sudara/pamplejuce: A JUCE audio plugin template. JUCE 8, Catch2, Pluginval, macOS notarization, Azure Trusted Signing, Github Actions) - or indeed, you could use pamplejuce as a base into which you can refactor your project (maybe its as simple as copying your Source/* files into a pamplejuce project fork, and then updating the resources for your needs .. who knows ..) - but either way, pamplejuce is a good place to start, since github-actions preclude the need to set up an entire VM machine, and you could do your releases directly from Github.
Either way, do not be intimidated by this phase of things - take it as an objective ‘next step’ in your development process to build the pipeline. I started with a pamplejuce-derived scaffolding project, and then once I got it working, I converted it to use my own locally administered VM’s instead of relying on Github - the only painful aspect of this was understanding the certification and notifcation heuristics for both Windows and MacOS, and then writing a script for each of the stages - build, packaging, signing, notarization - with the end result being .exe/.pkg redistributables which pop out of the end of my automatic pipeline whenever I trigger a ‘release build’ from my development environment.
But yes, either way you look at it, you will need to invest time/materials/money in the developer licensing that is a prerequisite for “authentic” notarization from Apple, and equivalent certification on the Windows builder side of things. But, either way, do check out pamplejuce if you haven’nt, especially the .github/workflows/build_and_test.yml file, which describes a lot of the steps you should take in order to produce proper redistributables.
If you need help with any of this, reach out - a lot of us have taken these steps with success …
