Migration9 min read

Ionic Appflow is shutting down: what to do next

Ionic Appflow is being wound down. Here is what the shutdown means for your live updates and native builds, your realistic migration options, and how to move to OtaKit without a rebuild.

If you shipped Capacitor or Ionic apps through Ionic Appflow, the wind-down puts your two most operationally important features on the clock: Live Updates and native cloud builds. The good news is that neither is hard to replace, and the live-update half in particular maps almost one-to-one onto OtaKit. This guide covers what actually changes, what you need to move, and a safe cutover plan.

The urgent part is Live Updates. A retired backend eventually stops serving update manifests, and a device that can't reach its update server just keeps running the last bundle it has. Migrate the update channel first; move the CI builds at your own pace.

What you actually lose

Appflow bundled several things under one subscription. When you unbundle them, most have clean, cheaper replacements:

  • Live Updates — over-the-air web-layer updates. This is the piece that needs a live server, so it's the one to move first.
  • Native cloud builds (iOS/Android) — replaceable with GitHub Actions, GitLab CI, Codemagic, or Xcode Cloud. See our iOS build in GitHub Actions and Android build guides.
  • Automations — the deploy-to-channel step becomes one CLI call in your own pipeline.

Why not just move to another platform-priced tool

Appflow's pricing is exactly why teams are looking to leave rather than renew: live updates were tied into a broad, seat-and-tier platform. OtaKit takes the opposite approach — no MAU metering, no bandwidth metering, CDN-direct delivery from a static signed manifest, and a fully MIT-licensed stack you can self-host. Most apps land in the $0–25/mo range. We break down the head-to-head in Capacitor + OtaKit vs Appflow.

Migrating Live Updates to OtaKit

Appflow's live update model and OtaKit's are conceptually the same: a channel maps to a stream of web-build bundles that devices check for on launch. The move is mechanical:

  1. Swap the plugin. Remove the Appflow live-update dependency and install @otakit/capacitor-plugin. Point config at your OtaKit app and channel.
  2. Wire a release step. Where Appflow ran a deploy automation, run the OtaKit CLI:
    otakit upload --release production
  3. Keep notifyAppReady(). If you were calling Appflow's ready signal after a successful boot, the OtaKit equivalent plays the same role — it's what arms automatic rollback.

The full config and API translation lives in our migration guide, and the general Appflow replacement rundown is in the best Appflow alternative.

A safe cutover plan for your install base

Devices in the wild are still pointed at Appflow. Cut over without stranding anyone:

  1. Ship one store release that swaps the live-update plugin to OtaKit. This is the only step that requires a review, because it changes native dependencies.
  2. As users update through the store, their devices start checking OtaKit instead. From then on every web-layer change ships over the air again.
  3. Keep Appflow live until the tail of your install base has moved to the new binary, then let it lapse.

Because the plugin swap is a native change, plan it like any store release — and use it as the last one you'll need to wait on for a while. After it lands, OtaKit ships the web layer without another review.

Where to go next

Start with Setup, then the CLI reference for the release command. If you want the honest feature-by-feature comparison first, read the best OTA tools for Capacitor.

Related docs