Flutter today. React Native next.
Ejenix was engineered for Flutter first — not because Flutter is the only runtime that deserves a post-release operating layer, but because Flutter is the runtime where an engine-level architecture could be patented, hardened, and proven on real silicon before being generalised. The same posture is now being applied, deliberately and slowly, to React Native.
Different runtimes. Same standard.
A code-push tool that is rigorous on one runtime and casual on another teaches enterprises a confusing lesson — that the rigour was incidental to the runtime, not intrinsic to the company. We refuse that lesson.
Flutter.
iOS arm64 · iOS arm64e · Android arm64 · Android arm32. The runtime where the architecture was proven.
- ● Engine-level integration
- ● Four-mode dispatch · patented
- ● Deterministic audit chain
- ● Hardware-validated on real silicon
- ● Reviewer packet, locally verifiable
React Native.
The second runtime where post-release operating support can be done well — if it’s done at the same standard. Active engineering.
- ○ Runtime integration — in progress
- ○ Multi-mode dispatch — design phase
- ○ Audit chain — shared with Flutter
- ○ Hardware validation — pending
- ○ Reviewer packet — shared with Flutter
We are not interested in being the eleventh code-push provider for a runtime. We are interested in being the first one that ships an architecture other code-push tools cannot replicate — once per runtime that justifies the engineering.
— The Ejenix engineering office
Four capabilities. All proven on real hardware.
Every claim on this page is something we proved on real iPhone and real Android arm64 silicon before any customer saw a demo. The four capabilities below are the ones the rest of the category cannot match, because matching them requires what Flutter required: engine work.
Fused into the runtime. No overlay.
Every patch dispatches through the same execution path as your original AOT code. There is no interpreter overlay, no JavaScript bridge, no whole-bundle swap.
Four execution modes. Picked automatically.
Field-level diffs, structural rewrites, content updates, and live-tested previews each travel through the mode they belong in. The dispatcher is the patent.
Verifiable. By anyone. Without us.
Every dispatched patch produces a witness. Every witness is independently verifiable by an open-source CLI. Your auditor doesn’t need to trust our database.
Real silicon. Continuous lifecycle.
Not simulators, not emulators. The Flutter build is gated on real arm64 hardware on every release — install, materialize, verify, revert, all signed.
React Native is the second runtime. It will not ship until it is ready.
The JavaScript runtime in React Native is genuinely different from Dart’s AOT pipeline. The right answer is not to clone the Flutter implementation — the right answer is to apply the same posture: engine-level where engine-level is the right layer, multi-mode where multi-mode is the right contract, audit-chained always.
Work is active. We are not announcing dates. When the React Native runtime crosses the same bar Flutter crossed — reviewer packet, deterministic verifier, hardware-validated lifecycle — it ships. Not before.
Same architecture, different code.
The SDK we ship for React Native will respect that React Native is not Flutter. The posture is identical. The implementation is not.
Shared audit chain. One reviewer packet.
Your compliance team learns one workflow, not two. The disclosure shape that clears your review for Flutter clears for React Native too.
No date. No compromise.
We will not announce a ship date for React Native that we are not sure we can hold to the same standard Flutter holds. Honest gap over false confidence.
The Flutter version of Ejenix is the first system to ship genuinely new code into a running production app at the engine layer. The React Native version will be the first one that does it without sacrificing that posture.
The roadmap we publish in private. Now public.
Every cross-platform mobile vendor has a slide that says “everything, soon.” Ours says the opposite. Here is what we are deliberately not shipping, with the reason on the record.
There is no AOT to patch.
Flutter web compiles to a JavaScript bundle. The premise of Ejenix — engine-level dispatch into a running native runtime — does not apply. Code-push for a JS bundle is a CDN problem, not an engine problem. We are not the right vendor for a CDN problem.
Desktop apps update through the OS.
macOS, Windows, and Linux already have first-class update channels — Sparkle, MSIX, deb/rpm, the App Store. The release-window problem we exist to solve is a mobile-store problem. On desktop it does not exist in the same form.
Different bet, different problem.
These runtimes are either too early to need a post-release operating layer at our standard (KMP) or are themselves a thin wrapper over a web view (Capacitor, Tauri) where the patching problem is again a web problem. We will revisit each one when the answer changes. It has not changed yet.
One-SDK-for-everything is a marketing line.
Flutter and React Native are different runtimes. The Ejenix SDK for each will respect that. Same posture, same audit chain — different code, on purpose.
If your stack is React Native, we want to hear from you now.
We are taking a small number of React Native design partners during the engineering phase. The goal is not to demo something half-built — it is to make sure the SDK we ship lands on your real stack, your real CI, and your real compliance posture.