The interesting part is the boundary. Swift compiles to WebAssembly, the framework code writes binary drawing commands into linear memory, and something on the other side paints them [7]. In the browser that something is Canvas2D [7]. On Android it is a Jetpack Compose host that reads the same command stream over JNI [10]. One serialization format, two painters.
That is why the framework surface can grow without doubling the work. The recreated pieces of Charts, SpriteKit, MapKit, StoreKit, Metal and the rest sit above the command stream [6], so they are written once; only the backend is per-platform. Count the frameworks named in the post and add SwiftUI itself and you get 15 API surfaces held to Apple's observed behavior [18].
The rendering path has the expected optimizations. A reconciler retains the view tree between passes, and offscreen canvases cache layers that have not changed [8]. That tells you where the design expects to be slow: a subtree that churns every frame gets no benefit from either, because both bets pay out only when most of the tree is stable.
Correctness here is defined by observation rather than by a spec. Dactyl renders a scene in Apple's simulator, captures the output, and compares it pixel by pixel with its own renderer; vision language models identify the discrepancies and dispatch coding agents to edit the framework implementation until the difference falls below a set threshold [14]. Moving interfaces get a virtual clock with fixed-step frame sampling, plus synthetic taps and key presses injected at specified moments, and per-frame game nodes and trajectories are compared as well [15]. Srivastava describes rerunning those scenes after an iOS update to find where the renderer has drifted [16]. This is genuinely good test engineering: the oracle is cheap to rerun, and the agents are doing framework-parity chores instead of sitting in the chat box [19]. Using a vendor's simulator as your conformance suite does mean your suite changes when the vendor ships.
What the harness asserts is what a frame and an injected event can show. Srivastava's own framing of why mobile is hard lists navigation, controls, keyboard behavior, animation and accessibility [3]. Four of those five leave marks in a captured frame or respond to a synthetic tap. The accessibility tree does not.
The published evidence is one demo: the same Swift source running in an iPhone simulator and as an APK on an Android emulator [11]. Dactyl has not published independent performance testing or broad compatibility results for production applications [12]. Treat the demo as an existence proof. For it to transfer to your app, the app has to stay inside the parts that were recreated, and the behavior you care about has to be visible to the oracle. Animations also have to be reproducible under fixed-step sampling, which rules out anything driven by wall-clock time or real input timing.
The strategic claim underneath, per runtimewire.com, is that the defensible layer in AI app development is the toolchain around generated code rather than the code [17]. Removing the remote Mac, the simulator boot and the build-streaming loop from a preview [9] is a real piece of that. The price is written into the same design: Apple and Google can move their interface frameworks independently, and Dactyl owns keeping both sides aligned [13]. That bill is denominated in someone else's release cadence.
