THE POST-RELEASE OPERATING LAYER FOR FLUTTER · Patented architecture
Flutter’s release window era is ending. We built what comes next.
Ejenix is the post-release operating layer for Flutter — engine-level, reviewer-safe by design, hardware-validated on real arm64, and patent-protected. Fifteen years of waiting on Apple's and Google's queues just ended.
A plain answer to the question every CTO asks in the first five seconds — before the demo, before the proof, before the patent talk.
The post-release operating layer for Flutter.
Ejenix ships Dart code, flags, config, UI, and assets to production Flutter apps — without store re-submission. Hardware-verified compliance gate. Cryptographic audit chain. Engineered from inside the engine, not bolted on top.
Other tools live in user-space. Ejenix lives inside the runtime — which is what lets us ship genuinely new behavior, not just modify what’s there. That difference is the patented moat.
What you can do by Friday.
Six concrete jobs that used to take a release cycle. With Ejenix, every one of them happens in your normal workday.
Ship the fix this afternoon.
A user-facing Dart bug ships through Ejenix in minutes — not the 5–14 days a store re-submission costs. Signed, cohorted, observable, reversible.
Add behavior that didn’t exist at build time.
Other code-push tools can only modify code that was compiled in. Ejenix ships genuinely new code into the running app. For example:
- Ship a new method for a payment provider that didn’t exist when you built the app.
- Add a new product card from server-driven UI — storefront updates without a build.
- Push a new onboarding screen for a single market overnight.
Others can modify. Only Ejenix can add. Patent-protected.
Cohort-paced rollouts.
1% → 5% → 25% → 50% → 100%, gated on crash-free and latency. Region, app version, device class, custom tags — compose them.
Code, layouts, config, assets. One platform.
Patches between releases. Multi-mode dispatch.
Push layouts to live screens. Reviewer-safe.
Toggle behaviour without a deploy. Typed, cohort-aware.
Images, fonts, JSON. Versioned, signed, delta-shipped.
All four push through the same console — one audit chain, one bill.
< 90 seconds. Contractual.
Boot-loop guard, last-known-good cache, hardware-enforced budget. Continuous validation proves it. The rollback is atomic — the audit chain records every byte.
Cryptographic chain. Verifiable without us.
Every operation is hash-chained and Ed25519-signed at the source. Your auditor verifies the chain locally, with an open-source tool. SOC 2 evidence in minutes, not weeks.
Engine-level integration — so patches can do things off-the-shelf approaches physically can't.
That’s not a metaphor. The architecture extends from the build pipeline into the runtime itself. The rest of the category can only modify what’s already there. Here, patches can also add new capability. That single difference is the moat — and patented at the core.
Architecture details available under technical NDA · Patent documentation available under NDA.
One command. Then it’s live in seconds.
A developer edits a file, runs ejenix push, and the patch lands in the running production app — no store review, no waiting.
Showing capability 01: DART CODE
One command. Four shipping surfaces. Engine-level dispatch. Open on a larger screen to see the live workspace.
Every other tool runs an interpreter or swaps the bundle. Ejenix is the layer above both.
For fifteen years, mobile teams had two choices: resubmit to the store, or run a slow interpreter. We built a third — multi-mode patch dispatch, engine-level, patent-protected. The category isn’t behind by a feature. It’s behind by an architecture.
Ship features. Not just bug fixes.
Other tools can only swap or modify code that was already compiled in. Ejenix ships genuinely new code into a running app — new functions, new methods. No rebuild. No store resubmission. Patent-protected.
Four internal modes for Dart code. Picked automatically.
Single-path code-push tools are either slow (interpreted) or limited (text-only). Ejenix runs four internal dispatch modes for Dart code, classified and routed automatically by the shape of the change:
- MODE 1 · Literal change — a constant, a string, a number. The fastest path.
- MODE 2 · Function-body change — replace the body of an existing function.
- MODE 3 · Add a new function into the running app. First system in the category to do this.
- MODE 4 · Structural change — code-shape rewrites the lighter modes can’t carry.
The patent covers the orchestration — the architecture that classifies a code change, picks the right mode, and dispatches. Not the four shipping surfaces. Not the individual paths. Competitors can build one mode; not the system that picks between four.
< 90-second rollback. Contractual.
We roll back at the device — boot-loop guard, last-known-good cache, hardware-enforced budget every patch must beat. Install / materialize / verify / revert, hardware-validated end to end. Operational discipline competitors don't claim.
Cryptographic audit. Verifiable without us.
Every operation hash-chained and Ed25519-signed at the source. Your auditor verifies the chain locally with an open-source tool. No vendor trust, no proprietary attestation. SOC 2 evidence in minutes.
App Store + Play. Engineered, not hoped.
Every patch produces a packet reviewers read, not guess. The compliance gate refuses native code, new permissions, unsafe dynamic loading. Compliance-by-construction. Hardware-validated on real devices.
A multi-year head start. Patent-protected.
Competitors can polish UI, drop price, hire louder marketers — none of that changes the layer they operate at. To reach where Ejenix operates, a rival has to rebuild from the engine layer up. By the time they finish, the patent will have issued. Not a feature gap. A category gap.
Architecture details and patent documentation available to qualified reviewers under NDA. · Reviewer packet ↗
Things that used to take a release.
Now take a coffee break.
Each line below is real — measured from live customer fleets in the last 30 days. The implication should not be subtle: most of what your store-review queue holds, no longer needs to be there.
None of these require a rebuild. None require a store resubmission. All of them are reviewer-verifiable.
Pick three: speed, control, proof. Or pick the architecture that wins all four.
Most workflows force a trade. The traditional release gives you proof but no speed. The ordinary hot-update gives you speed but no proof. Neither reaches the engine. We do. The rows in violet below mark capabilities the rest of the category is architecturally blocked from delivering — not features they haven’t built yet.
| Traditional release | Ordinary hot-update | Ejenix | |
|---|---|---|---|
| Time to ship a Dart change | 5–14 days | hours | seconds to minutes |
| Ships server-driven UI between releases | ● no | ● rare | ○ first-class |
| Ships feature flags & remote config | ● no | ● separate vendor | ○ built-in |
| Ships asset / bundle delivery | ◐ via release only | ◐ partial | ○ first-class |
| Requires rebuild & resubmission | ● always | ◐ sometimes | ○ not for eligible changes |
| Progressive rollout (1% → 100%) | ◐ store-gated | ◐ partial | ○ first-class |
| Rollback under 2 minutes | ● no | ◐ sometimes | ○ always |
| Cohort / region / device targeting | ● coarse | ◐ limited | ○ precise, composable |
| Fit for regulated teams | ◐ by inertia | ● rarely | ○ by design |
| Engine-layer integration | ● n/a | ● architecturally blocked | ○ the entire architecture |
| Patches that add new functions / methods | ◐ via release only | ● can only modify existing | ○ proven on real hardware |
| Cold-start parity (contractual ±0%) | ○ baseline | ● latency added every launch | ○ contractual · gated in CI |
| Locally verifiable audit (no vendor trust) | ● no | ● trust-our-cloud | ○ open-source verifier |
| Hardware-validated proof packet | ● no | ● no | ○ Hardware-validated · Continuous lifecycle validation |
| Tamper-evident audit trail | ● no | ● no | ○ append-only · signed · per-op |
○ available · ◐ partial · ● not supported · Comparison reflects observed public capability of common workflows, not specific vendors.
The questions we get before the contract.
Asked candidly. Answered candidly. The final question, deliberately, is not answered in public.
Q · 01 “This sounds like it bypasses the store review.”
No. We ship only changes store policy explicitly permits without resubmission; everything else goes through normal release. The gating policy is published to platform reviewers on request.
Q · 02 “What does my security team get to read?”
A private reviewer packet: trust posture, signed audit format, key custody, data residency, gating policy. Enough to pass a hard security review without leaking the engine.
Q · 03 “What happens to startup time and binary size?”
Cold-start parity is contractual. Binary overhead is a small constant. Degraded performance is a failure mode, not a trade-off.
Q · 04 “How does the auditor verify a patch?”
Each operation is signed and sequenced into an append-only record. Your auditor downloads the range, runs the open-source verifier on their laptop, re-derives every decision locally. No trust required — the record itself is the proof.
Q · 05 “What if I want to self-host?”
Available on Team and Enterprise. The control plane runs in your environment; the gating policy and signed-audit format are unchanged. Reviewer experience is identical to managed.
Q · 06 “…how does the engine actually work?”
Not published. We brief your CTO, security team, and platform reviewer under NDA. The product is the moat — the documentation is for customers, not competitors.
Request the briefing →After this, the old way looks obsolete.
Five days to ship a one-line fix isn't an engineering culture. It's a tax. Pay it once more, or don't.