Mobile App Over-The-Air (OTA) Updates: Shorebird vs. Expo EAS Update Architecture & App Store Compliance Playbook

# Mobile App OTA Updates Shorebird vs EAS Update: Architecture & App Store Compliance Playbook

Summary: Over-the-air (OTA) updates decouple runtime code delivery from native app store review queues, enabling mobile engineering teams to deploy production hotfixes in minutes rather than days. While Shorebird applies binary differential patches to compiled Flutter code using an embeddable Dart interpreter fallback, Expo EAS Update replaces complete Hermes JavaScript bytecode bundles for React Native. Both platforms adhere to Apple Guideline 2.5.2 and Google Play policies when restricted to bug fixes and paired with Ed25519 cryptographic signing.

---

The Mobile Deployment Crisis: App Store Review Bottlenecks and Production Hotfixes

Shipping native mobile applications introduces an operational bottleneck unknown to cloud-native web engineering: the asynchronous, opaque app store review queue. In modern web environments, teams deploy continuously using progressive rollouts, automated canary analyses, and sub-minute rollbacks. In contrast, native mobile updates must traverse Apple App Store and Google Play review pipelines. While Apple reports that over 90% of submissions are reviewed within 24 to 48 hours, real-world deployment turnaround routinely extends between 24 and 72 hours when accounting for queue variance, timezone offsets, expedited review processing, and multi-stage regression testing.

flowchart LR
    subgraph Traditional["Traditional App Store Release (Modeled 48-96h Cycle)"]
        direction TB
        A1["Critical Bug in Prod"] --> A2["Git Fix & Native Build"]
        A2 --> A3["Upload IPA/AAB (1-2h)"]
        A3["Upload IPA/AAB (1-2h)"] --> A4["Store Review Queue (Typical 24-48h)"]
        A4 --> A5["Gradual User Rollout (24-72h)"]
    end

    subgraph ModernOTA["Modern Mobile Hotfix Architecture 2026 (<15m Cycle)"]
        direction TB
        B1["Critical Bug in Prod"] --> B2["Targeted Code Patch"]
        B2 --> B3["Ed25519 Cryptographic Sign"]
        B3 --> B4["Push to CDN / Patch Edge"]
        B4 --> B5["Active Client Hotfix (<15m)"]
    end

When an unhandled exception or breaking API payload regression disrupts checkout funnels, authentication sessions, or regulatory compliance disclosures, waiting multiple days for a store review translates directly into lost revenue, negative store ratings, and permanent customer churn. Furthermore, even after store approval, user adoption of traditional native binary updates follows a prolonged tail: mobile analytics benchmarks and fleet telemetry regularly observe that a notable segment of active users (frequently estimated between 15% and 30% across enterprise mobile cohorts) remains on legacy builds for days or weeks due to disabled automatic app updates, metered cellular connections, or device storage constraints.

Over-The-Air (OTA) update architecture solves this mobile deployment crisis. By decoupling runtime code updates from native platform wrapper distribution, OTA code push enables engineering teams to ship critical bug fixes directly to end-user devices within minutes.

However, implementing mobile hotfixes at enterprise scale introduces complex architectural tradeoffs. Teams must navigate binary compilation differences across cross-platform frameworks, minimize startup performance penalties, prevent over the air updates mobile security risk, and adhere strictly to Apple App Store Review Guideline 2.5.2.

---

Engine Internals: Shorebird Dart AOT Patcher vs. Expo EAS Update Hermes Replacer

The architectural divergence between Shorebird (for Flutter) and Expo EAS Update (for React Native) originates in how their respective foundational frameworks execute application logic on native operating systems.

flowchart TD
    subgraph ShorebirdArch["Shorebird Engine Architecture (Flutter)"]
        direction TB
        S_Base["Native Flutter Binary (libapp.so / App.framework)"] --> S_Engine["Patched Dart Engine Runtime"]
        S_Patch["Delta Patch (BSDiff / Zstd Snapshot)"] --> S_Engine
        S_Engine --> S_Detect{"Code Modified?"}
        S_Detect -- "Unmodified Function" --> S_AOT["Direct Machine Execution (ARM64 AOT Native Speed)"]
        S_Detect -- "Modified Function" --> S_Interp["Shorebird Dart Interpreter Fallback"]
    end

    subgraph EASArch["Expo EAS Update Architecture (React Native)"]
        direction TB
        E_Base["Native Host Container (Objective-C/Swift/Kotlin)"] --> E_Hermes["Hermes Bytecode Engine"]
        E_Bundle["Complete Hermes Bytecode Bundle (.hbc)"] --> E_Updates["expo-updates Native Module"]
        E_Updates --> E_Mmap["Memory-Mapped Bundle Swap (mmap)"]
        E_Mmap --> E_Hermes
        E_Hermes --> E_JS["Hermes VM Bytecode Execution"]
    end

Shorebird: Differential Machine Code Patching via Custom Dart VM

When engineering teams implement a shorebird flutter ota code push pipeline, they resolve a long-standing constraint in mobile delivery. Flutter applications are compiled ahead-of-time (AOT) into native ARM64 machine code—packaged as libapp.so on Android and App.framework on iOS. Historically, platforms like Microsoft CodePush could not support Flutter because Apple's iOS sandbox strictly enforces Write XOR Execute ($W\oplus X$) memory protection policies, prohibiting dynamic allocation of executable memory (mprotect(PROT_EXEC)). Executing arbitrary downloaded native machine code is blocked by operating system security policies.

Shorebird bypasses this architectural barrier without violating platform execution policies by modifying the underlying Flutter engine:

1. Engine-Level Fork: Shorebird replaces the standard Flutter engine with a custom, drop-in binary compatible fork of the Flutter engine and Dart Virtual Machine.

2. Differential Binary Generation: During CI/CD, the Shorebird CLI evaluates the compiled release binary against the new patch code. Using binary delta algorithms (BSDiff coupled with Zstandard compression), it isolates only the modified classes and method declarations.

3. Dual Execution Path:

Unchanged Functions*: Execute directly on bare metal as pre-compiled native ARM64 machine code, preserving maximum frame rates and CPU efficiency.

Patched Functions*: When the patched Dart VM encounters a modified function symbol, an internal trampoline redirects execution to Shorebird's specialized, embeddable Dart interpreter. While unoptimized Dart interpreter execution can be up to 100x slower on CPU-bound operations or tight mathematical loops according to Shorebird's architectural documentation, UI event handlers, network callbacks, and state updates execute with negligible human-perceptible latency because unmodified widget trees and the Flutter rendering engine continue running at full native AOT speed.

4. Micro-Payload Delivery: Because Shorebird transmits only differential symbol changes and interpreted bytecode tables rather than entire framework bundles, patch payloads remain compact compared to full store downloads. According to Shorebird's official architectural documentation, Android patch slices typically start around ~160 KB per architecture slice (arm64-v8a), while iOS patches typically measure a few hundred kilobytes (often ~200 KB to ~500 KB depending on modified symbol graphs).

Expo EAS Update: Atomic Hermes Bytecode Bundle Replacement

React Native operates on a decoupled runtime model consisting of a native platform container (Java/Kotlin on Android, Objective-C/Swift on iOS) communicating with a JavaScript environment. In modern React Native architectures, the JavaScript code is compiled during build time into optimized bytecode executed by Facebook's Hermes engine.

Expo EAS Update uses an atomic bundle replacement model:

1. Hermes Bytecode Compilation: React Native TypeScript and JavaScript assets are bundled and transformed into Hermes Bytecode (index.android.bundle.hbc and index.ios.bundle.hbc).

2. Asset Manifest Graph: EAS Update parses the application's static dependency tree (fonts, raster assets, vector SVGs). It computes SHA-256 content hashes for every individual asset.

3. Atomic Bundle Swap: When a new update publishes to an EAS branch, the expo-updates native client queries the update protocol endpoint. It downloads only the newly introduced or modified static assets alongside the fresh Hermes bytecode bundle.

4. Memory-Mapped Loading: The native runtime swaps the file descriptor reference and maps the new bytecode bundle into memory using mmap(), initializing the new application state upon subsequent application launch.

---

Side-by-Side Architectural Comparison Matrix

Selecting the appropriate mobile hotfix deployment architecture 2026 requires understanding the performance, payload, and operational tradeoffs between Shorebird and EAS Update:

Shorebird delivers an advantage in wire payload efficiency and cold-start predictability, making it suitable for bandwidth-constrained environments. Expo EAS Update provides a uniform runtime model where all code executes inside the Hermes VM without runtime interpreter switching.

---

Apple App Store Review Guideline 2.5.2 Compliance Matrix

Navigating the expo eas update app store compliance guideline 2.5.2 perimeter alongside Shorebird patch policies is an essential governance task for mobile engineering leaders. Engineering executives frequently express apprehension regarding whether over-the-air code modifications trigger store rejections or developer account bans. Both Apple and Google permit runtime code updates, but enforce strict boundaries around what can be modified.

Apple App Store Review Guideline 2.5.2 specifies:

"Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces new features or functionality, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the application completely viewable and editable by the user."

In tandem, Section 3.3.2 of the Apple Developer Program License Agreement (DPLA) governs interpreted code and dynamic scripting. Apple permits interpreted code (such as JavaScript evaluated by JavaScriptCore or Hermes, and Dart logic interpreted by Shorebird's runtime) provided that such code does not introduce features or functionality inconsistent with the primary purpose of the application as submitted and approved, does not create an alternative app store or storefront, and complies with all OS sandboxing rules.

Google Play's Device and Network Abuse policy similarly prohibits apps from downloading executable code (such as .dex, .jar, or .so files) from third-party sources outside the Google Play distribution pipeline, but explicitly exempts code running within a virtual machine or interpreter, provided that code does not circumvent Google Play policies or alter the primary purpose of the app.

The compliance perimeter depends on functional intent and permission boundaries:

Enterprise Compliance Governance Playbook

To ensure adherence to Apple Guideline 2.5.2 and store distribution rules, enterprise organizations must institute three mandatory deployment gates:

1. Semantic Version Binding: Bind every OTA patch strictly to a single native release version (e.g., runtimeVersion: "1.4.2"). Never allow patches to span across minor or major native binary releases.

2. Audit Logging & Telemetry: Maintain an immutable changelog recording every patch's Git commit SHA, issue tracker ticket ID, differential file list, and author approval.

3. Feature Flag Isolation: If an OTA patch includes logic for an unreleased feature, keep that feature hidden behind a server-side feature toggle (e.g., LaunchDarkly or Flagsmith). Never activate net-new functional modules via OTA until the native binary carrying full disclosure has cleared App Store Review.

[!IMPORTANT]

Falsifiability Check: How do engineering leaders confirm an OTA update does not breach compliance boundaries? Implement automated CI/CD static diff validation: reject any patch that introduces new native bridge selectors, modifies permissions in native configuration manifests, or alters top-level navigation routes without a corresponding App Store Connect binary release.

---

Zero-Trust Security Threat Model: Ed25519 Signing & MITM Tampering Prevention

Allowing a mobile application to download and execute code over the network introduces a high-priority attack surface. Without rigorous cryptographic verification, an OTA update mechanism can serve as an automated remote code execution (RCE) vector for malicious actors.

Primary Threat Vectors

• Man-In-The-Middle (MITM) Packet Injection: An attacker on an untrusted public Wi-Fi network intercepts unencrypted or unpinned HTTP traffic and returns a weaponized JavaScript bundle or Dart patch that steals authentication tokens.
• Content Delivery Network (CDN) / S3 Bucket Compromise: If an attacker gains unauthorized access to the cloud storage bucket hosting OTA update bundles, they could push malicious code directly to millions of active installations.
• Replay and Downgrade Attacks: An attacker intercepts a legitimate, signed historical patch with a known security vulnerability and replays it to newer devices to force a regression.

sequenceDiagram
    autonumber
    actor Dev as Release Engineer
    participant CI as CI/CD Pipeline (HSM)
    participant CDN as Update Server / CDN
    participant App as Mobile App Runtime
    participant OS as Native Security Subsystem

    Dev->>CI: Trigger Hotfix Build (Git Tag)
    CI->>CI: Compile Patch Bundle
    CI->>CI: Compute SHA-256 Digest
    CI->>CI: Sign Digest with Ed25519 Private Key
    CI->>CDN: Upload Signed Manifest + Patch Payload
    
    App->>CDN: Poll for Updates (Current Version + Nonce)
    CDN-->>App: Return Manifest (Payload URL + Ed25519 Signature)
    App->>CDN: Download Patch Binary to Sandbox Quarantine
    App->>OS: Retrieve Baked-in Public Key (Native Binary Segment)
    App->>App: Calculate SHA-256 Digest of Local Payload
    App->>App: Verify Ed25519(Digest, Signature, PublicKey)
    
    alt Signature Verification Fails
        App->>App: Discard Corrupted Payload & Delete Quarantine
        App->>App: Fallback to Embedded Baseline Native Binary
        App-->>Dev: Transmit Security Alert Telemetry
    else Signature Verification Succeeds
        App->>App: Check Sequence Number >= Current Sequence
        App->>App: Stage Patch to Active Runtime Directory
        App->>App: Mount Patch on Next Boot / Reload
    end

Cryptographic Implementation: Ed25519 Public-Key Verification

The zero-trust standard for OTA patch distribution relies on Ed25519 asymmetric cryptography. Unlike symmetric keys (which would expose the decryption key if decompiled from the mobile app binary), asymmetric signing uses a keypair:

• Private Signing Key: Stored securely in a hardware security module (HSM) or encrypted CI/CD secrets manager (e.g., AWS KMS or HashiCorp Vault). It never leaves the build pipeline.
• Public Verification Key: Hardcoded directly into the native mobile application code (within a read-only binary segment of Swift/Kotlin).

Before the mobile application runtime applies any downloaded patch file, the native layer verifies the cryptographic signature:

$$\text{Valid} = \operatorname{Ed25519\_Verify}\Big(K_{\text{public}},\, \operatorname{SHA-256}(\text{PatchPayload}),\, \text{Signature}\Big)$$

If the verification fails by even a single bit flip, the runtime immediately purges the quarantined download from disk, retains the original baseline native code, and transmits an alert event to the mobile observability platform.

---

Production Hotfix Architecture: State Preservation, Offline Sync, and Push Notification Queues

Executing an over-the-air hotfix in production involves more than delivering a file to disk. Mobile architects must coordinate application state, local databases, and network queues to prevent data corruption.

Silent Push Notifications as Update Triggers

Relying solely on user-initiated cold starts to discover updates leaves a vulnerability window open for hours or days. Advanced mobile hotfix deployment architecture pairs OTA distribution with silent push notifications:

• iOS: Silent Apple Push Notification Service (APNs) payloads with "content-available": 1 and apns-priority: 5.
• Android: Firebase Cloud Messaging (FCM) high-priority data messages (priority: "high").

{
  "aps": {
    "content-available": 1
  },
  "ota_update": {
    "channel": "production",
    "min_runtime_version": "2.4.0",
    "patch_id": "patch_v240_hotfix8",
    "signature": "d3b07384d113edec49eaa6238ad5ff00..."
  }
}

Upon receipt, the native background handler initializes, invokes Shorebird's shorebirdCodePush.downloadUpdateIfAvailable() or Expo's Updates.fetchUpdateAsync(), verifies the cryptographic signature in the background, and prepares the update. When the user subsequently launches the application, the patch is already loaded into local flash storage, eliminating network waiting periods entirely.

Protecting In-Flight User State During Hotfix Mounts

Forcing an instantaneous UI reload while an end user is entering credit card details or filling a form causes user frustration. The application runtime must handle patch transitions defensively:

// Expo EAS Update Defensive Lifecycle Handler
import * as Updates from 'expo-updates';
import { AppState, Alert } from 'react-native';

export function configureDefensiveUpdateLifecycle() {
  Updates.addListener((event) => {
    if (event.type === Updates.UpdateEventType.UPDATE_AVAILABLE) {
      // Defer reload if user is actively engaged in transactional flows
      const isTransactionalScreen = checkActiveRouteIsCritical();
      
      if (!isTransactionalScreen) {
        // Option A: Silently wait until app transitions to background
        const subscription = AppState.addEventListener('change', (nextState) => {
          if (nextState === 'background') {
            subscription.remove();
            Updates.reloadAsync();
          }
        });
      } else {
        // Option B: Schedule patch application for next cold launch
        console.info('[OTA] Patch downloaded; deferred until next cold start.');
      }
    }
  });
}

Database Schema Migration Hazards (SQLite, Drift, WatermelonDB)

A critical error in mobile OTA management is attempting local database schema migrations over OTA code pushes.

If an OTA update modifies an SQLite table structure (e.g., executing ALTER TABLE users ADD COLUMN loyalty_tier TEXT NOT NULL) and the user later experiences an engine crash that triggers Shorebird's automatic rollback or an EAS update rollback, the underlying database will now exist on schema version $N+1$, while the rolled-back application code expects schema version $N$. This mismatch causes persistent SQLiteException startup crashes.

The Golden Rule of Mobile OTA State:

Never perform irreversible database schema migrations or local storage structural rewrites inside an OTA patch.

Schema mutations must be reserved exclusively for full native binary releases distributed through app store pipelines. OTA updates should implement defensive schema handling: use optional keys, flexible JSON blobs, or runtime fallback adapters to read and write data safely without mutating underlying database structures.

---

Automated CI/CD Patch Pipeline: Production GitHub Actions Snippet

The following enterprise GitHub Actions workflow automates the generation, signing, and phased distribution of over-the-air patches across both Shorebird (Flutter) and Expo EAS Update (React Native), incorporating automated security validation:

name: Mobile Over-The-Air (OTA) Production Hotfix Pipeline

on:
  workflow_dispatch:
    inputs:
      target_framework:
        description: 'Target Mobile Framework'
        required: true
        type: choice
        options:
          - 'shorebird-flutter'
          - 'expo-react-native'
      release_version:
        description: 'Target Native Release Version (e.g., 2.4.1)'
        required: true
        type: string
      rollout_percentage:
        description: 'Initial Canary Rollout Ring (Percentage)'
        required: true
        default: '10'
        type: choice
        options:
          - '10'
          - '25'
          - '50'
          - '100'

permissions:
  contents: read
  id-token: write

jobs:
  validate-and-deploy-hotfix:
    runs-on: ubuntu-latest
    timeout-minutes: 25

    steps:
      - name: Checkout Source Repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      # -------------------------------------------------------------
      # PATH A: SHOREBIRD FLUTTER ENGINE PATCH
      # -------------------------------------------------------------
      - name: Setup Java Development Kit (JDK 17)
        if: ${{ github.event.inputs.target_framework == 'shorebird-flutter' }}
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Setup Shorebird Code Push CLI
        if: ${{ github.event.inputs.target_framework == 'shorebird-flutter' }}
        uses: shorebirdtech/actions/setup-shorebird@v1
        with:
          shorebird-token: ${{ secrets.SHOREBIRD_TOKEN }}

      - name: Compile and Dispatch Shorebird Android Patch
        if: ${{ github.event.inputs.target_framework == 'shorebird-flutter' }}
        run: |
          echo "Building Shorebird differential patch for version ${{ github.event.inputs.release_version }}..."
          shorebird patch android \
            --release-version="${{ github.event.inputs.release_version }}" \
            --force \
            --allow-asset-diffs

      # -------------------------------------------------------------
      # PATH B: EXPO EAS UPDATE REACT NATIVE BUNDLE
      # -------------------------------------------------------------
      - name: Setup Node.js Runtime
        if: ${{ github.event.inputs.target_framework == 'expo-react-native' }}
        uses: actions/setup-node@v4
        with:
          node-version: '20.x'
          cache: 'npm'

      - name: Install Application Dependencies
        if: ${{ github.event.inputs.target_framework == 'expo-react-native' }}
        run: npm ci

      - name: Setup EAS CLI & Authenticate
        if: ${{ github.event.inputs.target_framework == 'expo-react-native' }}
        uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}

      - name: Export and Sign EAS Hermes Bytecode Update
        if: ${{ github.event.inputs.target_framework == 'expo-react-native' }}
        env:
          EXPO_UPDATES_CODE_SIGNING_KEY: ${{ secrets.ED25519_PRIVATE_KEY }}
        run: |
          echo "Generating cryptographically signed EAS update..."
          eas update \
            --branch="production" \
            --message="Hotfix Release: ${{ github.event.inputs.release_version }} (Canary: ${{ github.event.inputs.rollout_percentage }}%)" \
            --auto

      # -------------------------------------------------------------
      # AUDIT TELEMETRY & OBSERVABILITY NOTIFICATION
      # -------------------------------------------------------------
      - name: Record Audit Log and Alert Engineering Slack
        run: |
          curl -X POST -H 'Content-type: application/json' \
            --data '{
              "text": "🚀 *Mobile OTA Hotfix Deployed*\n*Framework:* `${{ github.event.inputs.target_framework }}`\n*Target Native Version:* `${{ github.event.inputs.release_version }}`\n*Rollout Ring:* `${{ github.event.inputs.rollout_percentage }}%`\n*Triggered By:* `${{ github.actor }}`"
            }' ${{ secrets.SLACK_WEBHOOK_URL }}

---

Strategic Mobile Architecture: Executive ROI & Implementation Framework

Adopting an enterprise-grade over-the-air update system alters mobile business metrics by collapsing the Mean Time to Resolution (MTTR) for high-severity production defects.

xychart-beta
    title "Mean Time to Resolution (MTTR): Traditional vs. Enterprise OTA (Modeled Hours)"
    x-axis ["Bug Discovery", "Engineering Patch", "Store Review Lag", "User Adoption (80%)", "Total MTTR"]
    y-axis "Hours" 0 --> 100
    bar [1.5, 2.0, 36.0, 48.0, 87.5]
    bar [1.5, 2.0, 0.0, 0.25, 3.75]

The Economic Model of OTA Infrastructure

The following representative enterprise model illustrates the financial disparity in incident duration between traditional binary store resubmissions and over-the-air hotfixes. Consider a digital commerce or subscription application generating $50 million in annual gross merchandise volume (~$137,000 daily):

1. Revenue at Risk: A regression breaking the checkout flow or payment tokenization path during peak marketing periods costs approximately $5,700 per hour in direct lost revenue.

2. Modeled App Store Release Delay: Under a conventional native release cycle, even when assuming an expedited app review is granted (modeled conservatively at ~18 hours) alongside typical staged user adoption lag (~24 hours to reach primary active cohorts), the business faces roughly 42 hours of incident exposure, resulting in a modeled $239,400 in direct gross loss.

3. OTA Hotfix Mitigation: Delivering a cryptographically signed Shorebird differential patch or EAS Update within 15 minutes reduces incident exposure to under $1,500.

When architecting cross-platform systems for enterprise scale, partnering with specialized engineers for enterprise mobile app development services ensures your runtime architecture, CI/CD pipelines, and patch verification layers maintain zero-downtime reliability and strict compliance.

---

Frequently Asked Questions

What happens if a user runs an older native binary version and an OTA patch is published?

OTA updates are bound to specific native binary fingerprints (via runtimeVersion in EAS or release-version in Shorebird). If an update is published for native binary v2.4.0, devices running native v2.3.0 will ignore the update manifest. The update client validates the native container's hash before applying code changes, preventing crashes caused by missing native bridges or unmapped system symbols.

Can Shorebird or Expo EAS Update modify native Swift, Kotlin, or C++ code?

No. Over-the-air updates cannot modify native platform binaries, compiled C/C++ libraries, or native Gradle/CocoaPods dependencies. Any modification requiring changes to native files (such as updating the Facebook SDK, adjusting native camera drivers, or modifying Info.plist/AndroidManifest.xml) requires building a full native binary and submitting it through standard App Store and Google Play review channels.

How do you prevent local SQLite or WatermelonDB schema corruption during an OTA hotfix?

Never perform destructive or structural database schema migrations (such as removing columns, renaming tables, or enforcing non-null constraints on legacy columns) inside an OTA hotfix. If a bug forces a rollback to an earlier patch version, the rolled-back code will crash when reading the altered database schema. Reserve all schema mutations for native binary app store releases, and use defensive JSON mapping or nullable data wrappers within OTA patches.

How does background OTA fetching interact with iOS background execution limits?

iOS strictly regulates background execution through the operating system's Background Execution Manager. To perform silent background updates, applications must configure the remote-notification Background Mode capability in Xcode and process incoming APNs silent pushes (content-available: 1). iOS allocates an execution budget of approximately 30 seconds for background downloads. Shorebird's differential payloads (typically starting around ~160 KB per architecture on Android and a few hundred kilobytes on iOS) fit comfortably within this background window, while larger React Native bundles should use resilient background download sessions (NSURLSessionConfiguration.background).

---

Sources

• Apple Developer: App Store Review Guidelines – Section 2.5.2 compliance parameters and acceptable interpreter execution rules.
• Apple Developer Program License Agreement – Section 3.3.2 terms governing interpreted code and scripting execution.
• Shorebird Architecture Documentation – Modified Dart VM execution, interpreter fallback mechanics, and binary diffing.
• Expo EAS Update Concepts & Protocol – Hermes bytecode bundle lifecycle, asset manifests, and expo-updates client protocol.
• Google Play Policy Center: Device and Network Abuse – Policies governing dynamic code distribution on Android.
• IETF RFC 8032: Edwards-Curve Digital Signature Algorithm (Ed25519) – Cryptographic standard for asymmetric digital signatures.
• Meta Open Source: Hermes JavaScript Engine – Memory-mapped bytecode execution architecture for mobile runtimes.