Someone Built a Full Swift Compiler in the Browser — And Nobody Is Talking About It 🤯

“You need Xcode to run Swift. You need a Mac to run Xcode. You need Apple’s entire runtime to run SwiftUI. That’s the story everyone accepted. Then one developer sat down and rewrote all three — in C — with zero dependencies.”

I stumbled onto miniswift.run at 11pm on a random Wednesday.

I closed my laptop at 2am.

Not because it was flashy. Not because it had a slick landing page (okay, it does). Because what I was looking at should not exist. A Swift compiler, a complete SwiftUI runtime, a Foundation layer, and a Metal shader compiler — all running entirely in your browser tab. No Xcode. No Mac. No Apple runtime. No npm. No React. No LLVM.

Just Swift. In a tab. Rendered to canvas. With real @State.

The whole thing is 71,000 lines of C. Built by one developer — Ugur Toprakdeviren. And the iOS community has barely noticed.

Let’s fix that.

🏗️ What Ugur Actually Built (Read This Twice)

This isn’t a Swift interpreter. It’s not a transpiler that secretly ships your code to a server. There’s no Apple runtime hiding behind a CDN somewhere.

This is a full compiler pipeline — Lexer → Parser → Sema → IR Gen → SSA → Optimizer → WASM — compiled to WebAssembly and running entirely in your browser tab. Hit Run, and your Swift source gets tokenised, parsed, type-checked, lowered to IR, and emitted as .wasm. Right there. In the tab. Zero round-trips.

Then on top of that compiler, there’s:

• A complete SwiftUI runtime — 52 views, 75 modifiers, a custom intermediate representation called UIIR, and an identity-aware diff engine that surgically rebuilds only the changed subtree on every @State mutation.
• A Foundation layer — Date, Calendar, JSON, UUID, UserDefaults, Unicode 17.0, URL components. 70+ runtime functions.
• A Metal shader compiler — libMetal tokenises Apple MSL, lowers to MIR, emits WGSL, and WebGPU paints the fragment. Raymarching, Mandelbrot fractals, plasma shaders. In a browser tab.

The number that stopped me cold: 0 dependencies. No npm. No LLVM. No clang. No Binaryen. No React. No shims. Every single piece — compiler, runtime, renderer, diff engine, Metal transpiler — written from scratch in C.

🧠 The UIIR Nobody Is Talking About

Here’s the part that gets zero coverage.

SwiftUI’s declarative model has to become actual pixels somehow. Apple does it through CoreAnimation and the native layer. MiniSwift does it through UIIR — a custom UI Intermediate Representation that sits between the Swift compiler and the canvas renderer.

When you write this:

VStack {
    Text("Hello, World!")
        .font(.title)
        .foregroundColor(.blue)
    Button("Tap me") {
        count += 1
    }
}

The compiler doesn’t just emit generic bytecode. It lowers that SwiftUI tree into UIIR JSON — a typed description of your view hierarchy that the canvas renderer knows how to paint. Every modifier, every layout constraint, every presentation flag — all encoded.

Then, when you tap that button and @State mutates, the identity-aware diff engine kicks in. It doesn't rebuild the whole canvas. It finds exactly which subtree changed and surgically swaps only that. The same reconciliation model React built its reputation on — implemented in C, for Swift, running on a canvas.

That’s not a toy. That’s architecture.

🎮 Metal Shaders in a Browser Tab — Wait, What?

If the Swift compiler didn’t break your brain, this will.

MiniSwift ships a separate Metal shader compiler called libMetal. It's 177KB of WASM. It tokenises ~106 Metal Shading Language keywords, lowers to MIR (Metal Intermediate Representation), performs 90+ builtin rewrites, and emits WGSL — the shader language that WebGPU understands.

The result: you write Apple MSL in the browser, and WebGPU renders it live. Edit the Mandelbrot shader, move the mouse, watch the fractal react. Raymarched distance fields. Implicit metaball fields. Polar coordinate tunnels.

// This runs in your browser.
// MSL → MIR → WGSL → WebGPU
fragment float4 plasma(VertexOut in [[stage_in]]) {
    float2 uv = in.uv * 3.0 - 1.5;
    float c = sin(uv.x * 5.0 + time) + sin(uv.y * 5.0 + time);
    return float4(sin(c), cos(c * 0.7), sin(c * 1.3), 1.0);
}

The reason this matters isn’t just “wow, cool demo.” It’s that the entire compiler infrastructure — the same C-based pipeline, the same plugin architecture, the same zero-dependency philosophy — was reused to build a second compiler for a different language on top. That’s what a well-designed compiler core buys you.

📱 The iPhone Frame Is Pure Canvas. No Cheating.

Open miniswift.run and you’ll see your SwiftUI code rendered inside an iPhone bezel. Dynamic Island. Status bar with a live clock and battery indicator. Home indicator at the bottom.

None of that is an image. None of it is a CSS overlay. It’s all painted on a <canvas> element in pure JavaScript, calculated pixel by pixel.

Three device presets: iPhone 16 Pro, iPhone 15 Pro, iPhone SE. And it already ships Liquid Glass support — Apple’s iOS 26 design language with translucent materials, auto-adapting borders, and depth-aware shadows. A browser-based Swift playground that already reflects Apple’s newest design system before most developers have even shipped iOS 26 apps.

That level of attention to detail is not an accident. That’s someone who actually cares.

🔌 The Plugin Architecture That Makes It All Work

Here’s the underrated engineering decision at the core of MiniSwift.

The compiler core knows nothing about the standard library. Zero. The compiler has no hardcoded knowledge of Array, String, Optional, or anything else from stdlib. Instead, modules register type declarations, IR handlers, and WASM builtins via a plugin API.

That’s why it was possible to build the Foundation layer, the SwiftUI runtime, and the Metal compiler as separate layers on top of the same core. Each module self-registers. The core stays clean.

The practical result:

• 290 stdlib runtime functions, 180+ inlined method handlers
• 70+ Foundation functions (Date arithmetic, JSON, UUID, URL resolution)
• 52 SwiftUI views and 75 modifiers — all as plugins
• Metal’s 106 keywords and 90+ builtins — same pattern, different module

This is the kind of architecture decision that separates “someone hacked this together” from “someone thought carefully about how this should grow.”

✅ 751 Tests. Zero Regressions. In a Side Project.

Let that land for a second.

A solo developer, building a Swift compiler from scratch in C, shipping a 751-test suite with a zero-regressions policy. Covering collections, concurrency, generics, error handling, strings, and numerics.

Most production codebases with full teams don’t hold this standard. MiniSwift does. And it publishes an honest, item-by-item coverage page at miniswift.run/support.html — marking exactly what works, what’s partial, and what’s not yet supported. No hiding behind vague “beta” disclaimers.

The things that don’t work yet are documented as clearly as the things that do:

• Animation tween engine → in progress
• @Observable macro → not in scope
• SwiftCharts → absent
• matchedGeometryEffect hero animations → pending

That kind of honesty in a solo open-source project is rarer than the compiler itself.

🆚 MiniSwift vs. Every Other “Run Swift Online” Tool

Swift Playgrounds (Apple) Online REPL tools MiniSwift Runs offline ✅ (app install) ❌ server round-trip ✅ fully in-tab SwiftUI preview ✅ native ❌ ✅ canvas render Real @State ✅ ❌ ✅ Metal shaders ❌ ❌ ✅ MSL → WGSL Zero dependencies ❌ needs macOS/iPadOS ❌ backend server ✅ Open source ❌ partial ✅ msf on GitHub Works on Windows/Linux ❌ ✅ ✅

The critical column is the last row. For the first time, a developer on Windows or Linux can open a browser tab and write real SwiftUI code — with @State, with sheets, with navigation — and see it rendered in an iPhone frame. No Mac required. No Apple Developer account. No Xcode download.

That’s not a convenience improvement. That’s a fundamental change to who can learn and experiment with Swift.

🚀 Try It Right Now

No install. No signup. Just open a tab.

// Paste this into miniswift.run/playground.html and hit Run
import SwiftUI

struct ContentView: View {
    @State private var count = 0

    var body: some View {
        VStack(spacing: 20) {
            Text("Count: \(count)")
                .font(.largeTitle)
                .bold()
            Button("Tap me") {
                count += 1
            }
            .buttonStyle(.bordered)
        }
        .padding()
    }
}

@State mutates. The diff engine fires. Only the Text node rebuilds. The Button stays exactly where it is.

That’s the real browser, running a real Swift compiler, rendering a real SwiftUI diff. In a tab.

❓ The Questions You’re Definitely Asking

Is this actually Swift or a subset? It’s the real language — structs, classes, enums, protocols, generics, closures, async/await, error handling, pattern matching. The compiler doesn’t silently desugar your code into something simpler. It compiles Swift.

Can I use this to ship an app? Not yet. This is a compiler and preview runtime — there’s no bridge to actual device APIs. It’s the best Swift playground on the planet, not a production build target. Yet.

Is the source code available? The Swift frontend (lexer, parser, sema) — msf — is open source on GitHub. The full runtime isn't public yet but the architecture is documented on the site.

How does it handle @State without a native runtime? MiniSwift ships its own JS state engine. When a Button fires, the engine writes the new value into the state store, the UIIR diff walks the affected subtree, and the canvas renderer repaints only the changed nodes. It's a clean, purpose-built system — not a polyfill.

Who built this? Ugur Toprakdeviren. One developer. 71K lines of C. And a sister project — minikotlin.run — doing the same thing for Kotlin. Apparently once you build one compiler from scratch, you just keep going.

🔚 TL;DR

MiniSwift is a full Swift compiler — Lexer, Parser, Sema, IR, WASM — plus a complete SwiftUI runtime, Foundation layer, and Metal shader compiler, all written from scratch in C, running entirely in your browser with zero dependencies. Real @State. Real diff engine. Metal shaders on WebGPU. iPhone 16 Pro frame painted on canvas. 751 tests. Zero regressions. Built by one developer.

It’s the most ambitious open-source Swift project you’ve never heard of.

Go to miniswift.run, paste some SwiftUI code, and hit Run. Then try to explain to me why this isn’t front-page news on every Apple developer blog.

🧑‍💻 Open source frontend → msf on GitHub 🎮 Live playground → miniswift.run/playground.html 📋 Honest coverage page → miniswift.run/support.html

Tags: *swift swiftui webassembly compilers open-source ios-development apple javascript wasm mobile-development frontend programming*