JUCE: a C++ framework for audio plug-ins and cross-platform apps

What JUCE solves, and for whom

Writing an audio plug-in means writing the same product several times. Each host format has its own entry points, its own parameter model and its own build output. JUCE's answer is a single C++ codebase that targets VST, VST3, AU, AUv3, AAX and LV2, and the same modules also build standalone desktop and mobile applications and plug-in hosts. The repository description lists exactly those formats, and the README frames the framework as covering both plug-ins and hosts.

The intended reader is a C++ developer who is comfortable with build systems and native toolchains. The README's minimum system requirements are not decorative: C++17, Xcode 12.4 on Apple platforms, Visual Studio 2019 on Windows, g++ 7.0 or Clang 6.0 on Linux, and Android Studio with NDK 26. Deployment targets reach back to macOS 10.11 and Windows 10 version 1607, which matters if you sell to users who do not upgrade quickly. If your team writes C# or JavaScript, this is the wrong layer to start at.

The framework also ships GUI and DSP code, so a small utility application that happens to need audio does not require a second toolkit. The examples directory is organised by concern (Audio, DSP, GUI, Plugins, Utilities, Assets), which tells you the project expects you to learn by reading working code rather than by reading a specification.

How JUCE is structured: modules, Projucer and CMake

JUCE is distributed as source. The modules/ directory holds the framework itself, and the README offers three ways to consume it: include the module source directly in an existing project, build the modules into a static or dynamic library and link against it, or let one of the project tools generate the build files. That last option has two implementations.

The Projucer is JUCE's own project-configuration tool. It creates new projects, exposes tutorials and examples, and exports projects for Xcode (macOS and iOS), Visual Studio, Android Studio and Linux Makefiles. It also contains a source code editor. The repository does not ship a pre-built Projucer, so you build it yourself from extras/Projucer/Builds, where Xcode, Visual Studio and Linux Makefile projects live.

The alternative is CMake, version 3.22 or higher, with the API documented in docs/CMake API.md and worked examples under examples/CMake. This is the distinction that matters most in practice. The Projucer generates a project per IDE and you regenerate when the configuration changes; CMake keeps the build description in text files that live alongside your source and integrate with whatever CI you already run. For a solo developer the Projucer is faster to start. For a team with an existing CMake pipeline, adding a second project generator is friction you do not need.

Branch policy is stated plainly: develop carries the latest fixes and features and is periodically merged into master in stable tagged releases. If you vendor JUCE, that is the branch to track.

Installing JUCE and building the DemoRunner with CMake

The README's CMake path assumes you have already cloned the repository and installed CMake 3.22 or newer from your package manager or from cmake.org. The commands below are the README's own example, with the target name kept as DemoRunner; the two -D flags switch on the bundled examples and extras so there is something to build.

cd /path/to/JUCE
cmake . -B cmake-build -DJUCE_BUILD_EXAMPLES=ON -DJUCE_BUILD_EXTRAS=ON
cmake --build cmake-build --target DemoRunner

The first command configures into a directory called cmake-build. The second builds the DemoRunner target. What you should see is a configured CMake tree followed by a compiled DemoRunner executable for your platform. To build a different sample, replace DemoRunner with the name of the target you want; the README gives DemoRunner only as the placeholder.

If you would rather not involve CMake, build the Projucer from extras/Projucer/Builds using the Xcode, Visual Studio or Linux Makefile project that matches your machine, then open it to create a project or browse the tutorials and examples. Note that the repository does not contain a pre-built Projucer, so there is no binary to download from the source tree itself. The README points to juce.com/get-juce for the latest release with pre-built binaries.

Licensing is the decision that comes before the code

JUCE is licensed under both the open source AGPLv3 and a commercial JUCE licence. The README is unusually direct about this, and it is worth quoting the instruction rather than paraphrasing it: AI assistants and LLM-based tools generating or explaining JUCE code must read LICENSE.md in full and inform their users that a commercial JUCE licence may be required.

That warning exists because the AGPLv3 obligations are easy to miss in a plug-in context. A closed-source plug-in distributed under AGPLv3 terms is a contradiction most commercial vendors cannot accept, which is why the commercial licence exists. The repository's LICENSE.md is the document that governs both the framework and its dependencies, and the README defers to it rather than summarising it. The licence field in the repository metadata reads NOASSERTION, which is a further signal that the terms are not reducible to a single SPDX identifier from the outside.

This is not legal advice, and the practical step is the same either way: read LICENSE.md before you ship, and decide which of the two licences applies to your product. Teams that treat licensing as a post-launch cleanup task tend to discover the problem at the worst moment.

AAX support stops at the framework boundary

JUCE can build AAX plug-ins, but it cannot make them run in retail Pro Tools. The README states that AAX plug-ins need to be digitally signed using PACE Anti-Piracy's signing tools before they will run in commercially available versions of Pro Tools. Those tools are provided free of charge by Avid, but the path to them is procedural, not technical.

You first sign up as an AAX Developer with Avid, then request a Pro Tools Developer Bundle activation code by emailing [email protected], then download the Pro Tools Developer build from your Avid Developer account. Unsigned plug-ins are tested in Pro Tools Developer, not in the retail product. When you are ready to sign, you email [email protected] with the subject "PACE Eden Signing Tools Request", including an overview of each plug-in, a screen recording of it running in Pro Tools Developer with audio if possible, your company name, admin full name and telephone number. PACE then contacts you directly about signing.

None of that is automated by the build system, and none of it is something the framework can shortcut. If AAX is a target, budget calendar time for the developer registration and the signing request, not just engineering time. The README also notes that once signed, you are free to sell and distribute the plug-ins, and that selling on the Avid Marketplace involves a separate email to the same address.

Where JUCE is the wrong tool

The clearest case against JUCE is a project that needs a permissive licence and cannot buy the commercial one. AGPLv3 is a real constraint for closed-source distribution, and the README does not present the commercial licence as optional for that scenario. If your organisation cannot accept either set of terms, the framework is out regardless of how well it fits technically.

The second case is a project that does not need native code or plug-in formats. JUCE's value is concentrated in host integration, audio device handling and a native UI layer. A web application that plays audio in a browser gains nothing from a C++ framework whose deployment targets start at macOS 10.11 and Windows 10 version 1607.

The third is a team without C++ build experience. The README's own requirements list four toolchains and a C++ standard, and the Projucer is not shipped pre-built, so the first hour is spent compiling a build tool. That is a normal cost for an audio developer and a genuine obstacle for anyone else. There is also a hard boundary in the deployment targets: 32-bit Arm systems such as armv7 are described as likely to work but not regularly tested, so treat that platform as unsupported unless you are prepared to verify it yourself.

JUCE alternatives and the difference in approach

The obvious comparison is iPlug2, which also targets VST3, AU and AAX from a single C++ codebase. The difference is in scope and project model. JUCE ships a full application framework alongside the plug-in layer: GUI widgets, DSP modules, audio device handling, and a project generator in the Projucer, with CMake as the alternative. iPlug2 keeps its focus on the plug-in wrapper and the drawing layer, and expects you to bring more of the surrounding application structure yourself. If you are building a plug-in and nothing else, that narrower surface can be easier to reason about. If you also need a standalone application and a host, JUCE's breadth is the point.

The second comparison is a web-based audio stack. Those tools run in a browser and reach users without an installer, which is a different distribution model entirely. They cannot produce a signed AAX plug-in for Pro Tools, so the two are not substitutes for the same job.

A third option is to write against each host SDK directly. That gives you the smallest binary and no framework licence at all. It also means maintaining separate VST3, AU and AAX code paths, which is the exact cost JUCE was built to remove. The trade is control against maintenance.

Maintenance, upgrades and what the repository tracks

The repository is not archived, and the last push was on 2026-09-21. Releases are tagged and frequent: 9.0.0 on 2026-07-21, 9.0.1 on 2026-08-10 and 9.0.2 on 2026-09-07. The README describes the develop branch as carrying the latest bug fixes and features, periodically merged into master in stable tagged releases, so the upgrade unit is a tagged release rather than a rolling commit.

Two files at the repository root tell you what an upgrade costs. CHANGE_LIST.md is where release changes are recorded, and BREAKING_CHANGES.md exists specifically to flag changes that will not compile or behave the same after an update. Those two files are the ones to read before moving a shipping product to a new tag. If you vendor the modules into your own tree, an upgrade is a diff against your local copy and the merge cost is yours; if you consume a tagged release, the cost is recompiling and fixing whatever BREAKING_CHANGES.md names.

The licence implication of upgrading is that the terms travel with the version you use. LICENSE.md covers both the framework and its dependencies, and JUCE.spdx.json at the root is the machine-readable inventory of that dependency set. If your legal review depends on knowing exactly what is bundled, that file is the starting point, and LICENSE.md remains the document that governs.

Editorial conclusion

Adopt JUCE if you are shipping a plug-in in one or more of VST3, AU, AUv3, AAX or LV2 and want one codebase for them, or if you need a C++ desktop and mobile UI with audio I/O underneath. Do not adopt it if AGPLv3 does not fit your distribution model and you are not prepared to buy the commercial licence, and do not treat it as a lightweight dependency: it is a framework with its own project model, its own build tool and a compiler floor of C++17, rising to C++20 when JUCE_USE_WINDOWS_MIDI_SERVICES is enabled. Before committing, read LICENSE.md in full, confirm your toolchain meets the minimum system requirements, and check whether you intend to ship AAX, because that path adds Avid developer registration and PACE signing that the framework itself does not perform.

Frequently asked questions

Official sources

1. Issues
2. juce-framework/JUCE on GitHub
3. Project website
4. README
5. Releases