How Birdify works

The model

Your app ships to the store once, with the Birdify SDK embedded. From then on, most changes — business logic, UI, copy, config — travel as managed bundles the SDK loads at launch instead of running from the store binary. You keep shipping to the store for anything that touches native code; everything else goes out over the air in seconds.

What ships over the air

A bundle is your app's managed layer — never compiled native code. What's inside depends on the framework:

• Flutter — the compiled Dart bundle. Birdify diffs it and reconstructs it on device for both iOS and Android.
• React Native — the JavaScript bundle (Expo or bare), swapped on next launch.
• Native iOS — a Server-Driven-UI description rendered as real SwiftUI, plus logic evaluated in a sandbox. No downloaded machine code.

Release → patch → device

A release is the signed baseline that matches the store binary. A patch is a diff against that baseline. Birdify uploads only what changed, serves it from edge storage, and the SDK fetches and verifies it before applying on the next launch.

release 1.0.0  ── signed baseline (matches the store build)
  └─ patch #1   diff · signed · 4.2 MB → 38 KB on the wire
       └─ device  fetch · verify sig + sha256 · apply next launch
✓ # users on the latest UI without an update prompt

Why it stays store-safe

App Store and Play policy allow apps to update interpreted code and content — they draw the line at downloading native executables. Birdify never ships native code: bundles are managed data your embedded SDK already knows how to run, so OTA updates stay inside the rules.