Cross-Platform Engineering in Rust

2026-04-07T00:00:00+00:00

Part 2 of the Orbiter technical series. See also: Introducing Orbiter</a>.</em></p>

Orbiter ships as a browser app, a standalone desktop app (macOS, Linux, Windows), an iOS app, an Android app, and six DAW plugins (VST3, CLAP, AU3) — all from one Rust codebase. This post is about how and why.</p>

What Made This Practical</h2>
A few things converged to make this level of cross-platform reach feasible for a solo developer:</p>

Rust's compilation model</strong> — the same code compiles to native binaries, static libraries for C FFI, dynamic libraries for JNI, and WASM, with no runtime or garbage collector to adapt. The C ABI means interop with Swift, Kotlin, and JavaScript is straightforward.</li>
wgpu</strong> — a single GPU abstraction over Metal, Vulkan, DX12, WebGPU, and WebGL2. WebGPU is now shipping in major browsers, making this a practical choice. One rendering path for every platform.</li>
iced</strong> — a GPU-rendered GUI framework with no platform dependencies beyond wgpu. The same widget tree runs everywhere.</li>
Agentic development tools</strong> — maintaining five platform bridges, each with its own FFI contract and build system, would be impractical to do entirely by hand. AI-assisted development made it feasible to write and maintain the bridge code, build scripts, and CI workflows at a pace one person could sustain.</li> </ul>
None of these individually is sufficient. The combination is what makes it work.</p>
The Landscape of Alternatives</h2>
If you're building cross-platform audio software, there are several established approaches. Each makes different trade-offs around licensing, language, platform reach, and web support.</p>
C++ Frameworks</h3>
JUCE</a></strong> is the industry standard. It's mature, well-documented, and has a huge community. But its licensing model</a> is layered — free under GPL (your project must also be GPL), or paid tiers with revenue thresholds ($50K for Personal, $200K for Indie at $40/month, unlimited at Pro for $130/month). After the PACE acquisition</a> in 2022, there's been recurring community concern about licensing stability. On the web, JUCE has experimental Emscripten support</a> but it's not a first-class target — binaries are large, browser API integration is manual, and plugin formats don't translate to the web.</p>
iPlug2</a></strong> has an excellent permissive licence (WDL/zlib) and notably good web support via Web Audio Modules (WAM). It covers VST2/3, AU, AUv3, AAX, and standalone. The GUI framework (IGraphics) is less feature-rich than JUCE's, and the community is smaller, but the licensing and web story are genuinely strong. Still C++ though, with the same WASM-via-Emscripten path.</p>
DPF (DISTRHO Plugin Framework)</a></strong> is lightweight and ISC-licensed (essentially MIT). Good Linux community, supports LADSPA, LV2, VST2/3, CLAP. No mobile, no web. A solid choice for desktop plugins where JUCE is overkill.</p>
DSL and Code Generation</h3>
FAUST</a></strong> takes a different approach: a functional DSP language that generates C++, Rust, WASM, or LLVM from the same source. Web support is excellent (generates AudioWorklet code directly). The GPL compiler produces code you can use under any licence. But it's a DSP authoring tool, not a full framework — you still need something else for the GUI and platform integration.</p>
Web-First Approaches</h3>
Tauri</a></strong> pairs a Rust backend with a web-tech UI (HTML/CSS/JS). Much lighter than Electron (~10 MB vs 100+ MB), and v2 adds iOS/Android. But audio must be handled via native code, and there's no plugin format support. Electron</a></strong> has the same architecture with higher memory overhead and GC pauses that can interfere with real-time audio.</p>
Flutter</a></strong> with dart:ffi can call into native Rust DSP code. Excellent mobile UI story, but Dart's garbage collector can cause audio glitches, and there's no built-in real-time audio — you're bridging to CoreAudio/AAudio yourself. No plugin format support.</p>
Rust-Native</h3>
nih-plug</a></strong> is the leading Rust plugin framework — ISC-licensed, excellent ergonomics, supports VST3 and CLAP with pluggable GUI (iced, Vizia, egui). Actively maintained. It doesn't support AU/AUv3, which is why Orbiter uses a separate au-bridge for Apple platforms.</p>
Vizia</a></strong> is a declarative, CSS-styled Rust GUI framework designed for audio plugins, with a nih-plug integration. Pre-1.0 but maturing. baseview</a></strong> provides low-level windowing for plugin UIs — the foundation that nih-plug and others build on.</p>
Where Rust Fits</h3>
The key gap in the C++ ecosystem is the web. JUCE and iPlug2 both reach it via Emscripten, but it's a second-class experience. Rust compiles to WASM natively, and the tooling (wasm-bindgen, web-sys, Trunk) is designed for it. The key gap in the web-first ecosystem (Tauri, Electron, Flutter) is real-time audio performance and plugin formats. Rust bridges both worlds — native performance with first-class WASM support and C ABI for FFI to every platform.</p>
The trade-off is maturity. JUCE has decades of audio UI widgets, comprehensive documentation, and a proven track record. The Rust audio ecosystem is younger and requires more custom work — especially for mobile, where iced has no built-in support. That's where the original bridging work for Orbiter came in.</p>
GPU Rendering with wgpu</h2>
The entire UI is rendered on the GPU via wgpu, a Rust implementation of the WebGPU standard. The iced GUI framework drives the rendering, and wgpu maps to the native graphics API on each platform:</p>

macOS / iOS</strong> — Metal</li>
Linux</strong> — Vulkan</li>
Windows</strong> — DX12 (Vulkan fallback)</li>
Web</strong> — WebGPU where available, WebGL2 as fallback</li> </ul>
The same iced widget tree and the same rendering code runs everywhere. Two WASM builds are produced (WebGPU and WebGL2) and the correct one is loaded at runtime based on browser support. On native platforms, wgpu selects the high-performance GPU adapter by default with a low-power fallback.</p>
Mobile: Custom iced Integration for iOS and Android</h2>
On desktop, iced runs on top of winit for windowing and event handling. On iOS and Android that's not an option — the native platform owns the window, the render loop, and the touch event system. iced has no built-in mobile support.</strong> Getting it running on iOS and Android required building custom integration layers from scratch — original work done for Orbiter (to be open sourced) that doesn't exist elsewhere in the iced ecosystem.</p>
On iOS</strong>, Swift creates a CAMetalLayer and passes it to Rust via C FFI. Rust creates a wgpu Metal surface directly from the layer pointer, then drives iced's `UserInterface</code> manually — building, updating, and drawing each frame without winit. CADisplayLink controls the render loop from the Swift side, calling into Rust each frame and receiving a redraw flag back. When iced has nothing to update, the display link pauses. Touch events are batched by Swift into C structs (phase, finger ID, coordinates) and forwarded across FFI, where they're translated into iced touch::Event</code> values.</p>`
`On Android</strong>, the pattern is similar but via JNI instead of C FFI. A Kotlin SurfaceView</code> provides the native window, which Rust converts to a wgpu Vulkan surface. The render loop is driven by Choreographer</code> frame callbacks. Touch events arrive individually through JNI calls. The crate is compiled as a cdylib</code> (shared library loaded by the Android runtime), unlike iOS where it's a staticlib</code> linked into the app binary.</p>`
`Both platforms share the same adaptive rendering strategy: a custom iced Notifier</code> implementation that signals the native side when a redraw is needed, letting the platform pause the render loop when idle.</p>`
Toward Shared Crates</h3> The iOS and Android integration code is currently Orbiter-specific, but the core of it — driving iced's UserInterface</code> from a native render loop, translating touch events across FFI, managing wgpu surfaces from platform-provided GPU layers — is generic. I'm planning to extract this into standalone crates (iced-ios-bridge</code>, iced-android-bridge</code> or similar) that any iced project could use to target mobile. The FFI contracts are already well-defined and the architecture is deliberately minimal — the native side provides a GPU layer and touch events, Rust handles everything else.</p>
Web: Four Threads in the Browser</h2> The web build has the most complex threading model because browsers enforce strict separation between contexts. Four independent WASM modules run on separate threads — audio runs in an AudioWorklet for low-latency playback, while ML inference and collaboration stay off the main thread to minimise CPU contention.</p> The main thread</strong> runs the iced GUI via wgpu compiled to WASM. The AudioWorklet</strong> runs the DSP engine in a dedicated audio processing thread — a separate Rust crate compiled to WASM independently. A collaboration worker</strong> handles Loro CRDT sync over WebSocket. An ML sequencer worker</strong> runs the generative model inference.</p> Trunk builds the WASM app, wasm-pack builds the workers, and Zola builds the static site that hosts it all. Two variants are produced — WebGPU and WebGL2 — and the correct one is loaded at runtime based on browser capabilities.</p>Desktop</h2> Desktop is the most straightforward target: Winit for windowing, wgpu for rendering, cpal for audio I/O. A real-time priority thread runs the DSP, with rtrb lock-free ring buffers for UI-to-audio communication. This is the standard iced architecture with no custom embedding needed.</p> DAW Plugins</h2> For producers and sound designers, the same engine runs as a plugin inside a DAW. Two plugin frameworks handle the wrapping:</p> nih-plug</strong> produces VST3 and CLAP binaries. The GUI is embedded via nih_plug_iced, which hosts iced inside the plugin window provided by the DAW.</li> au-bridge</strong> produces AU3 (Audio Unit v3) extensions for macOS and iOS. Each instrument is compiled as a separate Rust static library, and a Swift wrapper builds the AUAudioUnit parameter tree from metadata exported by Rust via FFI.</li> </ul> Six plugins total: three instruments, each available as both a synthesizer and an audio effect.</p> MIDI & Sync</h2> MIDI uses midir across all platforms — CoreMIDI on macOS/iOS, ALSA on Linux, WinMM on Windows, Web MIDI API in the browser. All available ports are connected simultaneously with hot-plug detection. MPE is fully supported: per-note pitch bend, pressure, and slide (CC74) control individual voice parameters through per-voice modulation.</p> Tempo sync supports two alternative transports: MIDI Clock (all platforms, leader or follower) and Ableton Link (native apps only, network tempo and phase sync over LAN).</p> Try Orbiter in your browser →</a></p>

Introducing Orbiter

2026-04-05T00:00:00+00:00

Building software is an engineering discipline in 2026 about as much as it ever has been, but it also feels like an art form more than I certainly ever felt it: suddenly it is far more likely the case that if I can imagine it, I can also build it. I am sure I am not alone in thinking that when I don't have to worry about punishing implementation difficulty, it becomes natural to spend time getting deeply curious, imagining and experimenting on things that feel fascinating but borderline impossible to implement. Orbiter is just such a thing of engineered mild madness for me.</p>

Orbiter is a generative ambient music system.</b> Its built-in sequencer composes meditative music in real time, or you compose together with it — driving physically modelled instruments. At this point there are three instruments available in the suite: handpans, gongs and singing bowls, but I am building some more.</p>

This app is my best take on a few specific physical modelling synthesis methods as someone who is still learning, and an expression of a claim that an indie developer can</em> now build and deploy an ambitious cross-platform suite of software, powered by something as hard as real-time audio digital signal processing (DSP) and on-device machine learning (ML) inference, across web, desktop and mobile platforms, with native technologies instead of web view slop.</p>

Here it is, running live in the browser (click Play to set it off):</p>

</iframe> </div> The thing is, Orbiter also</em> runs on macOS, Windows, Linux, iOS, and Android — with VST3, AU3, and CLAP plugins</a> for DAW integration. A separate post</a> covers how I approach this going cross-platform to this degree (in a few words, Rust and wgpu</a>).</p>

macOS — Orbit</figcaption></figure>
Windows — Edit</figcaption></figure>
Linux — Instrument Parameters</figcaption></figure>
iOS — Edit</figcaption></figure>
Android — Orbit</figcaption></figure> </div>
Really Orbiter was initially a series of related experiments, focused on the following three challenges:</p>

Realising a software instrument that feels, sounds and looks immediate, beautiful, and strange</strong> in the right kind of way, on all the supported platforms.</li>
Showcasing physical modelling realtime DSP and on-device ML inference</strong> across web, desktop, and mobile.</li>
Shipping a single codebase</strong> as a web app, and as a standalone desktop and mobile app, and a set of DAW plugins simultaneously — without relying on Electron, Tauri, or other webview-based approaches.</li> </ol>
Physical Modelling</h2>
The flavour of immediate and strange synthesis method that I was drawn is physical modelling, in particular modal synthesis. Perhaps because I play the cello (and lately the String Armonica mkII</a>) and have enjoyed tinkering with electroacoustics (MIDI controlled solenoids</a> and the Microphonic Playground</a> for the win), it feels interesting to build an instrument that both takes inspiration from something that really exists in physical space, but is impossible, unreal in some way (for example, its physical properties can be modulated / automated over time).</p>

Modal synthesis at its simplest: a strike or bow excites a bank of resonators, each tuned to a vibrational mode of the physical instrument. The modes ring and decay independently, summing to produce the output sound.</figcaption> </figure>
Handpan seemed like an interesting starting point for exploring this: (a)</span> I love the sound, (b)</span> a model that captures a bit of its character is relatively simple and low in computational complexity, and (c)</span> there are lovely, oddball scales involved (Hijaz, Kurd, Pygmy, to name a few).</p>
I built the first prototype of these ideas using the Rust based nih-plug</a> (with iced</a>), as a DAW plugin, and tested with Ableton Live and Bitwig. The nih-plug provied standalone app distribution mechanism provided a handy way to prototype the feel of the app as a standalone app.</p>

The first screenshot of the app (as a DAW plugin), then called "Orbiter".</figcaption> </figure>
</audio>
An early demo — handpan in D Hijaz.</p> </div>
On hearing it I was hooked and wanted to expand to additional, more complex physical models: a gong, and a bowed singing bowl, based on research literature. Each instrument reflects a different, relevant physically inspired principle:</p>

Handpan</p></div>
Gong</p></div>
Singing Bowl</p></div> </div>

Handpan</strong> — uses modal synthesis</a> with biquad resonators modelling individual vibrational modes. I found Alon (2015)</a> "Analysis and Synthesis of the Handpan Sound" particularly useful — it provided mode frequency ratios and decay times, the detuned mode pair structure that gives handpans their shimmering sustain, Helmholtz cavity coupling for warmth, and an excitation model. There is still a lot more to explore in that thesis alone.</li>
Gong</strong> — also modal, but the modes interact with each other. The challenge is capturing the pitch-shifting swells and rising shimmer as energy cascades from lower to higher modes after a strike. This is modelled using the Föppl–von Kármán equations</a> for large-deflection plate vibration, where the coupling between modes grows with amplitude (hence "nonlinear" — hit harder and the modes interact more). The approach follows Bilbao et al. (2023)</a> "Real-Time Gong Synthesis" (DAFx-23).</li>
Singing bowl</strong> — combines modal resonance with an elasto-plastic friction model (Dupont et al., 2002</a>) for bowing. The challenge is the sustained, slowly wavering tone produced by stick-slip friction when a rim is rubbed — the puja mallet alternates between sticking and slipping, driving inharmonic modes into self-sustained oscillation.</li> </ul>
Once I got the app running both standalone on the web and as a DAW plugin, ideas began to flow. How about…</p>

Sharing a sequence state by URL</b>: especially since I can ship this thing for real on the web, what if I could send the sequence I'm hearing to someone else in that same exact state and we could just sit there and enjoy it together? Or explore the sound together, collaboratively</b>, changing the scale, or instrument and FX parameter knobs together in real time?</li>
What if each parameter had slightly chaotic, out-of-sync low-frequency modulation</b>, so the sound slowly breathes and evolves on its own? Who doesn't love a good slow-evolving, complex modulation where you discover new nuances as you concentrate (omgomgomg, one day I want to reach Triple Sloth</a> Eurorack module grade dream state with the Orbiter modulation system too).</li>
Patch randomisation</b>: what if each random sequence produced by the app (identified by its random seed) also had its own unique set of instrument, scale type and root note parameters? Give also a fast way to randomise individual instrument parameters.</li>
Since the rule-based sequencer is so much fun, wouldn't it be nice to drive a DAW like Ableton or Bitwig with MIDI output from the app, with MIDI clock or Ableton Link based sync</b>?</li>
A playback timer</b>, so you can relax and fall asleep to it.</li>
… and so on.</li> </ul>
Slowly (I mean, not that slowly) the exploration revealed the definition for a musical tool with a pretty coherent shape, with a lot more to it than I thought I would be able to put together. The biggest surprise discovery though was still to come, and that is something I am calling a composition assistant</em>.</p>
Composition Assistant</h2> Algorithmic composition has a long history — from Mozart's dice games</a> through Xenakis's stochastic music</a>, Brian Eno's generative systems</a>, and more recently neural approaches like Music Transformer</a>. A generative process created with a small symbolic music language model baked into a tiny web based, or entirely native, app bundle, with battery friendly, GPU accelerated inference felt like quite an interesting challenge.</p>
I trained a novel, autoregressive transformer model (a "small language model", or perhaps an agentic</em> composition assistant, to be 2026-compatible) for Orbiter, and it is indeed bundled in the app: it generates notes with velocities and durations, either autonomously or in response to notes you play. The model architecture, training method, and data augmentation methods I developed for Orbiter are going to get a post of their own at the point I feel I have explored this in full.</p>
System overview: MIDI input and the composition assistant feed notes into physically modelled instruments, with audio and MIDI output across all platforms.</figcaption> </figure>
There are three different generative sequencer modes bundled in the app:</p>

Rule-based</strong> — deterministic patterns where the same URL and system clock always produce the same music, making every session shareable by link. This is what you hear by default.</li>
Autonomous</strong> — the model generates notes continuously on its own, streaming an evolving composition based on the current scale and tempo.</li>
Call & Response</strong> — play notes to prompt the model, which responds with complementary musical phrases.</li> </ul>
In autonomous mode, the model generates continuously with a sliding context window, keeping the output evolving.</figcaption> </figure>
Once I had built the call & response mode, suddenly the MIDI in & out capabilities in the app came to full bloom, opening a whole new set of possibilities: I could use this thing to help generate ideas in Ableton, with all the power of its built-in instruments and effects and my plugin arsenal!</p>
Collaboration</h2>
Sharing a link is all it takes for two people to experiment together in real time — in the browser with no install, or from the desktop and mobile apps. One person can teach other(s) how the instrument works, change scales, twist knobs, and the other hears and sees every change instantly. It is a zero-friction way to explore sound together.</p>
Under the hood, the entire application state — every knob, the scale, root note, sequencer seed — is synchronised between users via a CRDT</a> (conflict-free replicated data type), so concurrent edits merge automatically. Modulators still run locally, so the sound breathes independently for each listener. I intend to open source the collaboration server I developed for this purpose separately.</p>
Available Everywhere</h2>
Orbiter runs on iOS, macOS, Windows, Linux, and Android, as well as in the browser. For producers and sound designers, it's also available as a plugin: VST3, Audio Unit v3, and CLAP are all supported, so you can bring the generative engine directly into your DAW workflow.</p>

Ableton Live</figcaption></figure>
Bitwig Studio</figcaption></figure> </div>
</audio>
Handpan melody, through the gong resonator.</p> </div>
Technically, this meant addressing low-latency audio and GPU-accelerated rendering using native GPU libraries (Metal, Vulkan, DX12) on native platforms, and even in the browser (WebGPU with a WebGL2 fallback), with WebGPU acceleration and a CPU fallback for ML inference across all platforms. Rust and its WASM-targeting ecosystem turned out to be crucial: native performance across every platform, with first-class compilation to WebAssembly for the browser.</p>
The top lesson I can draw from building this way is that creativity really blossoms when you are equipped with a well thought through agent harness</a>. As long as I am pretty damned meticulous about that harness and the upfront degree of automated testing, I am freed from being quite so level-headed about implementation risk and limits of my capacity to realise something complex. For the first time in my life with a realtime audio related project, I felt the It will be easy, probably just a quick weekend project</q> moment. As much as that was a fallacy (always is), it is also a sign of having hit a fun problem when you realise that now is too late to give up on it (I love a good moment of "Schlep blindness"</a>).</p>
At any case, this is the first in a series of posts about Orbiter. Next: Cross-Platform Engineering in Rust</a> — how one codebase runs across browser, desktop, mobile, and DAW plugins.</p>
Try Orbiter in your browser →</a></p>

Orbiter - Blog

Cross-Platform Engineering in Rust

The Landscape of Alternatives</h2> If you're building cross-platform audio software, there are several established approaches. Each makes different trade-offs around licensing, language, platform reach, and web support.</p>

GPU Rendering with wgpu</h2> The entire UI is rendered on the GPU via wgpu, a Rust implementation of the WebGPU standard. The iced GUI framework drives the rendering, and wgpu maps to the native graphics API on each platform:</p>

DAW Plugins</h2> For producers and sound designers, the same engine runs as a plugin inside a DAW. Two plugin frameworks handle the wrapping:</p>

Introducing Orbiter

The Landscape of Alternatives</h2>
If you're building cross-platform audio software, there are several established approaches. Each makes different trade-offs around licensing, language, platform reach, and web support.</p>