Deno's Dactyl rebuilds SwiftUI to preview apps in browsers and target Android

Deno's Dactyl has built its own SwiftUI implementation to preview iPhone apps in a browser and compile the same Swift source into Android applications, according to an August 26 technical post by Deno software engineer Divy Srivastava. The architecture compiles Swift apps to WebAssembly, sends binary drawing commands through linear memory, and paints them in the browser with Canvas2D, avoiding the need for remote Macs and simulators. Dactyl's Android version uses a Jetpack Compose host communicating with its Swift engine through JNI, though push alerts and Google Play publishing remain unfinished.

Deno's Dactyl rebuilds SwiftUI to preview apps in browsers and target Android Deno engineer Divy Srivastava detailed a Wasm renderer that avoids streamed Macs, while push alerts and Google Play publishing remain unfinished. By RuntimeWire Staff /author/runtimewire-staff · Published Primary source: Dactyl https://dactyl.dev/blog/how-dactyl-works/ Why it matters Dactyl is betting that the defensible layer in AI app development is the toolchain around generated code. Rebuilding SwiftUI could make native previews cheaper and faster, but it also leaves Dactyl responsible for tracking Apple and Android as both platforms change. Dactyl https://dactyl.dev/?ref=runtimewire , the prompt-driven app builder made by Deno's team, has built its own SwiftUI implementation to preview iPhone apps in a browser and turn the same Swift source into Android applications. Divy Srivastava https://github.com/littledivy?ref=runtimewire , a Deno software engineer, laid out the architecture in an August 26 technical post https://dactyl.dev/blog/how-dactyl-works/?ref=runtimewire . His argument starts with a problem familiar to anyone who has asked an AI coding tool to move beyond the web: mobile software carries platform-specific expectations that a responsive website cannot imitate. Navigation, controls, keyboard behavior, animation and accessibility all contribute to whether an app feels at home on a device. Srivastava says Dactyl initially targeted iOS alone. The project grew into a larger attempt to bring that development model to browsers and Android without making developers maintain separate codebases. The work fits the instincts of the Deno https://deno.com/company?ref=runtimewire engineers behind it. Deno co-founders Ryan Dahl and Bert Belder previously worked on Node.js, with Dahl creating the runtime and Belder helping bring it to Windows. Their later products have repeatedly tried to remove setup and infrastructure from software development. Dactyl applies the same approach to mobile development, where the required toolchains still begin with large downloads, platform-specific hardware and app-store procedures. Putting a SwiftUI renderer inside the browser Dactyl's preview engine is a reimplementation of SwiftUI written in Swift. Apps compile to WebAssembly and link against Dactyl's implementation instead of Apple's runtime. Dactyl says it has recreated parts of frameworks including Charts, SpriteKit, SceneKit, RealityKit, ARKit, MapKit, StoreKit, MusicKit, PencilKit, WidgetKit, UIKit, CoreGraphics, Metal and Vision. Dactyl's documented technical design compiles Swift apps to WebAssembly, sends binary drawing commands through linear memory, and paints them in the browser with Canvas2D. A reconciler retains the view tree between rendering passes, while offscreen canvases cache layers that have not changed. That architecture lets Dactyl avoid the usual browser-based iOS development setup: renting a remote Mac, booting Apple's simulator, installing each build and streaming the resulting screen back to the user. Dactyl loads its renderer locally in the page instead. AI-generated source code is becoming widely available. A fast, portable toolchain that can compile, preview, install and publish that code is harder to reproduce. Swift on Android, with Compose as the host Dactyl takes a different route on Android. A Jetpack Compose host communicates with Dactyl's Swift engine through JNI and reads the same command stream used by the browser renderer. In its technical post https://dactyl.dev/blog/how-dactyl-works/?ref=runtimewire , Dactyl presented the same Swift source running in an iPhone simulator and as an APK on an Android emulator. The company presented the Android version as the same build rendered through its Jetpack Compose host. Dactyl has not published independent performance testing or broad compatibility results for production applications. The Android strategy also creates a maintenance obligation. Apple and Google can change their interface frameworks independently, leaving Dactyl responsible for keeping its SwiftUI reimplementation and Compose host aligned with both. Dactyl is using agents to maintain the renderer Srivastava says Dactyl automates much of that work https://dactyl.dev/blog/how-dactyl-works/?ref=runtimewire with AI agents. According to his technical post, Dactyl renders scenes in Apple's simulator, captures the output and compares it pixel by pixel with its own renderer. Visual language models identify discrepancies and dispatch coding agents to edit the framework implementation until the difference falls below a set threshold. For moving interfaces, the post describes https://dactyl.dev/blog/how-dactyl-works/?ref=runtimewire a virtual clock with fixed-step frame sampling and synthetic taps and key presses injected at specified moments. Dactyl also compares per-frame game nodes and trajectories to test animated scenes. The technique uses Apple's simulator as a reference implementation. Dactyl can rerun scenes after an iOS update and identify where its renderer has drifted. The agents handle repetitive framework-parity work rather than serving only as the product's chat interface. A crowded market, with a different technical wager Dactyl arrives as mobile app generation becomes its own category. Expo Agent https://expo.dev/blog/expo-agent-beta?ref=runtimewire entered beta in March with support for SwiftUI, Jetpack Compose and React. Rork https://rork.com/faq?ref=runtimewire offers React Native and Expo projects through its Pro product, while its higher-priced Rork Max exports native SwiftUI projects. Dactyl's distinction is the decision to recreate the simulator rather than stream one, then use the same Swift-based layout engine to drive Android controls. That removes the remote Mac from the live preview loop and gives Dactyl tighter control over build latency and infrastructure costs. Dactyl's own device documentation https://dactyl.dev/docs/device/?ref=runtimewire describes material production gaps. Push notifications are unsupported. HealthKit and WeatherKit applications do not build. SwiftData is limited to in-memory storage, so data disappears after a reload unless an application uses Dactyl's cloud layer. Some browser previews substitute browser features or sample information for device APIs. Google Play publishing is still planned https://dactyl.dev/?ref=runtimewire , although Dactyl can produce Android APKs for direct installation. Dactyl's commercial model reflects its focus on the toolchain. Its pricing page https://dactyl.dev/pricing/?ref=runtimewire lists a free plan, a $20-per-month Builder plan with 200 monthly credits and three publishing actions, and a $100-per-month Standard plan. Dactyl is selling the machinery around generated code: compilation, previewing, signing, device installation and app-store submission. Srivastava's renderer gives that pitch technical substance. Its value will depend on whether Dactyl can keep pace with two mobile platforms while closing the gaps that separate a convincing demo from an application people can rely on.