Rendering SwiftUI as a plugin interface instead of JUCE

[Marla Audio]

Hi everyone,

Over the past year I've been building several macOS AU/VST3 plugins.

Instead of using JUCE for the interface, I wanted to keep my UI entirely in SwiftUI while using a native audio engine underneath.

The biggest challenge wasn't DSP, but making SwiftUI behave like a responsive plugin UI inside different DAWs.

Things I had to solve included:

• Window resizing
• Host lifecycle
• State synchronization
• Smooth UI updates
• Performance

It ended up working surprisingly well and all three of my plugins now use this architecture.

I'm curious if anyone else here has gone down the SwiftUI route instead of the traditional JUCE approach.

[kerfuffle]

There are a lot of plug-ins that don't use JUCE but the native frameworks. SwiftUI is as native as it gets, although it's worse on Mac than on iOS, unless you're willing to restrict your plug-in to fairly recent versions of macOS.

I personally would use Core Animation over SwiftUI (and have done so, just not in any plug-ins I've released), just because I expect Core Animation to draw a lot smoother than SwiftUI.

But yeah, if you're not looking for a cross-platform library, why not use SwiftUI.

[george]

For macOS-only products I'd probably go the SwiftUI route. But JUCE is good for cross-platform work, and you can add platform native UI via custom modules, so if you want to move into Windows (and you should, to capture a considerable share of the market) you're better off with JUCE.

[hibrasil]

iPlug2 has SwiftUI examples. Just sayin'