iPlug2: a C++ audio plug-in framework for desktop, iOS, visionOS and web

The format matrix problem iPlug2 is built to remove

Shipping an audio plug-in means shipping several binaries. A CLAP build, a VST3 build, an AUv2 build for Logic, an AUv3 build for iOS, an AAX build for Pro Tools. Each format has its own entry points, its own parameter handling, its own idea of how the editor is created and destroyed. The README describes iPlug2 as abstracting an audio plug-in (IPlug) and its drawing engine (IGraphics), and lists CLAP, VST2, VST3, AUv2, AUv3, AAX (Native) and Web Audio Module (WAM v1) as targets, plus standalone win32/macOS apps and Reaper extensions. The audience is C++ developers who already know what a process block is and do not want to write seven of them. The README also states the official minimum targets: Windows 8, macOS 10.13, visionOS 26.0 and iOS 15, with a note that earlier systems may work depending on the graphics backend. That last clause matters, because the graphics backend is a choice you make, not a default you inherit.

How IPlug and IGraphics split the work

The framework is two layers. IPlug is the plug-in side: the abstraction over host APIs, parameters, state and audio processing. IGraphics is the drawing side: a graphics abstraction with a set of controls described as well suited for audio plug-ins, working in either bitmap or vector mode. The vector path runs on NanoVG or Skia, and the README frames that as a performance and requirement trade-off rather than a single correct answer. The repository layout shows the split directly: IPlug/ and IGraphics/ sit at the top level next to WDL/, Dependencies/ and Examples/. The README notes that IGraphics can be bypassed entirely, because iPlug2 can be used with other UI toolkits. The Examples directory is where that claim becomes concrete: IPlugWebUI, IPlugSvelteUI, IPlugP5js, IPlugSwiftUI and IPlugCocoaUI all put a different presentation layer on top of a C++ DSP core. IPlugChunks, IPlugControls and IPlugConvoEngine are closer to the classic IGraphics path. If you are evaluating the framework, the example you copy determines more about your architecture than any configuration flag.

Installing iPlug2 and building the IPlugEffect example

The README does not give a single install command. It points to a separate repository, iPlug2OOS, as the recommended starting point for an iPlug2 project in 2025, and it points to the wiki and the published API documentation at iplog2.github.io/docs. The repository itself carries CMakeLists.txt, CMakePresets.json and iPlug2.cmake at the top level, and the Examples directory has buildall-mac.sh and buildall-win.ps1 scripts, so the build is CMake-driven. A first look at the example list is the cheapest way to understand the shape of a project. Cloning the repository and listing the examples is a safe first step:

git clone https://github.com/iPlug2/iPlug2.git
cd iPlug2
ls Examples

That listing shows IPlugEffect, IPlugInstrument, IPlugMidiEffect, IPlugControls, IPlugWebUI, IPlugSvelteUI, IPlugSwiftUI, IPlugReaperExtension and others. From there, the IPlugEffect example is the smallest complete plug-in in the tree, and it is the one to read first if you want to see how parameters, a process block and an editor are wired together. The Examples directory also ships buildall-mac.sh and buildall-win.ps1, which build the whole example set rather than a single target:

cd Examples
./buildall-mac.sh

The README does not document what those scripts produce, which formats they configure, or where the built binaries land, so treat the script as a starting point for reading the CMake files rather than as a supported build command. If you want a project of your own rather than a copy of an example, the README's recommendation is iPlug2OOS, not a template inside this repository.

Where iPlug2 is the wrong tool

The README is candid about one thing: iPlug2 is a framework, not a product. There is no installer, no project generator that the README documents, and the recommended starting point lives in a different repository. If you want a wizard that produces a signed, notarized, multi-format build, iPlug2 will feel like a pile of CMake files. The README also asks for help with documentation, which is an admission that the docs are incomplete. The minimum platform list is another constraint: Windows 8, macOS 10.13, iOS 15 and visionOS 26.0 are the official floors, and the escape hatch for older systems is conditional on the graphics backend. If you need to support a host or OS below those floors, you are on your own. Finally, the release history is thin. The most recent release listed is v1.0.0-beta from 2024-11-06, labelled as optional dependencies, and the one before it is from 2019. Development happens on master, where the last push was on 2026-09-15, so the release tags are not a reliable signal of what the code does today. Pin a commit if you need reproducibility.

iPlug2 versus JUCE: two answers to the same question

The comparison people search for is iPlug2 vs JUCE, and the difference is architectural. JUCE is a broad C++ application framework that includes audio plug-in support among many other modules; iPlug2 is narrower, and the README describes it as abstracting an audio plug-in and its drawing engine. That narrowness is the point. iPlug2 targets WAM v1 and compiles to WebAssembly via emscripten, which puts browser delivery in the same source tree as the desktop builds. It also targets Reaper extensions, which is a niche JUCE does not centre. The licence is the other split: the README describes iPlug2 as licensed with a liberal zlib-like license, free to use in closed source projects and free from corporate interference, and the repository ships LICENSE.txt. Anyone choosing between the two should read both licences in full rather than rely on a summary, and should check which formats each framework actually targets today. The trade-off is ecosystem size: JUCE has more third-party material, while iPlug2 leans on its forum, Discord and wiki.

Maintenance, releases and what the licence lets you ship

The repository is not archived, and the last push was on 2026-09-15, so the master branch is moving. The release tags tell a different story: v1.0.0-beta (iPlug 2 optional dependencies) on 2024-11-06 and setup (iPlug 2 optional dependencies) on 2019-01-20. Neither is a versioned framework release in the usual sense, and the README does not document an upgrade path between them. Budget for tracking master and reading commit history when something breaks. The licence is the part with the clearest answer: the README calls it zlib-like, says it is free to use in closed source projects, and the full text is in LICENSE.txt at the repository root. Because the repository's licence field is reported as NOASSERTION, the README and LICENSE.txt are the sources to read, and if your organisation has a legal review process, that file is what it will review. iPlug2 also accepts sponsorship through GitHub Sponsors, which the README ties directly to maintenance time.

Editorial conclusion

Adopt iPlug2 if you need one C++ source tree that produces CLAP, VST2, VST3, AUv2, AUv3, AAX, WAM and standalone builds, and you are willing to read the wiki and API docs rather than expect a guided setup. Do not adopt it if you want a large commercial support contract or a visual designer; the README points to the forum and Discord instead. Before committing, verify that your target formats are in the list the README gives, that your minimum OS versions match the stated targets, and that the zlib-like LICENSE.txt terms fit how you plan to ship closed source.

Frequently asked questions

Official sources

1. iPlug2/iPlug2 on GitHub
2. Issues
3. Project website
4. README
5. Releases