My Ads Never Came Back After a Subscription Expired: Fixing the Direction of an Ad-Free Check

On a failed call, change nothing

With the function in place I laid out every combination and fed the same inputs to the broken version and the fixed one. This is the result from Node 22.

The two versions differ only in case A. The whole bug lived in that one line. The other five rows exist to confirm that fixing it did not change anything else, and the table shows that at a glance.

Cases B and E carry a second meaning: on a day with a bad connection, a paying user still gets no ads. When you cannot decide, you trust the previous value. How long to keep trusting it is a separate design; I covered that from another angle in Opening the App in Airplane Mode Shows Paywalls to Paying Members: Offline Entitlement Caching With RevenueCat.

A controller that stale responses cannot overwrite

The function alone was not enough. In a real app the check runs every time the app returns to the foreground and right after a purchase. When checks overlap, an older one can return late and overwrite a newer result.

First I reproduced the form that applies each source as it arrives.

// naive.ts — applying each source as it arrives (for reproduction)
import type { QueryResult } from "./adfree.ts";
export function makeNaive(initial: boolean, log: (s: string) => void) {
  let state = initial;
  return (r: QueryResult) => {
    const next = r.ok ? r.active : state; // decides from the one result that just arrived
    if (next !== state) { state = next; log(`naive -> ${next}`); }
  };
}

Giving it a subscription "inactive" first and a one-time "active" afterwards produced naive -> false / naive -> true. Ads come back, then vanish again: a brief flicker for a paying user.

The fixed version gives the controller a generation number.

// Controller with a generation number: waits for both, ignores stale responses
export type Query = () => Promise<QueryResult>;
 
export class AdFreeController {
  private generation = 0;
  private current: boolean;
  private queries: Record<Source, Query>;
  private onChange: (adFree: boolean) => void;
  constructor(
    queries: Record<Source, Query>,
    initial: boolean,
    onChange: (adFree: boolean) => void = () => {},
  ) {
    this.queries = queries;
    this.current = initial;
    this.onChange = onChange;
  }
  get adFree(): boolean {
    return this.current;
  }
  async refresh(): Promise<boolean> {
    const mine = ++this.generation;
    const wrap = (q: Query): Promise<QueryResult> =>
      q().catch((e: unknown): QueryResult => ({ ok: false, reason: String(e) }));
    const [subscription, oneTime] = await Promise.all([
      wrap(this.queries.subscription),
      wrap(this.queries.oneTime),
    ]);
    if (mine !== this.generation) return this.current; // a newer refresh has started: discard this one
    const next = composeAdFree(this.current, { subscription, oneTime });
    if (next !== this.current) {
      this.current = next;
      this.onChange(next);
    }
    return this.current;
  }
}

Inside refresh() it does three things: waits for both sources with Promise.all, turns a thrown exception into a "failed" value so nothing crashes, and discards its result if a newer refresh has started.

This is what I observed when I delayed and reordered the responses.

The second row is my favorite. The old answer says active and the new answer says inactive. Which one is right is not decided by speed. A newer answer must never lose to an older one. A generation number keeps that promise with a single integer.

A sketch for wiring this into an Expo app

From here on it is a sketch whose types I have not checked and which I have not run on a device. I wrote it assuming an app generated with Rork could connect the same way.

// useAdFree.tsx — re-ask both sources whenever the app returns to the foreground (sketch, not run on a device)
import { useEffect, useRef, useState } from "react";
import { AppState } from "react-native";
import AsyncStorage from "@react-native-async-storage/async-storage";
import { AdFreeController, type QueryResult } from "./adfree";
 
const KEY = "adfree:last";
 
// Wrap your billing SDK calls here (report failures as ok:false)
async function querySubscription(): Promise<QueryResult> {
  return { ok: false, reason: "not implemented" };
}
async function queryOneTime(): Promise<QueryResult> {
  return { ok: false, reason: "not implemented" };
}
 
export function useAdFree(): boolean {
  const [adFree, setAdFree] = useState(false);
  const ctl = useRef<AdFreeController | null>(null);
 
  useEffect(() => {
    let alive = true;
    (async () => {
      const saved = (await AsyncStorage.getItem(KEY)) === "1";
      if (!alive) return;
      setAdFree(saved);
      ctl.current = new AdFreeController(
        { subscription: querySubscription, oneTime: queryOneTime },
        saved,
        (v) => {
          setAdFree(v);
          AsyncStorage.setItem(KEY, v ? "1" : "0").catch(() => {});
        },
      );
      await ctl.current.refresh();
    })();
    const sub = AppState.addEventListener("change", (s) => {
      if (s === "active") ctl.current?.refresh();
    });
    return () => {
      alive = false;
      sub.remove();
    };
  }, []);
 
  return adFree;
}

What does it solve? It stores the last value on the device and uses it as the initial value at launch. When both queries are in, it replaces it. Until then, someone whose last value was true sees no ads, and someone whose last value was false does. The previous value decides how the app looks while it waits.

When the ad layer reads this value is another matter. The order of startup and ad initialization is covered in Initializing Ads Before Restoring Purchases Flashed an Ad at a Paying User: Startup Ordering in a Rork (Expo) App.

Four places to trip

1. Do not give "none" and "could not ask" the same value. Folding false, undefined, and an exception into a single false turns a flaky connection straight into a billing-state change. Give failure its own place in the result type.

2. Write the returning-direction test first. Alongside "buying removes ads", write "expiry brings ads back" with equal weight. The broken version failed only in case A.

3. Keep grace periods and holds out of this component. How to treat a payment grace period or an account hold is a separate design. For the story of cutting access because a cancellation was assumed, see The User I Cut Off as Cancelled Still Meant to Pay: Payment Grace Periods and Keeping Entitlements. This component handles only the merging of what it asked.

4. OR a time-limited ad pause on separately. If a rewarded ad pauses ads for a while, keep that as its own state and combine it with OR at the end. Mixed into the purchase decision, you can no longer tell which reason made it true when it expires.

What to do first tomorrow

In your own app, find the place where the ad-free value goes back to false when no purchase is confirmed. If you cannot find it, you may be in the state I was in.

If you do find it, check once whether that branch reads a confirmed fact or the flag's own current value. Then replace the six-row table above with your own two sources and fill it in.

When a question could not be answered, do not invent the answer. I try to keep to that line even on days with a bad connection, and even on days when I would like the ads back.

What I ran here is the TypeScript component rebuilt from the idea and its automated tests, and nothing more. I have not included device behavior in the original Android app or a check against StoreKit on the iOS side.