Dactyl turns a sentence into a real native app, no Xcode needed. Check this before you trust it with real users. A team from Deno launched Dactyl, an AI builder that writes real native iOS and Android apps in your browser. Here's what to verify first. BuilderWithin Editorial Team BuilderWithin Most AI app builders that promise a native mobile app actually hand you something else. Often that's a mobile website dressed up to look like an app, what's called a web view. Sometimes it's a React Native project, a common way to write one code base meant to work on both iPhone and Android, that still behaves differently from a real native build. Dactyl, a new tool from a team of engineers at Deno, the JavaScript runtime company, is trying a different approach: describe an app, and it writes real, native SwiftUI (Apple's own framework for building iOS interfaces) code you can preview instantly in your browser. Bert Belder, a Deno co-founder, confirmed on X that the project comes from a small group at Deno, built around a SwiftUI renderer running in WASM (a format that lets code originally written for one platform run inside a web browser at near-native speed). That's what powers Dactyl's in-browser simulator: you can tap through a real, working version of your app the moment it's built, without installing Xcode, a simulator app, or owning a Mac at all. What it actually builds. According to Dactyl's own site, the agent writes real SwiftUI you can read, edit, and export as an Xcode project (Apple's official app development toolkit) at any point, with no lock-in to the platform. The same Swift code compiles into a native Android APK as well, the installable file format Android apps normally ship in, which Dactyl says means no rewrite and no web view for the Android version either. Beyond the interface, Dactyl says it wires up working infrastructure by default: real Sign in with Apple and Google, camera and GPS access, and StoreKit (Apple's in-app purchase system) for real payments, all functioning in the browser preview before you ever install the app on a device. Getting an app onto your own phone just takes scanning a QR code, no Apple Developer account required. Publishing to the App Store or TestFlight does require that $99-a-year Apple Developer account, which Dactyl says it walks you through from inside the editor. Play Store publishing isn't available yet; Dactyl's FAQ lists it as coming later. The pricing model is the more interesting part. Dactyl's Builder plan costs $20 a month, and it's designed to run on a ChatGPT subscription you already pay for rather than reselling you tokens at a markup. Connect your own ChatGPT plan and the AI work runs on your existing allowance; Dactyl says failed builds don't cost you anything. A free tier exists too, running on Dactyl's own included credits instead. That bring-your-own-subscription model is worth noting on its own, separate from any specific price comparison. It ties what you can build to the usage limits of whatever ChatGPT plan you already have, rather than a separate credit system layered on top. If OpenAI changes what a Plus or Pro plan includes, as it's doing again this week with Codex's usage caps, that also changes how far your Dactyl budget goes, even though the two products aren't related. What to check before you rely on it. Dactyl is a new product from a small team, not an app-builder platform with years of production traffic behind it. That matters because of what it's plugging in by default: real user authentication, real payment processing, and real device data like location and camera access. Before you point Dactyl at actual users or real payments, read its privacy and data-handling terms directly. Confirm where user data from Sign in with Apple or Google actually gets stored, and whether that meets whatever privacy commitments you're making to your own users. A tool that wires up real auth and payments this easily is also a tool where a misconfigured default could expose more than you intended, and there's no public track record yet to lean on. What builders should do next. Don't take the pricing page's numbers as your numbers. Build one small but real feature end to end, entirely inside the free tier: a login screen using Sign in with Apple plus one saved user record. Track two things while you do it: how many corrections you have to make to get the auth flow actually working, and how much of the free credit allowance that single feature consumes before you'd need to pay. That tells you whether the $20 Builder plan, on top of a ChatGPT subscription you already have, is worth it for your specific project, instead of relying on Dactyl's own comparison to other native app builders. Where this fits. Dactyl is one more entry in a pattern worth watching rather than a single product worth ranking: AI app builders are increasingly competing on how close their output gets to real, exportable native code instead of a wrapped web view, and on whether they resell AI usage or let you bring your own subscription. Both choices affect what you can actually ship and what happens to your project if the tool disappears. Judge any builder, this one included, by what you can walk away with, not by what the demo shows. End of article BuilderWithin Weekly · Free If you found this useful, subscribe free. Get BuilderWithin Weekly in your inbox. Daily briefings publish on the site, and the weekly roundup pulls together what mattered. Unsubscribe any time. BuilderWithin Weekly · Free · No spam Get BuilderWithin Weekly in your inbox. One weekly roundup in your inbox. Daily briefings publish on the site for people who ship products. Unsubscribe any time · Weekly email, always free

Deno 2.9 launches lightweight desktop apps. deno desktop turns Deno or Next.js projects into self-contained binaries with OS webview or CEF, full Node compat and smaller size. Deno desktop in version 2.9. Deno released desktop app support in v2.9.0. The command converts any Deno project, from a single TypeScript file to a full Next.js application, into a self-contained binary. The binary includes the Deno runtime and a web rendering engine. The feature currently requires the canary build and remains subject to API changes before stable release. It targets smaller output sizes than Electron while preserving Node compatibility through Deno's existing layer. Core architecture choices. deno desktop defaults to the operating system's native WebView. This keeps binary size low because it avoids shipping a full browser engine. Developers can switch to the Chromium Embedded Framework backend for pixel-identical rendering across macOS, Windows, and Linux when needed. Communication between Deno code and the webview occurs through in-process channels rather than socket IPC. Values still cross a serialization boundary, yet the absence of process round-trips reduces latency for frequent calls. The same machine can cross-compile to all three desktop platforms; required backends download automatically. Built-in updates rely on a single latest.json manifest and bsdiff patches. The runtime checks the manifest, applies patches, and reverts automatically if a launch fails after the update. Framework support and usage. Pointing the command at a recognized project triggers automatic detection. Supported frameworks include Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, and any Vite SSR setup. In release mode the production server runs inside the binary. With the -hmr flag the dev server starts with hot reload enabled. No source changes are required. A minimal example uses Deno.serve: Deno.serve => new response(" Hello ", {headers: { "content-type": "text/html"},})); Running deno desktop main.ts produces an executable that opens a window pointed at the local handler. The serve call binds to the address the webview expects, so no explicit port configuration is needed. Practical trade-offs. The OS WebView path delivers the smallest binaries but inherits platform rendering differences. The CEF option removes those differences at the cost of larger downloads. In-process bindings improve speed yet still require value encoding, which matters for large payloads. Auto-update works only when the manifest and patches are hosted; the mechanism provides rollback but no custom distribution logic. Cross-compilation removes the need for multiple build machines, yet developers must still test on each target platform because native WebView behavior varies. Node compatibility covers most npm packages, though edge cases that rely on native addons may still require verification. Frequently asked questions. Does deno desktop require code changes for existing web apps? No. The command detects supported frameworks and runs either the production or development server without modification. How large are the resulting binaries? Default builds stay small by using the system WebView. Switching to the CEF backend increases size to achieve consistent rendering. Can the same source build for all three desktop platforms? Yes. One machine downloads the necessary backends and produces macOS, Windows, and Linux executables. Need a consultation? I help companies and startups build software, automate workflows, and integrate AI. Let's talk. #deno #desktop-apps #typescript #cross-platform