Request for Long Term Support (LTS) Release for JUCE Version 7

Audio Plugins
1

We are have been using JUCE 7.0.8 without issues for some time. Recently, we tried upgrading to version 8 but faced several issues, particularly on Windows (plugins showing some strange artifacts, sometimes missing text from menus and others) however, given that version 7.0.8 was stable for us, we decided not to proceed with the upgrade. At least wait until we had the necessary time to test.

However, after updating our development environment to the latest macOS Sequoia, we found out that JUCE version 7 is no longer building on MacOS Sequoia , forcing us to move to version 8.0.2.
After waiting several minutes for Jucaide to build on an M1, we discovered that the VST3 was still not building due to errors, and eventually resorted to using the latest JUCE commit from the development branch, which did finally allow us to build the VST3.

We find ourselves in a very precarious situation—having to use an untested development branch that may or may not work in production, and needing to push this out to customers without having the time for exhaustive/regression testing. This is especially concerning for us, as we are paying subscribers of JUCE and received no notification regarding potential incompatibilities with the new macOS Sequoia update.

We strongly believe that a Long Term Support (LTS) release is crucial for a framework like JUCE. An LTS version would provide a stable and reliable foundation that developers can confidently use without the need to constantly chase compatibility issues, especially with operating system updates. It would offer us more predictability and help mitigate the risks associated with updating core libraries. Moreover, an LTS release would prevent scenarios like the one we and many others are currently facing, where stability takes a backseat and rapid changes lead to development headaches.

From our observations on the forum, it’s evident that numerous developers are struggling with similar challenges. This suggests a systemic problem in JUCE’s deployment strategy, particularly when it comes to maintaining stability across updates.

We urge the JUCE team to consider releasing an LTS version for JUCE 7 that works with the latest macOS, with continued support for at least one year. This would be immensely helpful for the community and would allow us to focus more on developing and delivering great products to our customers rather than fighting build issues.

Thank you for your consideration.

7 Likes
2

Have you explored getting JUCE 7 working on the latest OS? I can think of at least five things that might be worth exploring

  • If you have a JUCE 8 licence grab the few commits from the JUCE 8 branch and apply them to JUCE 7 on a fork. I posted the commits I expect you’ll need here.

  • If you don’t have a licence, look at doing the work yourself. In this case I think it could be done with ignoring a few warnings and returning a null image for a single function, as long as you don’t need juce::createSnapshotOfNativeWindow() to work.

  • Try to get Xcode 16 to point at an older macOS SDK. This was a common task that was carried out with older Xcode versions (at least in my experience) see this question on StackOverflow where someone is asking about this

  • Some have reported success using Xcode 15 on the command line in macOS Sequoia, maybe this would suffice in this case

  • Install Sonoma on a virtual machine to allow development to continue on the older OS, something like VirtualBuddy might be useful for this

I would also add that in my professional experience I would strongly advise against updating to the very latest OS and tools versions on an active development environment wherever possible, esp. if some kind of deadline is looming. By all means have an up to date test environment, and even better a secondary development environment that you can use to evaluate the state of things. However, my general rule of thumb is don’t update macOS or Xcode on development environments until the following beta version is out unless absolutely required. That being said I understand that there are times when your hands are tied and there is no avoiding it.

I will also add that although there are breaking changes moving from JUCE 7 to JUCE 8 we react to issues on the development branch relatively fast and try to keep that branch as stable as possible. I would say more times than not upgrading to the development branch fixes an issue that someone is reporting. Plenty of users have reported using JUCE 8 with success.

3

I’m a bit late the game on moving over to JUCE 8 (even though I already paid for the license), however is there something specific that is known to prevent or cause issues building in Sequoia/Xcode 16 with JUCE 7.x codebase?
I just did a build of one of my existing 7.x based plugins (project generated in Projucer) and it built standalone/AU/VST3 without any issues (Sequoia/Xcode 16) and so far testing of debug builds on a M2 system seems to be working - I target the oldest OS possible - min deployment target OS 10.13 currently - seemed to work.
Will there be any fixing of critical issues in JUCE 7.x or is that now no longer supported?
Thanks.

4

Thank you, @anthony-nicholls, for your suggestions and the prompt response. I want to start by acknowledging the JUCE team’s responsiveness and engagement with users, which we genuinely appreciate.

That said, I still believe that adopting a Long Term Support (LTS) model would be highly beneficial. An LTS release would be governed by a clear set of rules, prerequisites, and a comprehensive list of compatible systems and tools. For instance, in scenarios like this, if the LTS version had not been tested with macOS 15.0.1 and Xcode 16, it would clearly indicate the risks of upgrading. Once testing is completed, the JUCE team could announce whether it is safe to update, providing developers with the confidence to proceed.

Additionally, introducing an LTS model would mean that each new LTS beta could be released well in advance of the current LTS end-of-life, giving developers ample time to thoroughly test and prepare for migration. This structured approach to updates is a standard model that has proven effective in other contexts, such as with Ubuntu, and would greatly benefit JUCE users by enhancing stability, predictability, and overall efficiency in our development workflows.

The approach we currently take regarding JUCE upgrades is, in general, to avoid upgrading unless absolutely necessary. Our systems are highly complex, involving integration with various plugins, APIs, external code, and native Windows and macOS components. Performing regression testing across all these elements is both challenging and time-consuming.

An LTS model would significantly alleviate these challenges by focusing solely on necessary and validated fixes rather than introducing new features, ensuring stability without unexpected disruptions. This approach would provide a reliable foundation for development, minimizing risks and reducing the need for exhaustive testing after every update.

1 Like
5

Anthony linked a few important commits here: Sequoia/Xcode 16 compatibility

I also think an LTS model of JUCE 7 would (have, maybe no feasible anymore) made sense considering the major changes of JUCE 8 and the ongoing threads highlighting problems. Especially the last makes me very careful when updating.

I also think the hole licence discussion should not be part of being committed to an LTS version of JUCE. A new version JUCE-7-LTS could be released as part of the JUCE 8 licence, so every project that wants to stay on JUCE 7 for one reason or the other, can continue to receive these kinds of fixes.

2 Likes
6

Very much in support of an LTS. Although there’s going to be a lot of resistance from the team I think the need for it is abundantly clear at the moment. It’s an established model for many developer tools, infrastructure solutions and open source projects for good reason.

7

at least merge those build fixes to juce 7 branch

4 Likes