Fullscreen Ads Stopped Showing After Going Back and Forth Between Screens — The Ad Holder Was Still Holding a Closed Screen

Reproduce the broken shape first

Before fixing anything, reproduce the broken form as it was. This is a re-creation of the idea, not a quote of the original code. In place of the ad SDK I made a stand-in that has only one property of the real thing: events arrive later.

// fake-ad.ts — 全画面広告 SDK の代役。「イベントを後から受け取る」性質だけを再現する
export type AdEvent = "loaded" | "closed";
type Listener = () => void;
 
export class FakeInterstitial {
  private listeners: Record<AdEvent, Set<Listener>> = {
    loaded: new Set(),
    closed: new Set(),
  };
  loadCalls = 0;
  showCalls = 0;
 
  addListener(event: AdEvent, cb: Listener): () => void {
    this.listeners[event].add(cb);
    return () => this.listeners[event].delete(cb);
  }
  load(): void {
    this.loadCalls += 1;
  }
  show(): void {
    this.showCalls += 1;
  }
  // テストから「SDK がイベントを返した」ことにするための入口
  emit(event: AdEvent): void {
    for (const cb of [...this.listeners[event]]) cb();
  }
}

The screen stand-in has a counter for notifications that arrive after it has closed.

// screen.ts — 画面の代役。閉じた(alive=false)画面に届いた通知を数える
export interface Host {
  name: string;
  onReady(): void;
  onClosed(): void;
}
 
export class FakeScreen implements Host {
  alive = true;
  ready = false;
  deadDeliveries = 0; // 閉じたあとに届いた通知の数
 
  name: string;
  constructor(name: string) {
    this.name = name;
  }
 
  onReady(): void {
    if (!this.alive) return void (this.deadDeliveries += 1);
    this.ready = true;
  }
  onClosed(): void {
    if (!this.alive) return void (this.deadDeliveries += 1);
    this.ready = false;
  }
  unmount(): void {
    this.alive = false;
  }
}

Here is the broken holder. Not recreating the object is right, but it pins the notification target to whichever screen called first.

// holder-buggy.ts — 壊れていた形。「作り直さない」は正しいが、通知先を最初の画面に固定している
import { FakeInterstitial } from "./fake-ad.ts";
import type { Host } from "./screen.ts";
 
let ad: FakeInterstitial | null = null;
 
export function getAd(host: Host): FakeInterstitial {
  if (ad) return ad; // 2回目以降は、作り直さずに同じものを返す
  const created = new FakeInterstitial();
  created.addListener("loaded", () => host.onReady()); // host は最初の画面のまま固定される
  created.addListener("closed", () => {
    host.onClosed();
    created.load();
  });
  created.load();
  ad = created;
  return created;
}

I ran a scenario that opens and closes five screens in order (demo.ts) and looked at whether each new screen reached the "ready to show" state.

壊れた形 1回目 ready=true
壊れた形 2回目 ready=false
壊れた形 3回目 ready=false
壊れた形 4回目 ready=false
壊れた形 5回目 ready=false
直した形 1回目 ready=true
直した形 2回目 ready=true
直した形 3回目 ready=true
直した形 4回目 ready=true
直した形 5回目 ready=true
壊れた形: 5回中 1 回表示 / 閉じた画面に届いた通知 4 件
直した形: 5回中 5 回表示 / 閉じた画面に届いた通知 0 件

With the broken holder, only the first of five screens could show an ad. The four "loaded" notifications for screens 2 through 5 all went to the closed first screen. Not one screen crashed. A wrong destination for one notification is enough to stop ads completely.

The fix: don't recreate the ad, swap only the listener target

Here is the fixed holder. Three things changed.

// holder-fixed.ts — 直した形。広告は作り直さず、通知先だけを最新に差し替える
import { FakeInterstitial } from "./fake-ad.ts";
import type { Host } from "./screen.ts";
 
let ad: FakeInterstitial | null = null;
let host: Host | null = null; // 今の通知先（いなければ null）
let ready = false;            // 広告の状態は、画面ではなく部品が持つ
 
function ensureAd(): FakeInterstitial {
  if (ad) return ad;
  const created = new FakeInterstitial();
  created.addListener("loaded", () => {
    ready = true;
    host?.onReady();
  });
  created.addListener("closed", () => {
    ready = false;
    host?.onClosed();
    created.load();
  });
  created.load();
  ad = created;
  return created;
}
 
export function attach(next: Host): void {
  ensureAd();
  host = next;
  if (ready) next.onReady(); // すでに読み込み済みなら、新しい画面にもすぐ伝える
}
 
export function detach(prev: Host): void {
  if (host === prev) host = null; // 自分が今の通知先のときだけ外す
}
 
export function show(): boolean {
  if (!ready || !ad) return false;
  ad.show();
  return true;
}

First, whether the ad is loaded is now held by the holder, not by a screen. When screens change, the state stays with the holder.

Second, attach tells the new screen immediately if an ad is already loaded. Without that, a screen opened after loading finished would stay on "preparing" until the next notification.

Third, detach only detaches when the caller is the current target. This was the most surprising part, and the next section covers it.

Against intuition: an old screen's cleanup can wipe out the new screen's connection

Detach when the screen closes. Written naively, detach just empties the target. But during a screen transition, the new screen's attach can run first and the old screen's detach can arrive afterward. The order can differ by library and version, so the safe move is to make it work in either order. With the new screen first, an unconditional detach erases the new screen's connection too.

I tried both versions on the same sequences.

// For comparison: detach without a condition
export function detachUnconditional(): void {
  host = null;
}

The table shows results checked by tests. In the first sequence the ad loads, but nobody is told, and again no ad appears. Adding the single condition "only if I am the current target" to detach left the target as B in either order.

One more point: in many stack-style navigators, going back does not re-run the "mounted" logic of the previous screen, because that screen was kept alive in the background. "Attach on mount, detach on unmount" therefore leaves the returning screen disconnected. You need to connect only while the screen is visible.

Hooking it up to Expo Router

On the screen side, connect only while visible. I used Expo Router's useFocusEffect.

import { useCallback, useState } from "react";
import { useFocusEffect } from "expo-router";
import { attach, detach, show } from "./holder-fixed";
 
export function useInterstitial() {
  const [ready, setReady] = useState(false);
 
  useFocusEffect(
    useCallback(() => {
      const host = {
        name: "screen",
        onReady: () => setReady(true),
        onClosed: () => setReady(false),
      };
      attach(host);
      return () => detach(host); // only detaches if it is still the same host
    }, [])
  );
 
  return { ready, show };
}

I have not covered this glue with automated tests the way I did the holder. Please check it on a device by moving between screens several times. For the doubled execution you see in development (connect, disconnect, connect), the holder itself is tested to keep its target after attach → detach → attach.

The same shape again: a static collection not emptied before rebuilding

In the native wallpaper app, a similar bug showed up in an image list. A static collection that held the list was not emptied before being rebuilt, so items piled up across restarts, and the slider's upper bound grew to four times the real item count.

I reproduced that shape too, with the item count taken from the length of a module-level array.

// catalog.ts — 一覧の件数を、モジュールが持つ配列から出している例
let items: string[] = [];
 
// 壊れた形: 読み込みのたびに足していく
export function loadCatalogBuggy(fresh: string[]): void {
  items.push(...fresh);
}
 
// 直した形: 作り直す前に、いったん空にする（まとめて置き換える）
export function loadCatalogFixed(fresh: string[]): void {
  items = [...fresh];
}
 
export function sliderMax(): number {
  return items.length;
}

Here is the result of loading a five-item list four times.

By the fourth load the maximum was 20, four times the real count of 5. Empty a static collection before you rebuild it. What makes this hard to notice is that writing "append" already assumes the list grows with every load.

Pitfalls: three places that stay broken when you think you fixed it

• What you do when show() returns false. The holder quietly returns false when no ad is ready. If the caller ignores the return value, all that remains is a button that does nothing. Give the screen a path that moves on without an ad.
• The rewarded-ad holder. It is easy to fix the fullscreen holder and leave the rewarded one as it was. This same shape came back in a rewarded holder for me. If you keep a holder, give it the same attach and detach shape.
• Other static holders. Anything placed at module level outlives its screens. The search in the next section finds them.

A first step you can take today

Count how many things in your app outlive a screen. Look for top-level let declarations and empty Map, Set, or array declarations at module level.

grep -rnE "^(export )?(let|var) |^(export )?const \w+(: [^=]+)? = (new (Map|Set)|\[\])" app src --include="*.ts" --include="*.tsx"

Among the lines that turn up, anything that holds a reference to a screen or a screen's callback is a candidate for this bug. It is not limited to ads; the same arrangement can happen with purchase state or location subscriptions.

If you also count launches, My Launch Counter Went Up by Two on Every Launch covers keeping that count in one place. For purchase state, see My Ads Never Came Back After a Subscription Expired.

One last thought. Checking where a notification is going is plain work, but it was a much shorter road than continuing to search for the cause in the ad settings. I hope it helps you narrow down the same symptom.