Dactyl: SwiftUI + Wasm para crear apps nativas con IA

Por qué las apps siempre han sido más difíciles para los LLMs que la web

El equipo detrás de Dactyl abre su blog técnico con una observación incómoda para el ecosistema vibe coding: los modelos de lenguaje tienen muchos más datos de la web que de aplicaciones móviles. Las apps responden a normas de plataforma, layouts característicos y una sensación «nativa» que los usuarios detectan aunque no sepan articularla. La web, en cambio, es abierta y universal.

El atajo habitual ha sido transigir. Plataformas como Lovable o Base44 —esta última adquirida por Wix por US$80M según publicó TechCrunch— generan apps usando Expo/React Native, Flutter o, en el peor de los casos, webviews. El resultado compila, pero sacrifica algo: compatibilidad, widgets nativos, rendimiento o features. Dactyl apuesta por lo contrario: compilar SwiftUI real y ejecutarlo en cualquier sitio, incluido el navegador.

SwiftUI compilado a Wasm: un simulador de iOS dentro del navegador

El motor de previsualización de Dactyl es, en esencia, una reimplementación de SwiftUI escrita en Swift, con varios frameworks clave ya portados: Charts, SpriteKit, SceneKit, RealityKit, ARKit, MapKit, StoreKit, MusicKit, PencilKit, WidgetKit, UIKit, CoreGraphics, Metal y Vision. Las apps se compilan a WebAssembly y se enlazan contra esta SwiftUI propia en lugar de la de Apple.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El motor emite un stream binario de comandos de dibujo en su memoria lineal, y un host JavaScript lo lee y lo pinta sobre un Canvas2D. El layout se resuelve completo antes de escribir cualquier comando, y un reconciler conserva el árbol de vistas entre pasadas: solo marca como «sucias» las vistas que leyeron algo vivo ese frame, como animaciones o contenedores con scroll. El host rasteriza cada capa una vez sobre un offscreen canvas indexado por un hash de su contenido, y luego la compone en frames posteriores. Por eso Dactyl renderiza layouts complejos de SwiftUI de forma fluida directamente en el navegador, sin instalación previa.

El truco que hace viable el Wasm: dynamic linking

Hay un detalle de ingeniería que importa mucho a quien evalúa la herramienta: SwiftWasm enlaza estáticamente. El motor completo ronda los 100 MB, y un enlace estático obligaría a enviar cientos de megabytes al navegador en cada edición. Dactyl lo resuelve separando el build:

El motor y la standard library se enlazan una sola vez como un módulo base, content-addressed. El navegador lo descarga y compila una vez y lo conserva entre ediciones.
Tu app se compila aparte como side module position-independent, ocupando entre 8 KB y 300 KB. Al cargar, se coloca en un offset de memoria en runtime, sus imports se bindean a los exports de la base, y su type metadata de Swift se registra con el runtime base. El swap ocurre bajo la app en ejecución. @State se snapshottea antes y se restaura después, así la posición de scroll, los campos de texto y los datos de la app se preservan entre ediciones.

Para un founder esto significa una cosa simple: el ciclo de edición es rápido incluso cuando el framework subyacente pesa cientos de MB.

Android: el mismo motor, host distinto

En Android, el motor compila de forma nativa para aarch64-unknown-linux-android24 con el Swift Android SDK y se empaqueta como librería compartida. Un host de Jetpack Compose lo carga y lo conduce sobre JNI. El command stream se lee directamente de la memoria nativa, sin copia: el host de Compose decodifica los mismos bytes que el del navegador.

Donde el host del navegador pinta un control sobre el canvas, el host de Compose monta un switch, text field o date picker Material real en ese rectángulo, con foco, ripple, teclado y accesibilidad nativos. SF Symbols y Material Symbols son sets distintos con nombres distintos, así que una tabla de mapeo generada cubre ambos hosts. La densidad de Compose se ancla a la escala de layout del motor y no a la del dispositivo, por lo que los controles caen exactamente sobre los rectángulos que el motor resolvió.

Lo notable es el tamaño del ejemplo: 71 líneas de SwiftUI corren idénticas en un simulador de iPhone booteado y en un emulador Android. No es marketing: es una demostración de que la misma fuente única puede desplegarse en dos plataformas sin webviews ni renombrar widgets. iPad funciona igual, con otro descriptor de dispositivo: cambian viewport, safe areas y size classes, y los layouts adaptativos de SwiftUI hacen el resto.

Cómo se mantiene al día con cada iOS nuevo

El desarrollo del motor está altamente automatizado con una flota de agentes. Los agentes usan los artefactos del SDK de Apple para construir una referencia de la API. Después se renderizan escenas en un simulador iOS booteado, se capturan y se hace un diff píxel a píxel contra el output del motor. Cuando sale un iOS nuevo, se re-renderiza la fuente de verdad contra el simulador nuevo.

Los screenshots pierden todo lo que se mueve, así que un filmstrip runner maneja un reloj virtual: avanza el motor en pasos fijos, samplea frames en una línea de tiempo y dispara toques y teclas sintéticos en momentos exactos. Para juegos se diffan estados y eventos —la posición real de un personaje en el frame N— usando el mismo node schema por frame (posición, rotación, escala, alfa, velocidad física), y las trayectorias se diffan por nodo y por frame. Cada diff se entrega a un LLM visual que identifica issues y dispara agentes para editar el framework source hasta que el diff baja de un umbral.

Qué significa esto para tu startup

El movimiento de Dactyl se entiende mejor en contexto. Andrej Karpathy —quien acuñó el término vibe coding— declaró en febrero de 2026 que esa etapa ya quedó atrás y la llamó agentic engineering, según recogió Forbes. En la práctica, eso significa que la pregunta ya no es «qué tan rápido prototipa el LLM», sino qué tan cerca del código de producción llega. Herramientas como Cloudflare, que abrió el código de Cloudflare OS el 5 de agosto según Ars Technica, o Base44, que entrena su propio modelo Base1 con «tens of millions» de interacciones de usuarios, están empujando en la misma dirección.

Dactyl ataca el ángulo contrario al de la mayoría: en lugar de generar Expo o Flutter, apunta a SwiftUI nativo compilado a Wasm. Si tu producto necesita componentes nativos de Apple (Apple Pay, HealthKit, ARKit, widgets) o quieres evitar el look de webview, este enfoque cambia la ecuación. Tres acciones concretas para evaluarlo:

Mide tu coste real de «no-native». Audita qué tanto de tu churn o de tus tickets de soporte viene de usuarios que sienten la app «rara» en su dispositivo. Si el porcentaje es alto, una capa cross-platform genérica te está costando dinero cada mes.
Prototipa con descripción, no con código. Si tu equipo es pequeño, intenta describir la app en lenguaje natural y comparar el output de Dactyl con el de una plataforma basada en Expo o Flutter. La pregunta no es si compila, sino si el resultado se siente nativo.
Piensa en WebAssembly como target, no solo en la web. El lanzamiento de Kotlin 2.4.0 en junio, con compilación incremental habilitada por defecto en Kotlin/Wasm y soporte del WebAssembly Component Model, confirma que Wasm ya no es solo una tecnología de navegador: es un runtime portátil para plugins, edge y módulos polyglot. Entenderlo hoy te posiciona para los próximos tres años.

El panorama general: el vibe coding está dejando de ser «describe y espera lo que salga» para convertirse en ingeniería asistida por agentes que produce software desplegable. Dactyl es una de las primeras herramientas en llevar esa promesa al terreno nativo de Apple sin pedirte que renuncies a los widgets del sistema.