Zrythm v2 replaces v1's C, GTK, and Meson stack with C++23, Qt6/QML, JUCE, and CMake in a ground-up rewrite. The switch was not made just to freshen the windows and buttons. Alexandros Theodotou had already said in October 2024 that GTK was performing poorly on non-GNU/Linux platforms and that Meson had become another source of friction.
The planned move was originally described as C++20, but the public v2 alpha arrived on C++23 instead. The current Zrythm v2 alpha now sits on a stack that changes the interface, build system, plug-in layer, testing setup, and chunks of the audio engine at the same time.
Qt6/QML therefore has a fairly practical job. Zrythm uses Qt Quick for a hardware-accelerated interface instead of carrying the old GTK front end forward, while JUCE takes on cross-platform pieces around audio and plug-in hosting. The Zrythm v2 plug-in support changes are a separate rabbit hole, but they show how far the architectural swap reaches beyond the visible UI.
The rewrite also explains why feature parity has been uneven. Rebuilding core systems means mature v1 behavior has to be ported, redesigned or dropped rather than simply switched back on. The remaining v1 feature gaps make more sense in that context because the project is replacing foundations while trying to recover everyday DAW workflows on top.
Hardware acceleration does not automatically make an alpha smooth, and Zrythm does not claim the rewrite has magically solved every performance problem. What it does provide is a different rendering path and a cross-platform UI framework the project chose specifically after running into limitations with its previous setup.
The first alpha also arrived with a much heavier validation setup. Its release notes list Clang sanitizers, Valgrind, QML linting, formatting checks, unit tests, integration tests, and benchmarks. Alpha.3 later included fixes for data races between the main and audio threads that were caught with ThreadSanitizer, so the tooling is already finding the sort of low-level bugs a real-time audio application cannot afford to shrug off.
Large rewrites still come with a bill. Industry evidence on software migrations describes maintainability as a common migration driver while also showing how new technologies create their own expertise and implementation challenges. Zrythm's alpha status fits that trade-off pretty neatly without needing to pretend the new stack is automatically better in every corner.
The build switch also reaches release packaging. Alpha.1 used CPack for AppImage packages on GNU/Linux, drag-and-drop packages on macOS and Inno Setup installers on Windows. It is boring infrastructure, but boring infrastructure is exactly what has to behave consistently when the same application is being shipped and debugged across three desktop platforms.
C++23 also raises the compiler baseline. The current build configuration requires GCC 14 or newer, or Clang 19 or newer, and explicitly enables the C++23 standard. It is a modern target, but it also means older distributions and conservative build environments can hit a wall before Zrythm itself starts compiling.
None of this proves a rewrite was the only possible route. It does explain why v2 behaves like a new application growing back into an old one's feature set rather than a normal major-version facelift. The interface changed because the project had cross-platform problems, while the language, build system, testing pipeline and framework choices changed with it.
The planned move was originally described as C++20, but the public v2 alpha arrived on C++23 instead. The current Zrythm v2 alpha now sits on a stack that changes the interface, build system, plug-in layer, testing setup, and chunks of the audio engine at the same time.
The rewrite started with cross-platform pain
The clearest answer to why Zrythm switched from GTK to Qt6 came before the rewrite was public. Zrythm v1 was considered production-ready on GNU/Linux, while the Windows and macOS builds were still described as beta quality. The developer tied part of that gap directly to GTK performance outside GNU/Linux and said the new stack was intended to make cross-platform development easier and more maintainable.Qt6/QML therefore has a fairly practical job. Zrythm uses Qt Quick for a hardware-accelerated interface instead of carrying the old GTK front end forward, while JUCE takes on cross-platform pieces around audio and plug-in hosting. The Zrythm v2 plug-in support changes are a separate rabbit hole, but they show how far the architectural swap reaches beyond the visible UI.
The rewrite also explains why feature parity has been uneven. Rebuilding core systems means mature v1 behavior has to be ported, redesigned or dropped rather than simply switched back on. The remaining v1 feature gaps make more sense in that context because the project is replacing foundations while trying to recover everyday DAW workflows on top.
Qt Quick changes more than the paintwork
The Zrythm Qt6 QML interface separates a lot of visual behavior from the C++ backend instead of keeping the old C and GTK arrangement. For a DAW, this matters because timelines, meters, editors, and constantly moving controls put more pressure on the interface than a mostly static desktop utility.Hardware acceleration does not automatically make an alpha smooth, and Zrythm does not claim the rewrite has magically solved every performance problem. What it does provide is a different rendering path and a cross-platform UI framework the project chose specifically after running into limitations with its previous setup.
The first alpha also arrived with a much heavier validation setup. Its release notes list Clang sanitizers, Valgrind, QML linting, formatting checks, unit tests, integration tests, and benchmarks. Alpha.3 later included fixes for data races between the main and audio threads that were caught with ThreadSanitizer, so the tooling is already finding the sort of low-level bugs a real-time audio application cannot afford to shrug off.
Large rewrites still come with a bill. Industry evidence on software migrations describes maintainability as a common migration driver while also showing how new technologies create their own expertise and implementation challenges. Zrythm's alpha status fits that trade-off pretty neatly without needing to pretend the new stack is automatically better in every corner.
CMake and C++23 raise the development floor
The Zrythm CMake build system is another part users may never see until they compile it themselves. CMake replaced Meson, and the current project uses automated dependency fetching, so a source build mainly expects CMake, Qt, and the platform toolchain instead of a long manual dependency hunt.The build switch also reaches release packaging. Alpha.1 used CPack for AppImage packages on GNU/Linux, drag-and-drop packages on macOS and Inno Setup installers on Windows. It is boring infrastructure, but boring infrastructure is exactly what has to behave consistently when the same application is being shipped and debugged across three desktop platforms.
C++23 also raises the compiler baseline. The current build configuration requires GCC 14 or newer, or Clang 19 or newer, and explicitly enables the C++23 standard. It is a modern target, but it also means older distributions and conservative build environments can hit a wall before Zrythm itself starts compiling.
None of this proves a rewrite was the only possible route. It does explain why v2 behaves like a new application growing back into an old one's feature set rather than a normal major-version facelift. The interface changed because the project had cross-platform problems, while the language, build system, testing pipeline and framework choices changed with it.
