Sunsetting an App Well — Designing the Path from Update Freeze to Full Shutdown

Serve the Sunset Notice from a Server-Side Flag

The single most important mechanism in stage 3 is the in-app notice. Editing the store listing reaches nobody who already installed the app. The app itself needs a way to learn that it is ending.

Firebase Remote Config can do this, but for an app on its way out I recommend a static JSON file on a CDN instead, for two reasons. You do not want to add a new SDK dependency to an app you are retiring. And a static file can outlive the backend: after the origin is gone, serving one JSON file from static hosting costs effectively nothing for years.

// app-status.ts — the server side is a single static JSON on a CDN
import AsyncStorage from "@react-native-async-storage/async-storage";
 
export type SunsetMode = "active" | "notice" | "readonly" | "ended";
 
export interface AppStatus {
  mode: SunsetMode;
  message?: string;      // notice text (switch by device locale)
  exportUntil?: string;  // deadline for data export (ISO 8601)
  learnMoreUrl?: string; // support page with details
}
 
const STATUS_URL = "https://static.example.com/app-status/my-app.json";
const CACHE_KEY = "app_status_cache_v1";
 
export async function fetchAppStatus(): Promise<AppStatus> {
  try {
    const res = await fetch(STATUS_URL, {
      headers: { "cache-control": "no-cache" },
    });
    if (!res.ok) throw new Error(`status ${res.status}`);
    const status = (await res.json()) as AppStatus;
    await AsyncStorage.setItem(CACHE_KEY, JSON.stringify(status));
    return status;
  } catch {
    // On failure, fall back to the last known value.
    // With no cached value, default to active so normal startup is protected.
    const cached = await AsyncStorage.getItem(CACHE_KEY);
    return cached ? (JSON.parse(cached) as AppStatus) : { mode: "active" };
  }
}

Note the direction of the fallback: a failed fetch resolves to normal startup. Invert it and a brief CDN hiccup turns your entire app into a shutdown screen. For a notice like this, safety beats certainty.

The launch path just branches on the mode.

// App.tsx — evaluate once at launch
const [status, setStatus] = useState<AppStatus>({ mode: "active" });
 
useEffect(() => {
  fetchAppStatus().then(setStatus);
}, []);
 
if (status.mode === "ended") {
  return <SunsetScreen status={status} />; // final screen, with export action
}
return (
  <>
    {status.mode !== "active" && <SunsetBanner status={status} />}
    <MainApp readonly={status.mode === "readonly"} />
  </>
);

The notice mode keeps the app fully usable with a banner; readonly disables writes and leaves browsing and export. Advancing a stage means editing one JSON file — no app review required. So the practice is: when you decide to retire an app, ship one last update that adds this hook. The apps where I skipped that final update are the ones whose cleanup cost me the most time afterward.

Give Users a Way to Take Their Data With Them

Favorites, settings, anything accumulated on the device deserves an exit door. The implementation is small — serialize to JSON and hand it to the share sheet.

// export-user-data.ts
import AsyncStorage from "@react-native-async-storage/async-storage";
import * as FileSystem from "expo-file-system";
import * as Sharing from "expo-sharing";
 
export async function exportUserData(): Promise<void> {
  const favorites = await AsyncStorage.getItem("favorites_v2");
  const settings = await AsyncStorage.getItem("settings_v1");
 
  const payload = {
    exportedAt: new Date().toISOString(),
    schemaVersion: 2,
    favorites: favorites ? JSON.parse(favorites) : [],
    settings: settings ? JSON.parse(settings) : {},
  };
 
  const uri = FileSystem.cacheDirectory + "my-data-export.json";
  await FileSystem.writeAsStringAsync(uri, JSON.stringify(payload, null, 2));
  await Sharing.shareAsync(uri, { mimeType: "application/json" });
}

Including a schema version in the export pays off if you ever ship a successor app that imports the file. Even with no successor, the plain fact that users keep their data changes how the shutdown is received.

Winding Down Auto-Renewable Subscriptions

If the app sells subscriptions, the order of operations gets stricter, because removing the app from sale does not stop existing subscriptions — they keep renewing until each subscriber cancels.

First, close the purchase flow inside the app using the same sunset flag, so no new subscriptions begin. Then end the availability of the subscription products in App Store Connect. Existing subscribers get the shutdown date and cancellation instructions through the in-app notice and the support page. Cancellation is an action only the user can take, which is exactly why early notice is the honest form of it.

How you treat the last remaining subscribers is less a question of money than of posture. Do not let renewals continue past the point where the service has effectively ceased: set the shutdown date at least one full billing cycle out. Individual refunds largely flow through Apple's own mechanisms, but whether you did everything you could to inform people shows up, verbatim, in your final reviews.

Do Not Switch the Server Off — Degrade It in Steps

The backend comes down in stages, not with one switch.

On Cloudflare Workers, step 2 is nothing more than swapping the Worker's responses for fixed values from KV or static assets. Even after the dynamic backend is gone, a static snapshot of the last content you served lets the experience degrade gently instead of breaking. The option to keep that snapshot alive for years at near-zero cost is the second reason I prefer the static JSON approach throughout.

What Remains After You Pull the App

Pressing the remove-from-sale button never gets entirely comfortable — my finger still hesitates every time. Knowing what persists afterward makes it lighter.

Installed copies keep running. The support URL and the privacy policy page must stay up for as long as those users exist; take them down and inquiries have nowhere to go. As long as you maintain the developer account, the same app can even return to sale under the same App ID. Removal is closer to dormancy than to disposal.

The best return on this experience, though, goes to the apps still in service: add the app-status.json hook to them now. The best outcome is never needing it. But if the day comes, the time you saved by not scrambling to ship a final update becomes, quite directly, the care you can put into the goodbye.

Designing the last day is part of designing the app. I hope this serves as a useful piece of preparation that grows more valuable the longer your apps live.