No Mac, No Xcode, No React Native!?
There's a specific kind of flattery in being named on a competitor's landing page.
Not linked.
Not reviewed.
Just held up as the thing to avoid….
That's the treatment React Native gets from Dactyl… which sounds like the name of Elon Musk’s next child.
But it’s a new AI app builder from the folks at Deno (the TypeScript-first runtime built by the people who made Node.js, to fix everything they regretted about it).
They say the App Store gets "a genuine native binary, not React Native or a webview", and the FAQ claims most AI app builders generate React Native inside a wrapper, make you preview through an app you install, and resell AI tokens at a markup.
An entire framework, dissed in an FAQ….
Burn.
With Dactyl, you describe an app in plain English, and an agent writes real SwiftUI (Apple's declarative UI framework) you can read, edit, and export as an Xcode project.
Then comes the party trick.
A live iPhone appears on the web page, running your app while the agent builds it.
Not a video stream from a rented Mac in a data centre.
Not a cloud simulator you queue for.
The docs insist the iPhone in your browser is the real app running, rendering genuine SwiftUI pixel-for-pixel, and you can tap it, type in it, and scroll it as it rebuilds on every change.
So how does real Swift run inside a browser tab?
Ryan Dahl answered that one himself.
Yes, that Ryan Dahl, the creator of Node.js and cofounder of Deno.
His launch thread says they built a SwiftUI renderer in WebAssembly (a binary format that lets compiled languages like C, Rust, and Swift run in the browser at near-native speed, Wasm for short), drawing a low-latency simulation of the app to a browser canvas, with OAuth flows and even the camera running through browser APIs while you build.
A SwiftUI renderer…
In Wasm (short for WebAssembly).
The pricing model is the other jab at the competition.
The Builder plan is $20/mo, the AI runs on the ChatGPT subscription you already pay for, so nobody resells you tokens, and failed builds cost nothing.
Oh, and it does Android.
So how does SwiftUI run on Android with native components?
Dactyl doesn't say.
The established way to pull this off is Skip, the open-source toolchain that compiles Swift and SwiftUI into native Jetpack Compose for Android.
Whether Dactyl runs on Skip or something home-grown, nobody has said.
Dactyl isn't aimed at us.
It's aimed at everyone who was going to become us.
The 1920s automobile wasn't aimed at the horse either.
It was aimed at people shopping for one.
The horse is still around a century later, mind you.
Mostly at weddings.
👉 Dactyl
Win a Year of Unlimited CI/CD Build Minutes ($3,990 Value)
For years, CodePush was how React Native shipped OTA updates.
Then Microsoft retired App Centre in March 2025, and CodePush went read-only with it.
The Codemagic team ran a fork for 18 months. Then they rewrote the whole thing.
Codemagic Patch is what CodePush should have been:
➡️ CDN-first delivery
➡️ Binary diffs
➡️ Native fingerprinting
➡️ An actual dashboard (Did you say Dashboard!?)
➡️ Easy to self-host, source on GitHub
Patch comes from Codemagic, the CI/CD platform built for mobile teams.
And to celebrate the launch, they're giving away a year of unlimited builds on M2 Macs (their Annual plan, worth $3,990).
To enter, just join the Codemagic Discord. The team is in there and happy to walk you through it, answer questions, and help you figure out if it fits your setup.
👉 Join the Discord before September 14th.
Winner drawn September 15th.
Not That Kind of Enrichment
"Enriched" is a word that usually earns you a visit from the IAEA (the nuclear watchdog, not a Markdown linter).
In React Native, it now earns you native Markdown instead.
Enriched Markdown is the newest stable member of Software Mansion's Enriched family of rare earth elements, next to enriched-html and enriched-streamdown.
The party mansion now has a whole wing for rich text.
It's maintained by Gregory Moskaliuk (@hryhoriiK97) and a few dozen contributors.
It does two jobs.
An EnrichedMarkdownText component renders Markdown as native text:
import { EnrichedMarkdownText, } from 'react-native-enriched-markdown'; <EnrichedMarkdownText markdown={'This is **enriched** *markdown*.'} onLinkPress={({ url }) => Linking.openURL(url)} />
And an EnrichedMarkdownTextInput lets users type rich text and returns Markdown:
import { EnrichedMarkdownTextInput, } from 'react-native-enriched-markdown'; <EnrichedMarkdownTextInput placeholder="Type here..." onChangeMarkdown={(md) => save(md)} />
But the interesting part is what it refuses to do.
The usual React Native approach to Markdown is a JavaScript parser that explodes your string into a tree of nested Text and View components, which React reconciles, and Yoga (React Native's layout engine) lays out, per message, per token if you're streaming.
Enriched Markdown skips the tree entirely.
The native side parses the Markdown (via md4c, a C parser, on iOS) and draws the whole block as one native text view, an attributed string on iOS, a Spannable on Android.
One component.
One native view.
No JavaScript re-render per token.
Why build it this way?
Watch what happens when an AI types the word "bold" at you.
stream so far what renders "This is **bo" → This is **bo "This is **bold**" → This is **bold**
For a moment, your users see raw asterisks.
Then the closing marks arrive, and the text snaps into bold.
Now multiply that snap by every bold, link, list, and table row in the reply, and remember each repaint is a full re-parse and a rebuilt component tree in JavaScript.
That's the flicker you've seen in every AI chat app that was built in a weekend.
Enriched Markdown attacks the expensive part of that loop.
The drawing…
Each new token fades in where the message ends, without repainting a single word that's already on screen.
It just renders whatever Markdown you hand it, fast, which makes it the perfect base for something that fixes the string before it arrives.
That something has a name.
react-native-streamdown sits on top and fixes the Markdown before it ever renders.
When the stream reads "This is **bo", a repair library called remend closes the dangling syntax on the fly, so your users see bold text from the very first token instead of asterisks.
So yes, enrichment is finally legal.
As long as you keep it to Markdown.
👉 React Native Enriched Markdown
Everyone's Compiling React in Rust but Us
For most of its life, the React Compiler has been a Babel plugin.
The React Compiler is a build-time step that automatically memorises your components and hooks, so you stop hand-writing useMemo, useCallback, and React.memo.
And it has only ever shipped as a Babel plugin.
A JavaScript program that rewrites every file of your app during bundling, at single-threaded JavaScript speed.
That era is ending.
Fast.
Everywhere except the one bundler we all use…
Earlier this year, the React team open-sourced a Rust port of the React Compiler.
The reason is unglamorous.
The tools that would run the compiler stopped being written in JavaScript, so the compiler couldn't stay JavaScript either.
And the Rust half of the ecosystem grabbed it instantly.
Oxc, a project rebuilding standard JavaScript tooling in Rust, was the first to ship support for it.
Compiling a React component through the Babel plugin takes roughly 100ms.
And adoption across the web happened almost overnight.
Oxlint shipped 22 lint rules powered directly by the React Compiler's internal validation engine.
Vite added official React Compiler support with a single plugin flag.
Biome added a dedicated useReactCompiler lint rule to catch code that breaks compiler rules.
Bun built a native --react-compiler flag right into its bundler.
And SWC and Turbopack wired the Rust compiler directly into their core build pipelines.
Now, the part that concerns us.
Look at the list of tools running the new Rust compiler.
Oxlint, Biome, Bun, Vite, SWC, Turbopack.
Notice anyone missing?
Where the fuck is Metro?
React Native still runs the compiler through Metro's Babel transformer.
That means none of those 10x speedups applies to us.
We're still compiling React components at single-threaded JavaScript speed.
While the web spends 2026 deleting Babel from its pipelines…
To be fair, there is an answer of sorts.
Expo's Why Metro doc defends the status quo.
Rust cores make contributions and patches harder, and Metro's AST transformation is intentionally Babel.
Which is a philosophy.
Philosophies don't make your build pipeline 10x faster.
Somewhere, the Dactyl FAQ writers just felt a new bullet point forming.
