GoKawiilHow Dactyl works
App development has always been harder than web development for LLMs. Apps tend to have platform style norms and layouts, and they need to look and feel a certain way. People can feel when an app is “native” and crafted for their device. Plus, the web is open and universal in a way apps and app stores typically are not, which means LLMs have comparatively less data in their training sets.
Many vibe-coding platforms have tried to solve the problem by, essentially, compromising. They generate apps using Expo/React Native, Flutter, or even just webviews. But we found none of those approaches provides an optimal user experience; you're always sacrificing something, whether it's cross-platform compatibility, native widgets, performance, or features.
We made Dactyl to help you build native apps without those compromises.
Today we present the inner workings of Dactyl’s cross-platform SwiftUI renderer—a Wasm port of the iOS simulator—and how we bring the Apple ecosystem to Android and the web.
iOS previews on the web
We chose Swift as the primary language in Dactyl because of its simplicity and well-defined layout semantics. In fact, Dactyl was initially designed to be a development platform exclusive to iOS.
Previewing an iOS app without a Mac normally means renting one and streaming a real simulator back: a boot, an install, and a launch before you even see the app, metered for as long as you keep working.
That approach only scales as far as your budget allows. But what if you could have a simulator inside your browser? Well, that would scale infinitely. So we built it.
Dactyl’s preview engine is a reimplementation of SwiftUI in Swift, plus the frameworks apps reach for. Plenty of modules are implemented, including Charts, SpriteKit, SceneKit, RealityKit, ARKit, MapKit, StoreKit, MusicKit, PencilKit, WidgetKit, UIKit, CoreGraphics, Metal and Vision.
... continue reading