AU component version is always 0 in exported plugins (Xcode exporter misses versionAsHex)

[dannytaurus]

Every AU exported from HISE on macOS registers with a component version of 0.0.0, regardless of the project version. The bundle version fields are correct, so this only shows up when a host or validator reads the AudioComponents registration.

Repro

Export any project as AU on macOS, then look at Binaries/Builds/MacOSX/Info-AU.plist:

<key>AudioComponents</key>
<array>
  <dict>
    ...
    <key>subtype</key>
    <string>Mbsf</string>
    <key>version</key>
    <integer>0</integer>   <!-- always 0 -->
  </dict>
</array>
...
<key>CFBundleShortVersionString</key>
<string>0.0.30</string>    <!-- correct -->
<key>CFBundleVersion</key>
<string>0.0.30</string>    <!-- correct -->

I see this on a 0.0.30 project and on two untouched 1.0.0 test projects, so it is not version-string specific.

pluginval reports the plugin as version 0.0.0 as a result. That is JUCE's own AU format reading it back: juce_AudioUnitPluginFormat.mm calls AudioComponentGetVersion, which returns the value from that plist entry.

Cause

In JUCE/extras/Projucer/Source/ProjectSaving/jucer_ProjectExport_Xcode.h, writeInfoPlistFile() sets options.version (around line 1839) but never sets options.versionAsHex. That member defaults to 0 in juce_PlistOptions.h, and juce_PlistOptions.cpp writes it straight into the AudioComponents dict:

addPlistDictionaryKey (*dict, "version", versionAsHex);

The Mac Makefile exporter does set it (jucer_ProjectExport_MacMake.h: options.versionAsHex = project.getVersionAsHexInteger();), so the Xcode path is the only one affected, and that is the path HISE uses for macOS export.

Fix

One line next to the existing options.version assignment in the Xcode exporter:

options.versionAsHex = owner.project.getVersionAsHexInteger();

Since HISE 5 ships a prebuilt Projucer in the JUCE submodule, this needs a Projucer rebuild to reach users, not just the source change.

Impact

Fairly mild but worth fixing. The compiled binary is fine: JucePlugin_VersionCode is set correctly from getVersionAsHex(), so the AU wrapper's Version() returns the right value at runtime and the plugin loads and works normally. What breaks is the registration metadata:

• Hosts display the plugin as version 0.0.0.
• AU caches keyed on component version never invalidate across releases, so users updating a plugin may need to clear their AU cache manually before macOS notices anything changed.

Workaround

Until the exporter is fixed you can patch the value per build, but note where: Info-AU.plist is written by the Projucer --resave step inside batchCompileOSX, not by the HISE export, so editing it straight after exporting gets overwritten.

The AU component version is the project version packed as major * 65536 + minor * 256 + patch written as a decimal integer, so 0.0.30 becomes 30 and 1.2.3 becomes 66051.

Set it with /usr/libexec/PlistBuddy -c "Set :AudioComponents:0:version 30" "Binaries/Builds/MacOSX/Info-AU.plist" after the resave, then build the .xcodeproj in Xcode.

If you drive the build from a script, insert that command into your copy of batchCompileOSX between the --resave line and the xcodebuild line.

Tested against the JUCE 6.1.3 submodule on macOS.

[dannytaurus]

Update: workaround of setting the version manually in the .plist confirmed working here.

After rebuilding, Logic reported the AU version in Plug-in Manager as 0.0.30 instead on invalid.

[Lindon]

@dannytaurus
Perhaps report this - and your findings on the JUCE forums?

[dannytaurus]

@Lindon It appears to be specific to @Christoph-Hart's customised JUCE fork.

Revised (more detailed) cause from Claude:

Cause

JUCE/extras/Build/juce_build_tools/utils/juce_PlistOptions.h in JUCE_customized carries the pre-6.1 API, where versionAsHex is a member each exporter has to fill in.

jucer_ProjectExport_Xcode.h writeInfoPlistFile() sets options.version but never options.versionAsHex, so it keeps its default of 0 and juce_PlistOptions.cpp writes that straight into the AudioComponents dict.

juceaide and jucer_ProjectExport_MacMake.h both set it, so only the Xcode path - the one HISE uses for macOS export - is affected.

Upstream JUCE is not affected either way: 6.0.8 has the same member and its Xcode exporter does set it, and 6.1.0 removed the member altogether, computing the value inside the plist writer (getAUVersionAsHexInteger at juce_PlistOptions.cpp:315 in 6.1.3).

So this looks like an assignment lost while carrying the older plist code onto a 6.1.3 base.

Fix: one line next to the existing options.version assignment, matching what upstream 6.0.8 had:

options.versionAsHex = owner.project.getVersionAsHexInteger();

Since HISE 5 ships a prebuilt Projucer in the JUCE submodule, this needs a Projucer rebuild to reach users, not just the source change.

[dannytaurus]

Ha. A fix from @DanH is already sitting in a PR in the custom JUCE repo sine June 16th: https://github.com/christophhart/JUCE_customized/pull/3

[DanH]

@dannytaurus nearly all my PRs get ignored

[ustk]

I stopped trying to push PRs because a lot of us are cross fixing the same stuff over and over before having a chance to see them reviewed and merged, unfortunately...

[Christoph Hart]

Sorry guys I‘m currently completely submersed in a theatre project, so this month will still be slow but then I‘ll pick up the work and review / merge all the PRs - just keep them coming they are not ignored but sit around waiting to be reviewed.

[David Healey]

@dannytaurus I just had a user on Tahoe report this issue

Logic Pro's plug-in manager says Libre wave > Rhapsody is compatible but the version is invalid.

Is that related to what you've described here?

[dannytaurus]

@David-Healey Yep. Below shows 'invalid' value from current HISE build, a post-export fixed one and a non-HISE version number.

[David Healey]

@dannytaurus wonder why the issue is only showing up for this one use though.

At least it's a simple fix

[dannytaurus]

@David-Healey

issue is only showing up for this one use

What do you mean? As far as I know all AU plugins exported from HISE since Dec 2021 have had this 'invalid' version in Logic. VST3 is unaffected.

[David Healey]

@dannytaurus It's the first time a user has reported that Rhapsody won't load because of this version issue. Or possibly the user just saw invalid and didn't try and load it on a track - I shall ask.

[dannytaurus]

@David-Healey The AU with an invalid version works fine. It just shows 'invalid' in the plug-in manager.

[David Healey]

Yeah the fix works

[dannytaurus]

@David-Healey Nice. Did you do the JUCE fix? Or the post-export manual fix?

[David Healey]

@dannytaurus I pulled in Dan's PR and rebuilt Projucer

[ustk]

In PluginDoctor it's saying v0.0.0 (before the fix) so it kinda stands for "invalid". I'll report to DDMF so it shows a "invalid" string of some sort as well...

[dannytaurus]

@ustk Yeah, good idea. I asked Claude if the version reports as an invalid number, or just as 0.0.0.

• The AU plist has AudioComponents.version = 0.
• Pluginval decoded that as v0.0.0.
• JUCE’s decoder explicitly formats the packed integer 0 as 0.0.0.

0.0.0 is valid as a semantic version, but AU metadata uses a packed UInt32, not a SemVer string.

In practice, hosts treat raw value 0 as “version unset.” Logic therefore labels it invalid, while pluginval merely displays the decoded value.

For 0.0.30, the AU field should contain integer 30. The bundle’s separate CFBundleVersion can remain the string 0.0.30.