Drawing SwiftUI previews in a browser when SwiftUI only runs on Apple's systems

SwiftQuest — Wed, 21 Oct 2026 07:34:44 +0000

I've been building a SwiftUI course that runs in the browser, and the hard part was obvious from day one: Apple's SwiftUI only exists on Apple platforms, and the learner's code compiles and runs on Linux servers. Here's how it ended up working, in case it's useful to anyone or someone spots a hole in it.

A stand-in SwiftUI module

There's a stand-in SwiftUI module with the same names and signatures as Apple's. So the learner's file is the file they'd write in Xcode, import SwiftUI and all, and their mistakes get the same compiler errors.

The module draws nothing. A run turns the views into a tree of plain nodes, with each modifier wrapping what it modifies, in order. That order matters for the same reason it matters in real SwiftUI: .padding().background(.blue) and .background(.blue).padding() are different trees.

#Preview is what gets drawn

A macro can't name something a host program can find. So before compiling, the #Preview line gets rewritten to a plain let (line numbers kept, so compiler errors still point at the right line), and a generated main.swift hands every preview to the host.

One run explores the whole screen

After rendering, the host presses every control once and keeps each screen that follows, up to 160 screens within two seconds. When you tap a button in the browser, it just follows a path that was already explored, so there's no second run. A tap that crashes gets pinned to its button instead of killing the whole preview.

The browser does the layout

The browser reimplements SwiftUI's proposal and response rules: stacks sharing space by flexibility, frames and padding proposing and reporting sizes, text wrapping to what it's offered. The constants came from frames the iOS simulator printed: line heights, spacing, button padding, symbol sizes.

Checking it against the real thing

Every example is also drawn with real SwiftUI on the iOS simulator, and the two pictures are compared. The weakest spot is SF Symbols, which are stand-in icons because their licence keeps them on Apple platforms. It's close to Xcode, not identical, and you still finish real apps in Xcode on a Mac.

This is the SwiftUI part of SwiftQuest, a course I'm building. Every exercise runs on a real Swift compiler, each run in its own throwaway gVisor container (I wrote about that sandbox here). The SwiftUI course has 8 destinations and 24 quests, from your first view to one app of your own built in three milestones, and it's open to beta testers now next to the Swift course. There's no deadline, you can be approved the same day, and testers get Pro for life: https://swiftquest.dev/beta?ref=devto

Happy to go deeper on any of the above in the comments.

Running strangers' Swift code: one gVisor container per run

SwiftQuest — Sat, 17 Oct 2026 07:47:15 +0000

I'm building SwiftQuest, a course where you learn Swift by writing it and running it in the browser. Not a simulator, not a toy interpreter: the real Swift 6.4 compiler, on a Linux server, with its real error messages.

That means strangers type code into a box and I compile and run it on my machine. Here's how that works, and what it costs.

The rule: the API never runs learner code

The API server that handles accounts and lessons refuses to compile anything in hosted mode. Every run goes to a separate runner server (an arm64 Linux box) that has one job: take a run, execute it in a sandbox, send back the result.

The API doesn't send commands. It sends a signed job with the run's inputs only: the files, the mode (script, multi-file compile, or a Swift package with tests), the test fixtures. The job is signed with Ed25519 over the exact bytes, with an id, an expiry, and a digest of the plan the API expects. The runner re-plans the command line itself from those inputs and refuses anything that is:

unsigned, expired, or replayed,
planned differently from what the API signed,
outside a small allowlist of run plans.

So even a compromised API can't ask the runner to run curl or rm -rf. It can only ask "compile these files in one of these known ways".

The container

Each job gets its own throwaway container under gVisor (runsc), Google's user-space kernel. The flags are boring on purpose:

--network=none
read-only root filesystem
--cap-drop=ALL and no-new-privileges
runs as uid 1000, not root
caps on memory, CPU, process count, open files and core dumps
two small size-capped tmpfs mounts for the workspace and temp files
no host mounts, and only HOME and TMPDIR in the environment

When the program ends, the container is gone. The next run starts from a clean image with the pinned toolchain.

Testing the sandbox like an attacker

I didn't want to trust my own config, so there's a hostile attack suite: programs written to escape, read secrets, reach the network, or leave things behind for the next run. It runs against the real sandbox on the real runner, not against mocks.

On the current setup it's 18 out of 18: seven real lessons that must still work, and eleven attacks that must all fail. After each attack, a plain run has to pass and no job container may be left behind. A small program that reports facts about itself shows uid 1000, gVisor's kernel, a fresh workspace and no secrets in its environment.

What it costs

gVisor isn't free. Measured on the runner, runc vs gVisor:

a script: 0.18 s → 0.46 s
a compile: 0.24 s → 0.52 s
a cold Swift package build: about 10 s → 22 s

End to end, a learner sees about 1.3 s for a script and 1.5 s for a two-file compile. The first package build is around 20 s. That's fast enough that people hit Run without thinking about it, which matters more for learning than any feature.

Two things that turned out to matter for beginners

Show the compiler's words, not mine. Every error is shown word for word, and a plain-language explanation goes underneath, never instead. One gotcha: Swift's default diagnostic style draws notes inside an ASCII picture of the code, where a line-based parser can't find them, so notes and fix-its were silently dropped. Compiling with -diagnostic-style=llvm prints them as ordinary file:line:col: note: lines.

Test the lesson text like code. Lessons say things like "try changing this to let and see what happens". Each of those suggestions is now a test run against the pinned toolchain (289 of them). The first time I checked, 18 of 90 suggestions were simply wrong. Every starter, solution, demo and hint in the course also runs through the real sandbox: 1,789 checks, about 87 minutes.

Try it

SwiftQuest's beta is open now. All 15 islands and 40 quests are free for testers, there's no deadline, and if you work through it and answer a five-minute survey you keep Pro for life. I'd especially love people who have never written code, plus a few Swift devs to catch anything I teach wrong.

Apply here: https://swiftquest.dev/beta?ref=devto

Happy to answer anything about the sandbox in the comments.

DEV Community: SwiftQuest