Overnight Universal Audio issued a support email telling users of their software to defer updating due to a problem with macOS 14.4. An issue that was first highlighted by multiple developers at the end of last week. We’ll go into the details in this article and ask why does studio software keep letting us down? 

It’s Broken… Again!

This week has been another frustrating one for developers and musicians using Pace iLok protection and macOS. The release of macOS 14.4 has rendered thousands of M2 and M3 based systems incompatible with the audio tools users rely on. Why does this keep happening?

Users are rightfully perplexed, a post over at GearSpace saying “You would think that these companies participate in Beta tests for new OSes and are ready at release time.” (sic) Here’s the thing, developers do participate in beta tests. Apple has been issuing 14.4 betas since the end of January, so how have developers let clients blunder into this?

A Developer’s Perspective

We asked one developer who’s been working on the issue to explain a little more, they said this;

“There’s a fine line between a reason and an excuse, so make of our perspective what you will, but we can explain how we missed it and why we did not warn people about it in advance.

We tested the first few 14.4 betas that Apple issued, we have come to expect problems so usually do. We generally test on an M1 Max laptop, an M1 Mac mini, an Intel Mac mini and if problems show up there are a few older Macs that can be pulled out of storage. Everything seemed fine, basically no change – all of the plug-ins were working in all versions on Intel and Apple Silicon so we were not seeing this as a particularly significant point release. By the time the RC was released on Monday we were confident enough in what was on show in the betas to give it a pass.

On Wednesday a client contacted support to say all of the plug-ins in the portfolio crashed with the 14.4 RC on his M3 Pro laptop. Within a few hours we had established this was affecting multiple iLok protected plug-ins on his system, we symbolicated one of his crash logs (identified the specific area of the crash), and were fairly confident it was a protection issue based on the symbols in the crash and the specific plug- ins affected. The client had tried under Rosetta, and the problem went away – since Rosetta is so good it was another indicator that it only affected Apple Silicon processors running natively.

We wanted to investigate further before alerting clients or PACE to a potential problem that had only one problem report on one system so far. Cry wolf too often and people stop listening. We install software all the time that developers have warned us off and it’s fine, or the issues are pretty insignificant, so we take a fairly cautious line on this if we are going to issue a warning because when we do we want people to take it seriously.

Likewise we don’t believe in sounding an alarm with other developers until we have a reproducible problem that we have sufficient confidence in. We can blow years of goodwill with bogus reports that waste time and lead to nothing pretty quickly. The first thing PACE will do is ask for a test case they can reproduce locally. That’s fair enough. We didn’t have one but wanted to make one. Since the protection was likely involved we had to do that locally and couldn’t easily lean on beta testers to help out. Apple’s RC release notes contained nothing to indicate there would be an issue or help pin down the problem so we figured that meant using an M2 or M3 system and trying to reproduce it there, then make a reproducible test case there. We thought we had time over the weekend to do it because Apple often releases software on a Tuesday and usually leaves a bit more time between an RC and a final issue.

Not this time.

Apple released 14.4 to the general public on Thursday (in many parts of the world after office hours). Of course – the new M3 MacBook Air laptops were landing with clients on Friday and this was an essential day-one patch. Perhaps we should have foreseen that this might trigger a release earlier than usual. By Friday morning support inboxes had plenty of support requests from M2 and M3 clients confirming the issue was not isolated and was indeed going to become widespread, so we sent out a newsletter to try and stem the tide and an email to Pace with all of the investigation data to date.

This was too late of course. Plenty of clients are now stuck with systems that don’t work properly, and more are upgrading every day having not caught the news. Of course it’s not especially easy to revert an OS update.”

They feel personally responsible;

“Security patch updates like this are important, and here we are again in the audio industry asking clients to defer them. We’re sorry. Collectively this industry has failed you, again. We wanted to explain why we didn’t spot it and perhaps why others did not either.

We don’t know why nobody else picked this up during the beta cycle but perhaps it’s a sign we all need to invest in even more test hardware and invest more time testing to make sure we cover all of the permutations. Even the releases that seem minor and seem innocuous. Perhaps it means we need to reach out to a wider group of beta testers to make sure somebody is installing beta software on every conceivable system even when we are not changing plug-ins ourselves. Perhaps Apple could provide more detail to developers about what they are changing so we can read and make informed guesses about what might break if this or that is being updated. It’s not only a protection issue, there have been plenty of other examples over the years.

We catch these problems quite often, far more often than people probably realise but of course it’s the ones we miss that matter the most. The space between June to October with a new macOS release is often an extremely anxious time with things breaking and being fixed every few weeks and we are grateful to Apple for sharing this test software with us so we can work with them to try to help. As recently as November 2023, the macOS 14.2 beta broke iLok protected plug-ins in a very similar manner as this. From what we understand of it, it’s a very similar problem this time around. We found it then because on that occasion it presented on local test systems so we were able to speak with PACE early on in the beta cycle and they were able to speak with Apple about it in time. A number of other devs did too, and between all of us it meant very few clients noticed.

Now that a little more time has passed we think we understand the problem more fully. PACE has indicated that the fix will come from Apple, but the timescale for that is unknown.”

More Than One Developer

As we highlighted at the start of this article this issue is bigger than one developer, with LiquidSonics, Sonnox, Joey Sturgis Tones, Neural DSP, Universal Audio and many others all making public statements about the issue.

It’s time like this when one has to ask; “Why does studio software keep letting us down?” It’s easy to throw rocks in a moment of anger, and if you’re in the middle of a project with a deadline, justifiably so. However, it’s clear that there’s a number of dependencies that occur in the chain; OS, software protection, and the developer, it only takes one of those to fail and we’re stumped.

As the developers who have spoken about this have said, there is no date for a fix, it’s not a good look for Apple, PACE or the developers. On this occasion running the DAW under Rosetta is a work-around, but it feels like this is more by luck than judgement! 

Critical security patches like the 14.4 update contain important fixes that keep clients safe. In an age of online activations and cloud-based subscription licences that demand a system is always online this is more important than ever. The typical advice of holding off updates for a period of time is a double-edged sword.

Sadly, the developers are bottom of the proverbial food chain, so they are relying on Apple (who work at their own speed), and PACE.

Our Advice

Our advice has been consistent for the lifetime of this blog, circa 2008. Never perform software updates on mission critical systems when in the middle of an important project. For many professionals and major studios this means their systems are sometimes three or four generations behind the latest version, but they work! Before going all-in with a new release it’s helpful to edge forwards slowly by creating a dual boot machine so you can check your software will work before fully committing. We explain how to do it in this article. 

If you have recently bought a new Mac with the latest OS, then it can be difficult to lag the main operating system release as they often won’t work with an older operating system. For example an M3 Mac won’t find the drivers it needs in Ventura so you have no choice but to use Sonoma. 

The lesson from this is we can’t fully trust the software we use and are walking the tightrope balancing the needs of security vs dependability. We have to create studio machines that don’t rely on the latest day-one releases of software that might tank our DAWs but also don’t have wide open goals for hackers to target while we are going about our day-to-day business online. Running an out-dated system means we might not have the latest greatest version, but at least we know we can do work and make money, at the end of the day that’s the important thing.