When people ask what Oxid apps are built on, the short answer is: Rust.
The longer answer involves memory safety without garbage collection, zero-cost abstractions, a type system that rejects data races, and a compiler that catches whole categories of bugs before the code ever runs. Every Oxid app has Rust in it, though how much varies a lot from app to app. Here's how it shapes what we build, and where it stops.
Why Rust for Desktop Apps?
Most macOS apps are written in Swift or Objective-C. These are excellent languages with deep Apple ecosystem integration. We use Swift too -- for UI layers, system integration, and anything that talks directly to AppKit or SwiftUI. Ten of our twelve apps have a SwiftUI interface. The other two, Oxid Studio and Oxid Note, are built with Tauri: a web interface drawn by the macOS web view, over a Rust backend.
For the core engine of each app -- the part that talks to servers, parses files, manages state and does the heavy lifting -- we usually choose Rust. Here's why:
Memory Safety Without a Garbage Collector
Swift uses Automatic Reference Counting (ARC) to manage memory. It works well, but ARC has a runtime cost: passing an object around increments and decrements a counter.
Rust takes a different approach. Its ownership system tracks memory at compile time. There's no garbage collector, and no reference counting unless you ask for it. Memory is freed deterministically, when its owner goes out of scope.
The result: in safe Rust, use-after-free and dangling pointers are compile errors rather than crashes you find later.
Concurrency the Compiler Checks
Apple silicon Macs have several performance and efficiency cores, and using them means doing work in parallel. Concurrent programming is notoriously error-prone -- data races and deadlocks are the stuff of debugging nightmares.
In safe Rust, a data race is a compile error: the type system won't let two threads mutate the same data without synchronisation. That guarantee covers safe code only; unsafe blocks and the bridge to Swift or C are outside it, and it doesn't prevent deadlocks or logic bugs. You can read how it works in the Rust book's chapter on concurrency.
Some places it shows up:
- Oxid SiteMirror crawls a site with several requests in flight at once (by default 4 per host and 16 in total), all coordinated by its Rust engine.
- Oxid Transfer queues transfers in a Rust engine. Transfers to different servers run at the same time; transfers to the same server currently go one after another.
- Oxid Mail syncs, indexes and searches mail in its Rust core while the SwiftUI interface stays separate.
Zero-Cost Abstractions
In many languages, writing clean, abstract code comes with a performance penalty. Rust's "zero-cost abstractions" principle means that high-level constructs like iterators, generics, and pattern matching are designed to compile down to the same machine code you'd write by hand.
We write expressive, maintainable Rust, and we don't pay extra at run time for the abstraction.
Rust + Swift (and, Twice, Tauri)
Most of our apps follow this separation:
┌─────────────────────────────┐
│ SwiftUI / AppKit │ ← UI Layer (Swift)
│ Native macOS Interface │
├─────────────────────────────┤
│ Swift ↔ Rust Bridge │ ← FFI Layer
├─────────────────────────────┤
│ Rust Core Engine │ ← Business Logic (Rust)
│ File I/O, Processing, │
│ Algorithms, State │
└─────────────────────────────┘
Swift handles everything the user sees and touches: windows, menus, drag-and-drop, and system integration. It's the right tool for UI work, with first-class access to Apple's frameworks.
Rust handles work under the hood: network protocols, parsing, indexing, crawling and application state.
The bridge between them is C-compatible FFI (Foreign Function Interface), generated for us by tools such as UniFFI and cbindgen.
The split isn't the same everywhere. In Oxid VM the virtual machines are driven from Swift through Apple's Virtualization framework; Rust is its command-line tool, its MCP server and the agent that runs inside Linux guests. In Oxid Mac Cleaner the junk scanner and cleaner are Rust, while the large-file and duplicate finders are Swift. In Oxid Studio and Oxid Note, the top layer is a Tauri web view instead of SwiftUI.
Where This Shows Up
Rather than quote benchmark numbers we haven't measured, here is what the architecture actually buys, app by app:
Oxid Mac Cleaner scans for caches, logs and app leftovers in its Rust core and shows you what it found, by category, before you clean it.
Oxid Studio ships an arm64 media engine with FFmpeg bundled — a build made for this app, LGPL, using VideoToolbox for H.264 and HEVC — so a clean Mac can import and export without installing anything else. Its Rust backend drives that FFmpeg for every export.
Oxid VM runs Linux and macOS virtual machines through Apple's Virtualization framework, with a Rust command-line tool and MCP server alongside.
OXAMP ships Apache, MariaDB and PHP compiled from source as relocatable arm64 binaries, run by a supervisor written in Rust. Nothing is resolved from Homebrew at runtime, which is why it starts the same way on a machine that has never had a developer stack installed.
The Developer Experience
Beyond performance, Rust makes us more productive:
- The compiler catches bugs early. Use-after-free and data races in safe code are compile-time errors, and an out-of-bounds index is a checked panic rather than silent memory corruption.
- Refactoring is safer. When we change a data structure, the compiler tells us every place in the codebase that needs to be updated.
- Dependencies are reliable. Cargo, Rust's package manager, handles dependency resolution, building, and testing in one tool.
None of this stops logic bugs. We still ship them, and fix them — the product pages say plainly what each app does not do yet.
Why This Matters to You
You don't need to care about programming languages to benefit from Rust. What it gives you is a class of crash that safe Rust code rules out: memory corruption in the engine. It doesn't make an app fast or light on its own, and we haven't published measurements of launch time, battery use or memory, so we won't claim them here. Parts of every app are also Swift, C (FFmpeg, for example) or, in two apps, a web interface, and the guarantees above apply to the Rust parts.
Building the Future on Rust
Rust adoption is growing. The Linux kernel now has Rust support.
We're glad to be building on this foundation. Every new Oxid app starts with a Rust core.
Explore our apps and see what each one does.