Cabbage Logo
Back to Cabbage Site

Distributing plugins on MacOS (Part 2)

#1

tl;dr you need to sign plugins if you want to share them on the latest versions of MacOS. I’ve provided a simple script below that will do this for you once you have Apple credentials.

As most Apple users will know by now, it’s getting harder and harder to distribute software on a Mac that hasn’t be verified by Apple. It means that users wishing to distribute Cabbage plugins on Mac will now need to adhere to Apple’s latest policy regarding signing and notarising of apps. I will also have to start doing the same with Cabbage itself. Anyhow, if you do wish to share plugin bundle with people, you will now need to do the following (take a deep breath…)

  • Sign up for an Apple developer ID, this will cost 99$ yearly. :face_with_symbols_over_mouth:

  • Create a Developer ID Certificate.

  1. Log into your Apple Developer Account and go to Certificates, Identifiers & Profiles .
  2. In the upper-left corner, click + to add.
  3. Under Software, select Developer ID then click Continue .
  4. Click Choose File .
  5. Select the certificate request file you created earlier (a file with a certSigningRequest file extension), then click Choose .
  6. Click Continue .
  7. Click Download .

When this is done, you should have in your KeyChain Access a certificate with a name like "Developer ID Application: R Walsh (4R359YV9BF)

That’s the apple ID stuff taken care of. Now you must do the following for each plugin you will to release.

  • Generate an application/plugin specific password at https://appleid.apple.com/ Click the generate application password link, give the password a general name, i.e, GranularPlugin, and then generate. It will show you a new password. copy and paste it somewhere. Note you never use your regular Apple password here. It’s also app specific ones you need to use.

  • Assuming that you have exported your plugin, relink the binaries. These step is explaining in Distributing Plugins on MacOS Part 1. Note that you should really remove everything from the embedded Csound pacakge that you don’t need. In most case I wipe the contents of the Opcode64 folder too. The less binary files you have in there, the less work you have to do.

  • The next step is to sign and notarise. You must codesign the plugin binaries, and the Csound library binaries. Then you prepare a zip file and upload this to Apple for verification. I use the following script to do this. prepareForDistribution.sh (2.1 KB) I call it like this:

sudo ./prepareForDistribution.sh ~/Library/Audio/Plug-Ins/VST/PluginName.vst PluginName "Developer ID Application: R Walsh (4R359YV9BF)" myAppleIdId my_app_password

  • After the final step, you should get message like this:

    No errors uploading ‘MyPlugin.zip’.
    RequestUUID = bdsf5b-248dfg6-9fa1-33fdgh1778234

  • Now you must check that the verification was Ok. To do this, you can pass the RequestUUID to the xcrun altool command, where RequestUUID below is the RequestUUID code from above. You will need to pass your app-password at this point.

xcrun altool --notarization-info RequestUUID -u myAppleID

Finally, I’ve been testing this with a new universal build of Csound which you can get from here. It’s pretty barebones in that not all plugins are supported, but it’s will run natively on an M1 mac which is nice. Because it’s my own build of Csound, the relink script from the previous post will not work. You need to use this one instead.
relinkCsoundMacOS.sh (2.4 KB)

Of course I’m happy to answer any questions. I wish I could make this process easier, but Apple has put everyone in a real tight corner here. I don’t think we have any choice but to play ball.

1 Like
More macOS issues coming down the line
M1 Cabbage
Packaging custom graphics to work with an AU export
Automatic plugin export with CI/CD: Azure Pipeline workflow
Problem displaying waveform with gentable and problem exporting in .vst
#2

Rory, do you know if this will only be applicable to the latest version of the os? Or is this going to be the model moving forward? Linux may be closer in my future than I thought!

#3

Wow… a lack of foresight of this magnitude in such an important and impactful decision does not indicate intelligent leadership at the helm. It’s a real shame Apple thought this was the best way to solve security problems, and then chose to use it as an excuse for another cash grab at the same time.

I imagine lots of casual developers will abandoned the system very soon. I was already considering it strongly due to such poor support for older hardware and OS versions, but this has absolutely made the decision that much easier and final.

#4

I think the newest versions will enforce this more tightly. Gatekeeper has got progressively aggressive from Catalina onwards but it’s on a different level nowadays.

If I didn’t have to consider Mac users I wouldn’t be using macOS at all.

It might certainly cause developers to think twice, but I don’t think it will have any affect on the typical end user. These new measures have always been in place for developers of iPhone apps. The problem is that you routinely hear stories of Apple removing 3rd part apps from the App Store, only to then release their own versions of the same app. You really have to feel for developers in these cases:


Right now I can still release Cabbage outside of the App Store, but at some point I might be forced to deliver it exclusively from the App Store. This will inevitably lead to a world of pain. :face_with_symbols_over_mouth:

#5

Apple’s software is built on the back of Open Source, sadly it was the BSD license, which allowed for Commercial use, and then Apple found a way to privatize the rest of GNU. I appreciate that Steve Jobs embraced Open Source early on, and he is a big reason for the Open Source movement, but there comes a point when you have to say enough. Apple is one of the worst companies out there.

… Sorry, didn’t mean to get to worked up. Guess I’m just disappointed that I was so wrong about Apple. Just say no!

#6

But that’s part of them ploy to grab more cash. Now with their new hardware being encased in a closed plastic shroud, there will be little to no use for any of their future hardware.

1 Like
#7

And I think that is what Apple is banking on. Sadly, they know that the music industry is quite tied to their computers. They are going to pick everyone’s pockets until they can’t anymore!

#8

For sure. Many have totally bought into the Apple hype and won’t ever give it up. If Apple were a company I trust, I would say this is a genuine move toward better security for their users. But I don’t trust them one bit. And I’m writing this post from my Mac :joy:

3 Likes
#9

wow, so this maybe explains the ‘operation not permitted’ line after the linking process. Thanks, as always, Rory for getting this information up.

1 Like
#10

Thanks very much for this update, Rory. I happened to fall for the Apple trap some months ago and signed up for an Apple Developer account, so I wanted to give this a try but I’m such a neophyte at this, I couldn’t for the life of me get around this.

I understand we can use your script and modify the instructions so as to have our details here:

  • I replaced both paths as I copied my AU plugin into a specific “Releases” folder inside a project folder (I just added your script to that same path for simplicity’s sake).
  • I then added my certificate ID
  • Then my Apple ID
  • Then the password I generated for my app (as per the previous instructions)

…but got a “command not found” when I ran it in the Terminal.

Are we supposed to change the script as well? For example, the last line…

xcrun altool --notarize-app --primary-bundle-id "com.cabbageaudio.CabbagePlugin" --username $APPLE_ID -password "$APP_PASS" --file $PLUGIN_ZIP.zip

…or are we meant for us who are not under Cabbage pro yet, to keep your credentials?

Should the “PluginName” be the same as the name of the app we created when we created the app-specific password?

I know it’s only so easy to ask, but in case you ever find the time, It would be amazing to have a tutorial about this (especially to understand how a script can “invasively” code-sign all the related binaries?).

Either way, thanks very much!

#11

Some comments:

  • You shouldn’t need to modify the script at all, but you can do. You can also change the bundle identify (com.company.product) tag. To be honest, none of this stuff is even visible to the end user.

  • You probably may need to chmod the script so you can run it:

chmod +x prepareForDistribution.sh

  • The PluginName is the name of the plugin binary that resides in the Contents/MacOS/ folder

  • Does you certificate ID looks similar to the one I posted? i.e., “Developer ID Application: R Walsh (4R359YV9BF)” You can get the exact name from the Keychain Access app.

If I find some time. The new semester has just started, and on top of that we have a new family member at home, an extremely small and beautiful little girl. So time is at a premium :slight_smile:

1 Like
#12

Such a shame from them to apply that for open source softwares too…
I won’t pay 99$/y … to distribute a free plugin… that’s so sad for Mac users but they will have to build the future versions of the plugin from themselves now…

#13

I don’t mind signing and notarising open source Cabbage plugins. Just drop me a line.

2 Likes
#14

Thanks! Will give this a shot :slight_smile:

Wow, congratulations!!! Please don’t mind us nerds and may you go play some ukelele for the newcomer instead! Some things I’m sure we can figure out on our own eventually :wink: (and if I ever do figure this code-signing thing out myself, I’ll see to it to post a step-by-step here).
:slight_smile: :slight_smile: :slight_smile:

1 Like
#15

Not totally sure how to do this…

codesign -s "Company Name" " /Applications/Utilities/My App.app"

??

#16

Right back at you :rofl:

1 Like
#17

Oh I see - I didn’t get to that part yet. The instructions sound like you have to sign it first and then run the .sh to get it ready for the Cupertino posse. You’re saying the script will do the signing too?

Thanks for the detailed instructions btw, your efforts are really appreciated.

#18

Yeah, the script should do everything for you, well apart from sign your soul over to Apple. That part is on you :slight_smile: But I’ll update the instructions to make this super clear…

#19

My soul was signed over 3 iphones ago during the reign of “Jobs the Terrible”

Umm - just some more clarification here… are we signing then the actual au and vst package? Or just the binaries within (i.e. CabbagePlugin, CsoundLib64). The instructions make it sound like the former

~/Library/Audio/Plug-Ins/VST/PluginName.vst

But then would you also sign ?
~/Library/Audio/Plug-Ins/VST/PluginName.vst/Contents/Resources/CsoundLib64.framework/Versions/6.0/CsoundLib64

and

~/Library/Audio/Plug-Ins/VST/PluginName.vst/Contents/MacOS/CabbagePlugin

#20

No, just the binaries.

The script does this for you. The reason we pass the path to the plugin is so that the script knows where the embedded Csound framework is. By passing the path to the plugin, it means the script will work from any directory.