Engineering
Deploy
Over-the-air code delivery for React Native and Flutter apps — ship fixes to already-installed apps without an App Store / Play Store resubmit. App Store + Play compliant, with staged rollout and Catch-driven auto-rollback.
Sankofa Deploy ships code updates to your already-installed React Native and Flutter apps over-the-air — no new App Store / Play Store binary, no review wait. Push a fix, control who gets it, and roll it back automatically if it misbehaves.
Deploy is store-compliant on both iOS and Android: a patch updates the code layer of an app you already submitted for review, running inside the platform's interpreter — never downloaded machine code. What ships in a patch, and how it's produced, depends on your framework.
Platforms
| Framework | SDK | What ships in a patch | Deep-dive |
|---|---|---|---|
| React Native | sankofa-react-native | A JavaScript bundle | React Native SDK |
| Flutter | sankofa_flutter | Real Dart code, auto-diffed from your source — no hand-written patch file | Getting started |
- React Native delivers a JavaScript bundle built from your app. The RN SDK exposes the Deploy surface (
SankofaDeploy); the React Native SDK docs cover the bundle workflow end to end. - Flutter uses Dart code-push: you edit your ordinary
lib/*.dartsource, run one command, and Sankofa auto-diffs the rebuild against a base snapshot and ships only the changed functions. There's no separate patch file to author — see Getting started.
Releases vs. patches
Deploy has two units of delivery, the same shape on both frameworks:
| Base release | Patch | |
|---|---|---|
| What it is | The full native binary you submit to the store | A code-only update against a base release |
| Store review | Yes — normal App Store / Play submission | No — delivered over-the-air |
| Contains | Native runtime + your compiled app + assets | Only the changed code (a JS bundle on RN; the changed Dart on Flutter) |
| Bound to | A store version + build number | One base release (same version + build number) |
| Frequency | Once per store version | As often as you need |
A patch always targets the exact version + build number of the base release it was built against. Ship a new store version and you start a new base. Platform specifics live in the sub-pages — see Getting started and Releasing to the App Store for Flutter, and the React Native SDK docs for RN.
Staged rollout
Every patch carries a rollout percentage — the share of eligible devices that receive it. Ship to 5%, then 25%, then 100%; bucketing is deterministic per device, so a device that's in at 25% stays in as you ramp — you never re-shuffle who's exposed. Patches can be optional (applied on the next natural restart) or mandatory (applied before the user continues). See Rollouts & safety for the full lifecycle.
Auto-rollback safety net
A bad patch shouldn't take your app down. Deploy has two independent guards:
- On-device boot-crash rollback. If a freshly-applied patch crash-loops on launch, the device restores the last known-good version on its own — no server round-trip, no host code, works offline. The bad patch is quarantined locally so it isn't re-downloaded.
- Catch-driven halt. Wire Catch to Deploy and a spike in errors on a bonded release pauses the rollout for everyone; affected devices revert on their next check. See Rollouts & safety.
Where to go next
SDK
React Native
The sankofa-react-native Deploy surface and the JS-bundle workflow.
Flutter
Getting started
Add Sankofa to a Flutter app, ship a base release, ship your first patch.
Flutter
Design for hot-fixes
The interface pattern that makes Dart logic patchable. Start here.
Guide
Rollouts & safety
Rollout %, mandatory updates, rollback / roll-forward, the boot-crash net.
Reference
Platform & policy
iOS vs Android capabilities and store-compliance framing.
Reference
FAQ & limits
Common questions and the boundaries of what Deploy can ship.