The category patches around the engine.
We rebuilt the engine itself.
Every other approach in the category lives in user-space, layered on top of Flutter. Ejenix lives inside the engine. That single architectural choice creates four moats the rest of the category cannot cross without doing what we did — and getting it through Apple and Google as we did. The lead is structural, not seasonal. The core architecture is patented.
A 4-layer architecture. Each layer engineered independently. Each layer verifiable independently.
Most code-push tools are a single black box: upload your patch, hope it lands. Ejenix is a 4-layer architecture where each layer is engineered, gated, and verified separately — from the build pipeline through the device runtime through the audit chain. You don’t have to trust us. You can verify each layer yourself.
Every change classified before it ships. The mode is picked for you.
Your engineer runs the patch command on a normal Dart commit. In seconds, the tool delivers what no other Flutter code-push platform can:
Not source-level — deeper. The tool knows precisely what needs to move and why.
A one-line fix doesn’t need what a structural rewrite needs. The system reads your change, picks the path that suits it, and ships it through that path — without you choosing. The patent covers this orchestration, not any single path.
Ten categories of forbidden change blocked at the build pipeline. The gate is non-negotiable.
Your signing key never leaves your environment. Every patch carries a plain-text packet your auditor — or Apple — can read.
A Dart code change is classified by shape and routed through one of four runtime paths — automatically. The patent covers the orchestration that picks. Not any single path.
A constant, a string, a number. The fastest path.
Replace the body of an existing function.
First system in the category to do this.
Code-shape rewrites the lighter modes can't carry.
Every other Flutter code-push tool treats patches as opaque blobs to swap. We work at a deeper layer with a classifier and a mode picker. That single architectural decision is what makes everything downstream possible.
Cohort-aware delivery. 1% → 5% → 25% → 50% → 100%, gated.
The signed patch lands in the control plane. Tracks (stable / beta / canary), segments (region / app version / device class), and approval gates decide who receives it. Devices authenticate via SDK key, fetch from regional CDN, and pull only the chunks they don’t already have. This layer is where rollout discipline lives.
The patch is materialized inside the Flutter engine. This is the engine-layer integration competitors cannot match.
The device verifies the signature, materializes the patch into the running app via the mode the build tool picked, and runs the boot-loop guard. If the patched app fails three boots in a row, it reverts locally to last-known-good without waiting for the cloud. This is the layer where every other code-push tool is architecturally blocked.
Every operation is signed at the source. The chain is the proof.
Authored, signed, rolled out, approved, reverted — every event is hash-chained, Ed25519-signed at the point of origin, and verifiable locally by your auditor with an open-source tool. No vendor trust required. We could disappear tomorrow and your audit trail would still verify.
Each layer is documented in the reviewer packet. Mechanism details under technical NDA. · See the reviewer packet ↗
Patches that pass platform review by design. Not by exception.
Most OTA approaches survive platform review by exploiting gray areas in the policy. That works — until policy tightens. Then the entire fleet stops shipping, sometimes overnight. The category has lived through this cycle twice in five years.
Ejenix doesn’t operate in gray. The architecture begins from the policy itself: a strict gate that refuses any patch the platform would refuse. Ten capabilities are forbidden by design — listed openly in every reviewer packet, refused at build time, never silently degraded.
When policy tightens, we don’t scramble. The gate already enforced it. That isn’t a compliance team’s memo. It’s a wire format.
When the rules change. We’re already there.
Apple has enforced App Store Review Guidelines 3.3.2 + 4.7 against dynamic-code SDKs for over a decade. Mass enforcement hit category-wide in April 2017 — every Objective-C runtime hot-patcher and JavaScript interpreter overlay lost coverage at the same time. The guideline language tightened again in June 2021. The EU Digital Markets Act (in force March 2024) and India's DPDP Act (operative 2025) added a regulatory layer above platform policy. Every 2–3 years, the rules tighten — and every vendor in this category moves at once, because they all sit on the same architectural foundation. Your customers should ask: what happens to my app the next time it tightens?
Three techniques. One Apple guideline.
Every dynamic-code SDK in the category uses one of these three patterns. They’re not secret — they’re well-documented industry techniques. All three sit under the same App Store guideline. Competitors don’t describe them to you because if they did, the policy exposure would be obvious.
Bundled interpreter overlay.
How it works: a JavaScript or bytecode interpreter ships inside the app at build time. New code is downloaded post-install and run through that interpreter at runtime.
“Executable code, scripts, or other dynamic content” downloaded after install is the exact case the guideline forbids.
Every patched function pays interpreter cost on every call. The interpreter itself is identifiable in the binary at review.
Whole-bundle / asset swap.
How it works: the entire JS or Dart bundle is replaced over-the-air, or specific “asset” files containing application logic are swapped. Marketed as “content updates.”
If the “asset” contains executable behaviour, the guideline classifies it as code — regardless of the file extension or framing.
The asset-vs-behaviour line is what reviewers tighten. When framing fails, the entire SDK loses coverage at once.
Runtime method swizzling.
How it works: platform runtime APIs (Objective-C method swizzling, Java reflection) swap method implementations at runtime, driven by a script the app downloads.
Dynamic substitution of executable behaviour is the central forbidden case — the canonical example the guideline was written against.
April 2017 enforcement targeted this technique directly. The category effectively died.
No bundled interpreter. No bundle-swap framing. No runtime method swizzling. Engine-level integration is a different category entirely — with a reviewer-disclosed compliance gate that refuses what 3.3.2 forbids before it ever leaves the build pipeline.
When policy tightens, the fleet stops shipping.
When policy tightens, nothing changes.
Every entry is a matter of public record. The category-wide exposure is structural, not bad luck. Every vendor on grey-area foundations meets the next one at the same time.
We don’t live in the grey area. We live above it.
Other platforms ask their customers to bet on Apple looking the other way. We ask Apple to verify our claims directly — with a reviewer packet, an open-source verifier, and hardware-validated proof on real devices. When the rules change, the customers who chose Ejenix don’t need a war room. They need to keep shipping.
Cold-start identical. Every patch. Every time.
Code-push approaches that route everything through a generic interpreter pay a hidden tax: a few extra milliseconds of boot latency on every launch, for every patched user, forever. At one patch the cost is invisible. At ten patches it shows up in Core Web Vitals-style metrics. At fifty patches it is a perceptible delay on cold-start that compounds across your entire fleet.
Multiply that cost by 38 million devices and you are paying for a slow product every single morning your users open the app. Procurement teams at regulated companies notice this in their performance audits. App Store reviewers notice it when comparing release builds. Your retention dashboard notices it weeks later, as fractional ms losses turn into measurable churn.
Ejenix doesn’t pay that tax. Because we live inside the engine, a patched function runs at the same speed as the original — byte-identical latency to the base build. The mode picker (Layer 1) ensures interpretation is only used when it’s a net win, and only for the function that actually needs it — never for the whole app. The cases that genuinely require interpretation are bounded, classified, and disclosed in the reviewer packet up front. Nothing hidden, nothing accumulated.
Cold-start parity is contractual. Gated in CI. Measured per release on real iPhone hardware today, with Android parity finalizing this week. The rest of the category’s typical answer here is “mostly fast” or “within 10%.” Our answer is parity, measurable, signed into the audit chain. Not a slogan — a property.
Reviewer-verifiable. Locally.
Most audit stories end at "trust our cloud." Some end at "trust our database." Neither survives the regulator who asks for proof the vendor cannot tamper with the record after the fact.
The Ejenix audit chain is a signed, sequenced, append-only record. Your auditor verifies it with an open-source verifier — on their laptop — without trusting us, our cloud, or our database. The record itself is the proof. We could disappear tomorrow and your audit trail would still verify.
Audit ships in every tier. Including the free one. Audit is a product property, not a paywall.
Proven where it actually runs. On the device.
Most “production-ready” claims in this category rest on tests that ran in a CI container. A real device is a different animal — different memory pressure, different OS, different chip, different filesystem, different thermal envelope, different threading model.
Ejenix is gated against real arm64 hardware on every release. A production-grade patch-family matrix. Continuous install / materialize / rollback lifecycle. Hardware-validated end to end. Including the fail-closed reject paths the category usually pretends don’t exist.
The hardware test record ships in the reviewer packet, signed. The category does not have a precedent for this kind of disclosure.
What works where.
Honest disclosure of where each capability is hardware-validated, where it’s in active validation, and what’s outside scope by design. The category does not publish anything like this.
● Hardware-validated · ○ In active design · Engine-level integration required for both Flutter and React Native targets
Four moats. One architecture. Patented. A category being redefined.
The lead isn’t in features. The lead is in the layer we operate at, the regulatory path we’ve already cleared, and the patents we hold. The rest of the category can copy a feature in a quarter. They cannot copy this architecture in a year — and if they tried, they would meet our patents.