No Server, No Wait
About MiniSwift Updates
I've mentioned this many times before, but MiniSwift was released in April 2026 after three years of development. I've come a long way since releasing it. (At some point, I once again realized that you really have to stop working locally and face the real world.) Both the positive and negative feedback I've received have helped me improve tremendously. I'd like to thank everyone for that.
Today (September 7, 2026), I wanted to take a look at some Swift REPLs and playgrounds on the internet. Unfortunately, every one I came across was compiling code on the server side. From a usability perspective, this is both very expensive and, honestly, not very practical.
I simply wrote print, hit Run, and waited about 60 seconds for that simple piece of code to compile.
This is where MiniSwift differentiates itself from its alternatives in five very nice ways.
- Server cost is zero. All the code you write is compiled and executed on your own client. None of it ever reaches the MiniSwift server. If you'd like, you can turn off your internet connection and test it yourself.
- Waiting time. I mean, telling someone who's learning Swift, or someone who just wants to quickly test a piece of code, "Come on, my friend, wait one minute for every line you change" — I don't know, that doesn't feel very acceptable to me in 2026.
- Stdlib. All these playgrounds support the Swift standard library. Maybe that's not something to criticize, but MiniSwift supports a considerable number of libraries from the Apple ecosystem as well. Like Foundation. (Yes, it supports Foundation.)
- Debugger. MiniSwift gives you the ability to debug your code live, without using Asyncify or JSPI. I haven't seen any online Swift REPL do this.
- And, of course, SwiftUI. I'll have a lot more to say about this later.
Of course, alongside this criticism, those kinds of programs have one major advantage: they can give you everything the actual Swift language provides, unconditionally. MiniSwift differs a little here. There may be cases in the Swift language, especially certain edge cases, that MiniSwift doesn't handle correctly. Even though it passes the official test corpus, there may still be edge-case bugs that the native language itself already handles and MiniSwift doesn't. I don't know.
So how does MiniSwift catch these?
This is where real-world projects come in. I continuously compile and test 1,500 randomly downloaded Xcode projects from GitHub with MiniSwift, and I keep moving forward by closing the gaps that show up.
Things That Slow MiniSwift Down
When I develop a project, I start by designing the interface.
In other words: what does this piece of code, module, or library promise to provide?
Once the interface of a project is complete — which also means spending a long time thinking about the project with pen and paper — I believe more than half of the project is already done. Especially if you can anticipate the edge cases. That's where a programmer's experience and understanding of the problem really show themselves. After that point, how the code itself is written and how the internal implementation works really becomes a detail.
I started MiniSwift with the same mindset. For both the MSF I expose externally and the internal implementations, I always designed the interface first.
But after a while, this started getting out of my control.
The reason was that MiniSwift wasn't trying to handle only the Swift language. It was also trying to handle the Apple ecosystem.
Trying to squeeze the entire Apple platform into a single WASM file was, in hindsight, a genuinely crazy idea. My advice to anyone thinking about doing this: don't. :D
Of course, there were reasons for this too. If this article doesn't get too long, maybe we'll get into those as well.
At the beginning, after writing the frontend for the Swift language — parser, lexer, AST, semantic analysis — I scanned all the swiftinterface files on the system and extracted the contracts of Apple's official libraries. I then organized them into separate folders as .swift and .h files, as well as documentation.
From that point on, I generated separate gaps.md and feature.matrix.md files for each one.
In other words: how much of these interfaces do I actually support?
This was the most reasonable way I could find to see what I was missing.
I knew from the beginning that I needed to complete the Stdlib first. But during those three years of development, I had been working on things piece by piece.
The reason was what I can only describe as engineering impatience: I wanted to see SwiftUI code running on the web.
But having SwiftUI code touch something that wasn't implemented was incredibly frustrating. So I imposed some discipline on myself and realized that I first needed to close every gap in the Stdlib.
I managed to do that around four months after going live.
When I finally saw that there were no partial or missing entries left in the Stdlib, I felt relieved.
Naturally, when people using MiniSwift tried some code from the Stdlib and saw that it didn't work, some responded by making fun of it, while others gave genuinely sincere feedback.
I realized that I had at least minimized that risk, and those kinds of reports eventually stopped coming.
Then I noticed that people were simply opening an ordinary console app, writing whatever code they wanted, and testing it.
You might wonder how I figured that out.
Server traffic.
When I looked at the incoming traffic, I saw roughly 10–20 thousand requests per day, and from the sw.js file I realized that MiniSwift had developed a loyal user base. ;-)
Detours
Unfortunately — whether you call it the magic of our profession or its curse — after a while, when you notice yourself doing the same work over and over again, you start asking whether it really needs to be done this way.
The moment you start chasing that question, serious detours begin to appear in the project.
Some of the detours I experienced with MiniSwift came from exactly this.
I realized that much of the work I was doing for Apple frameworks was also very similar to what existed on other operating systems for Kotlin (Android) and C# (Windows). At one point, I even shared a graph about this on social media.
This is where things started branching out for me.
Because alongside Swift's Stdlib, I realized that much of the work being done in other Apple frameworks had very similar counterparts on Android and Windows.
So why shouldn't I move these onto a common platform? :D
Clichés
Like every profession, our industry has its own clichés.
"It can't be done!"
When you start looking for an answer to why, the common response you usually encounter is basically this:
You think you're going to do what these enormous ecosystems — Apple, Android, and the rest — couldn't do? You're the only smart one, huh? You're the only person who thought of this?
Ah, curiosity.
That's what it does to you.
But isn't curiosity also the reason MiniSwift made it this far?
What "it can't be done" really means is this: you can't take this on alone. You'll spend years on it and end up with nothing.
Yes.
That's a much more accurate answer.
And it's a fair one.
But it didn't stop me, because when I started MiniSwift, I never set out saying, "I'm going to cover the entire Apple ecosystem."
Those doors opened later, one by one, as I kept building things and asking myself, "I wonder if I could implement this library too?"
And as of today, all of the following Apple libraries are supported by MiniSwift, even if some of them are still only partially supported:
Accelerate, AlarmKit, AVFAudio, Combine, Compression, CoreData, CoreFoundation, CoreGraphics, CoreImage, CryptoKit, Dispatch, Foundation, GameplayKit, ImageIO, Metal, MetalFX, MetalKit, ModelIO, Observation, QuickLookThumbnailing, SceneKit, simd, Stdlib, SwiftData, SwiftUI, System, UIKit (Partial), UniformTypeIdentifiers.
Exporting to the Web and Other Platforms
Because of the way MiniSwift is structured, once I managed to lower the language into IR, I realized I had an incredible amount of power in my hands.
I could now translate Swift into an intermediate language, and this structure belonged entirely to me.
In other words, without depending on LLVM or anything similar, I had something in my hands that I could shape however I wanted.
The first thing I tried locally was this:
Could I run this language on Android?
The idea of taking an Apple project written using libraries supported by MiniSwift and running it on Android and other platforms was incredibly exciting to me.
And it turned out to be so simple that even I was surprised.
As an example, taking a sample project I'd built using Combine and SwiftData and bringing it to Android became almost child's play for MiniSwift.
Because I could do:
Swift → IR → C
Then I connected that C code to Android through JNI.
Bingo.
When I saw not only the Swift language itself, but Apple libraries running on Android, my brain melted. ;-)
At that point, I realized I couldn't stop working on this.
But there was another problem.
What was I going to do with the SwiftUI code?
At first, I made the mistake of trying to display the SwiftUI code directly on Android. I tried to reproduce the SwiftUI interface one-to-one on Android, but I quickly abandoned that idea.
Then I converted the SwiftUI code into a Compose layout.
That was my second bingo moment.
Because a reactive variable inside code written with a Compose layout, which originated from Combine and had now been translated into C, carried over to Android with the same deterministic behavior.
That was genuinely my WTF moment. :D
Then another question came to mind:
If I could build this structure for Android with just one bridge, why shouldn't it work on other operating systems?
So I immediately tried it with Linux (GTK) and Windows.
This time I wasn't quite as surprised, because I'd already done the same thing. :D
And without JNI, thanks to the incredible power of C.
Seeing a project I had developed for Apple running as-is on Windows, Linux, and Android made me both very happy and a little scared.
The reason I was scared was that I've been developing Apple applications since around 2009 — iOS 3, I think — and I know what kinds of pitfalls and third-party dependencies can exist inside a real project.
Naturally, I knew the first thing people would want to do was test whether their own projects would run on other platforms with MiniSwift.
But maybe as our engineering skills improve, our marketing skills get worse. I don't know.
I was afraid I wouldn't be able to explain this properly.
Because if I couldn't, people would mercilessly call it AI slop. :D
You could say, "Who cares what people think? Just do your work."
I wish I could think like that about everything.
But I'm flesh and blood, and I have a heart.
Naturally, the things people write affect me too.
Let me slip in a small anecdote here.
While I was looking for an answer to the question of whether I could do something similar to MiniSwift with the Kotlin language and the Android ecosystem, the MiniKotlin.run project emerged.
I was quietly working on it on my own when, much later, I discovered a post I hadn't even known existed.
Someone had found the MiniKotlin project and shared it on Hacker News.
And it stayed at number one on HN for quite a while.
A dream I'd had since I was young basically turned into a nightmare.
Reading people say that the person who made this project probably didn't have enough technical knowledge to hold a two-sentence technical conversation, and others calling it AI slop so bad it was basically pig food, genuinely hurt me.
Because I hadn't shared the project on HN.
I didn't even know it was there.
I only discovered it about 12 hours later, when I came home, looked at the server logs, noticed something strange, and figured out what had happened.
By then, people had already talked about me and passed judgment.
So I thought, apparently you're not allowed to publish a project on your own in this world.
First you're supposed to go to the HN crowd and say, "Hey guys, I've got this project I'd like to publish. You won't be mad at me, right?" and get their permission.
Strange.
Anyway, I've gone on too long and wandered away from the subject. Please forgive me.
To quickly wrap things up:
I've added the ability to export to the Web, and I'm aware that it doesn't work perfectly yet. But I've learned that some things simply don't improve until you put them into the real world, so I'm continuing to improve it based on the feedback I receive.
Exporting from MiniSwift to Android, Linux, and Windows is currently ready, but I haven't released it yet because I don't feel confident enough to put it live.
I hope I can release it very soon.
Take care.