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 and native Android (in development), a Server-Driven-UI description rendered as real SwiftUI or Compose, 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.