@Orvillain I'll never support AAX. My audience simply doesn't live there. Thank goodness!

On Mac I'm building a pkg, and my post-install script runs a quarantine flag removal on the installed vst3 file. It seems to be working for some alpha testing.

If by alpha testing, you mean on your own machine and a few developer friends, then yes that'll work but it's unlikely to survive contact with the real world.

Fortunately the macOS side is the easiest to solve. Get a $99/year developer account, get your App and Installer signing certs and apply them during the export and packaging phase. Extremely easy.

@David-Healey Yeah, even though the UK government is doing all it can to erode them away year after year

Aside from tax efficiency, the main reasons I'm doing it are for plugins:

1. Ability to use Azure cloud-signing on Windows, and
2. Ability to have Meat Beats Ltd as my Apple signing ID instead of my full name.

@DanH Agreed, especially music producers who might be downloading and installing free and shady plugins from all over the place. They know how to do the 'install anyway' dance.

But for my first plugins (fully self-contained VST3) the ZIP method is same-effort for the end user. Anyone used to breezing past the 'install anyway' screens also knows how to drop a VST3 into the system folder.

Like I said, when I register as a limited company, I'll definitely do Azure code-signing and make a proper installer (and no Unknown Publisher screen). I just need to register the limited company before shipping plugins with sample archives or expansions.

For context, on the Mac side (my daily development platform):

Gatekeeper flat out refuses an unsigned, un-notarized plugin, so there's no ZIP escape hatch like on Windows. And yet it was the easy half. Not painless in the Apple way of things, but genuinely quick, and available to me as an individual with no company.

Apple Developer account. $99 a year, open to individuals anywhere. No company registration, no face scan theatre, just an Apple ID and standard identity verification. This is the thing Microsoft's equivalent (Azure Trusted Signing) doesn't offer UK individuals, and it's the whole reason the Mac release was unblocked while the Windows one needed a workaround.

Certificates. The account gets you two Developer ID certs: Application (signs the plugin bundles) and Installer (signs the pkg). Generated once through the developer portal, installed into the keychain, done.

Signing and notarization. This part is scripted and runs as part of my build: codesign each bundle with the hardened runtime enabled, submit to Apple's notarization service with notarytool, staple the ticket. Notarization sounds scary but it's an automated malware scan on Apple's servers that takes a few minutes and gives you an answer, not a reputation system you wait months to accrue. Once it passes, users see zero warnings, forever, on every machine. That's the deal Windows code signing doesn't offer even when you pay: on Windows a fresh cert still has to earn SmartScreen reputation over time. Meh.

The installer. I used Package Builder ($30 Mac app) rather than the free Packages app or hand-writing pkgbuild scripts. Drop in the AU and VST3, select "Code Sign and Notarize" with the Developer ID Installer cert and your Apple ID. It signs the pkg and submits it for notarization itself, so the installer comes out fully cleared, not just the plugins inside it. Awesome.

So the finished state is lopsided but works for me. Mac: signed, notarized, one pkg, double-click, no warnings. Windows: ZIP and a one-line readme. The platform that mandates signing made it a solved problem for an individual developer in an afternoon for $99 a year. The platform where signing is optional made it annoying enough to avoid shipping an executable at all.

I just went down the Windows installer and code signing rabbit hole for my synth plugin and came out the other side with a decision I didn't expect: no installer at all.

TLDR: if your plugin is one file going to one folder, a ZIP with clear instructions gives your users a smoother, less alarming experience than an unsigned installer, and costs you nothing.

Sharing the findings here in case it saves someone else a day of research.

My plugin is a single VST3 on Windows. Bundled presets/images/fonts/audio assets (for simple Audio Loop Players). That means one file, one destination folder. So the installer would exist mostly for polish, not necessity.

Here's why I dropped it.

The problem: an installer is an .exe, and an unsigned .exe looks scary

If you ship an unsigned installer, SmartScreen will greet your users with the "Windows protected your PC" screen, and they have to click "More info" then "Run anyway" to proceed. I'm sure most Windows users, especially music producers, are used to this, but for a paid product from a developer they've never heard of, that's bad optics. I'd argue worse than no installer at all.

Option 1: Azure Trusted Signing. Blocked for me.

This is the modern route everyone recommends, and it's cheap. But it's only available to individuals in the US and Canada. In the UK you need a registered (Limited) company. I'm still a sole trader with no Ltd, and I'm not registering a company and wading through Azure bureaucracy just to unblock a release. Registering is on the roadmap but not worth bumping it up for this.

Option 2: An individual code signing cert. Possible, but underwhelming.

There is a middle path: Individual Validation (IV) certs. SSL.com and Certum both sell these to individuals with no company required, verified via passport and a face scan, turnaround in days not weeks. Certum even has a "Cloud CODE Signing for Individual Developer" product that a company literally cannot buy.

But here's the catch that killed it for me: signing removes the "Unknown publisher" label, but SmartScreen reputation still builds up gradually per certificate. A fresh cert with no reputation can still trigger warnings. So you pay, you do the ID verification dance, and your users may still see scary screens for a while. And from March 2026 the CA/B Forum caps code signing cert validity at 458 days, so this becomes a recurring chore, not a one-off.

The realisation: no .exe, no problem

SmartScreen cares about executables. A ZIP containing a .vst3 and a text file doesn't trigger any of this.

So the Windows release is:

• MyPlugin.vst3
• INSTALL.txt ("Copy MyPlugin.vst3 to C:\Program Files\Common Files\VST3 and approve the admin prompt")
• LICENSE.txt

That's the whole install. VST3 has one canonical system folder, so there's no per-DAW path confusion like the old VST2 days. I shipped earlier plugins as VST2/VST3 and had some support tickets, but those were usually because of the VST2 confusion. Oh, and I'm clearly not doing AAX either - another axis of complexity avoided.

The installer isn't dead, just deferred

When I register as a company, I'll 100% ship an Azure cloud-signed installer. Shipping an unsigned one in the meantime would be a downgrade from the ZIP.

One extra risk: the ever-annoying Anti-Virus checks on Windows, and two practical mitigations. [1] Submit the ZIP and the .vst3 to Microsoft's file-submission portal once the release build is final (it whitelists the hash and hugely reduces the block-at-first-sight risk), and [2] run the final binary through VirusTotal before release so I know which of the ~70 engines flag it, if any. Both are free and take minutes.

Very open to having my mind changed here, but given the fact that I've been distributing my previous (non-HISE) plugins for 3 years on Windows via the ZIP > extract > copy to folder method, I think this is a no-brainer approach for my first couple of self-contained HISE plugins.

Update: Claude-generated gist here of the suggested patch: https://gist.github.com/weavermedia/3fc4a419920fcda8de389a89d7aec68d

@David-Healey Nice find

@David-Healey Had Claude do a deep dive on this. My summary:

1. It was fixed in JUCE 8.

JUCE 8 (2024) introduced TypefaceMetricsKind with two modes: legacy (the old per-platform behaviour - explicitly documented as "metrics may differ for the same font file on different platforms") and portable (same metrics everywhere, based on the sTypo metrics - i.e. the same table family our harmonisation aligned everything to). portable is the default for the new FontOptions API. legacy survives only for the deprecated Font constructors. JUCE 9 (released three days ago) carries that forward. So the divergence we measured isn't just fixed upstream - it's acknowledged as a framework bug with a designed migration path.

2. Submitting a JUCE 6 fix to JUCE is a non-starter. It's 2 major versions EOL. Fixed in JUCE 8 anyway.

3. Would a fix even be accepted, considering it's technically the font at fault?

JUCE 8 is the counterargument to that. The JUCE team looked at this exact situation and concluded the framework should absorb it. And our own data supports that: Google-shipped fonts (multiple Barlows and Michroma) carry disagreeing tables. When the ecosystem's most mainstream font foundry ships "broken" metrics, they're not broken - the platform-divergent reading of them is.

4. Submit a fix to HISE

This would technically be a fix to the current JUCE_customized submodule repo and I don't really want to go there. It's a heavily customised version of JUCE 6 and sounds like at some point Christoph will move to JUCE 9 (judging by previous comments), possibly inheriting the fix anyway, so I wouldn't know where to start with this.

I'm happy to leave all this here with a note to @Christoph-Hart that if he wants to take this on I'm sure we would all appreciate it but it feels too messy/convoluted for me to take on right now.

@David-Healey Turns out, it's not Windows/JUCE/HISE/our code - it's the fonts themselves!

PSA: If your fonts render bigger/smaller on Windows than Mac, your font files are probably broken (and how to fix them)

Claude and I just solved a cross-platform rendering issue that I'd been treating as "JUCE renders fonts differently on Windows" - turns out it was nothing of the sort, and the fix is a one-time patch to the TTFs themselves.

Sharing here because I nearly shipped a table of per-platform correction factors instead.

Symptom: the same embedded font at the same nominal size rendered ~12–24% smaller on Windows than on macOS (three different fonts, three different ratios).

Cause: a TTF carries three sets of vertical metrics - hhea, OS/2 typo, and OS/2 win - and they're allowed to disagree with each other. macOS (CoreText) sizes fonts from hhea; JUCE on Windows uses the OS/2 win metrics.

This isn't from dodgy free fonts — they're popular stock Google Fonts downloads (Barlow, Barlow Condensed and Michroma). All three even set the USE_TYPO_METRICS flag asking renderers to use the consistent tables, but the JUCE Windows path ignores it.

Diagnosis (predict the divergence before you patch anything):

# Python script, and fontTools should be installed (pip install fontTools))
from fontTools.ttLib import TTFont
f = TTFont("MyFont.ttf")
hhea, os2 = f["hhea"], f["OS/2"]
print("hhea total:", hhea.ascent + abs(hhea.descent))
print("win  total:", os2.usWinAscent + os2.usWinDescent)

If win / hhea matches your measured Mac to Windows size ratio, this is your problem. Mine predicted x1.24, x1.13, x1.12 against measured x1.2, x1.12, x1.12. Close enough proof for me.

Fix

os2.usWinAscent = hhea.ascent
os2.usWinDescent = abs(hhea.descent)
f.save("MyFont.ttf")

Mac rendering is untouched (hhea unchanged), Windows converges to match.

After patching, all my script-side correction factors went to 1.0 and both platforms render pixel-identical sizes. Meaning I could remove all the platform-specific text scaling code I had just added.

Gotcha

• Classic "HISE caches fonts per session" - after replacing a TTF in place, fully quit and relaunch HISE before testing or exporting. A recompile silently keeps the old typeface.

@David-Healey I switched to Google fonts for exactly that reason - hoping they would have decent hinting for Windows.

But both fonts need scaling factors (x1.12 and x1.2) for Windows and the baseline is even off on one of them. *sigh*

@ustk Just the ever-tightening security of OS vendors. Privacy is a selling point now, as is anti-machine-fingerprinting.

A user account authentication system, via the browser, feels much more lightweight, predictable and more transparent to the user.

How's everyone handling the text rendering differences between Mac and Windows?

I develop on a Mac and when I finally saw the plugin in Windows, I was horrified at the text rendering!

Leaving aside the awful 1x rendering issues, the font metrics were off by much more than I'd like.

Since all my font sizes are defined in a Typography namespace, I added a platform-specific scaling function to resize the fonts - interestingly scaling two fonts in opposite directions.

Is there a more elegant/robust way to handle this? Are my fonts the problem here?

@ustk Seems like user account verification is the way to go - à la Moonbase.

Very, very not helpful to this thread, I know, but the machine ID issue is only going to get worse, it seems.

@bashfulsound It's a bug. I submitted a PR here but not sure if Christoph has seen it yet.

https://github.com/christophhart/HISE/pull/962

@Christoph-Hart Works great here!

I'm only using it with the PluginState rather than External, which I think you're doing @David-Healey ?

SubStates: {
    MidiAutomation: "PluginState"
}

But it works great with all my scenarios.

@Christoph-Hart Thanks for the proper fix. (Here in case anyone missed it)

Claude says there's still one case that your fix doesn't catch:

Calling Palette.text where Palette has no text but a local text is in scope will silently bind to the local instead of erroring. Degenerate case (the code is already wrong at that point), but just thought you should know. Maybe you saw it and elected not to cover it.

@lalalandsynth What kind of cost are we looking at for one of these looks?

Pull it from public display, rework it for my specific plugin, then deliver the individual assets, various mockups and 3D source files?

Ballpark - is it ££ hundreds, £££ thousands, or ££££ tens of thousands?

@David-Healey You would usually have a CLAUDE.md file in each repo that documents all the conventions used there.

It's loaded in each new session and used throughout that context.

I have more or less the same CLAUDE.md in every HISE project that has HISE conventions, gotchas and resources. And I have a project-specific PROJECT.md with the same, but per project - so things like what this plugin does, what DSP is uses, target audience, etc.

PROJECT.md is referenced in CLAUDE.md so it carries into every session.

@David-Healey Have you pointed Claude to any of your other repos? Rhapsody, etc.

If you do that, and tell it to use your scripting conventions rather than inventing new ones, it will likely do a better job.

I found Claude usually follows whatever style is already in the repo. Might be my bad code, of course!

Also, genuinely curious - why does it need cleanup/rewriting?

@David-Healey Yeah, that's why I wanted a solution that didn't involve any plugin/preset callbacks at all.

Just wanted zero mappings saved in the presets, and a nice clean MidiMappings.js save/load script.