Rolling Out Firebase App Check in Rork Without Breaking AdMob or Crashlytics

Initializing DeviceCheck and Play Integrity from a Rork app

Here is the minimum I drop into a Rork project right after expo prebuild. It lives at the JS entry point, runs immediately after Firebase initialization, and never blocks app startup if it fails.

// app/_layout.tsx, very early in the boot
import firebase from '@react-native-firebase/app';
import appCheck from '@react-native-firebase/app-check';
 
async function initAppCheck() {
  const provider = appCheck().newReactNativeFirebaseAppCheckProvider();
 
  provider.configure({
    apple: {
      // Production App Store: App Attest with DeviceCheck fallback
      // TestFlight or dev builds: debug provider
      provider: __DEV__ ? 'debug' : 'appAttestWithDeviceCheckFallback',
      debugToken: process.env.EXPO_PUBLIC_APP_CHECK_DEBUG_TOKEN,
    },
    android: {
      // Production Play Store: Play Integrity
      // Internal testing: debug provider
      provider: __DEV__ ? 'debug' : 'playIntegrity',
      debugToken: process.env.EXPO_PUBLIC_APP_CHECK_DEBUG_TOKEN,
    },
    web: { provider: 'debug', siteKey: '' },
  });
 
  await appCheck().initializeAppCheck({
    provider,
    isTokenAutoRefreshEnabled: true,
  });
}
 
initAppCheck().catch((e) => {
  // Never block app startup on App Check failure
  console.warn('[AppCheck] init failed', e);
});

The .catch instead of an await inside the boot path is deliberate. The worst experience an indie app can ship is a splash screen that freezes during App Check initialization. After a couple of incidents in production, the rule that settled in was: if App Check init fails, continue silently, and let Remote Config decide whether the rest of the app switches into a degraded mode.

Debug tokens go in via environment variables, registered both in EAS Secrets and GitHub Actions, so they are injected at build time only. This is the cheapest way to prevent a forgotten debug provider from shipping into a production binary.

Absorbing the first few seconds after install

On iOS, the App Attest attestation key is generated on the device the first time a freshly installed app launches. Until that generation completes, getToken() keeps failing. isTokenAutoRefreshEnabled: true does not save you here, because the retry cadence is left to the SDK's own backoff — so if your boot path attaches a Realtime Database listener before the first token exists, that particular connection is rejected with a 401.

What makes this failure mode nasty is that it only affects newly installed devices. It never reproduces on your own phone, because your device already holds a provisioned attestation key. The bug ships invisibly, and the only sessions that quietly go missing are the ones from users opening your app for the very first time.

The fix is a small gate in front of Firebase-dependent initialization — one that refuses to wait forever and falls through to a degraded mode instead.

// lib/appCheckGate.ts
import appCheck from '@react-native-firebase/app-check';
 
const MAX_WAIT_MS = 4000;
const BACKOFF_MS = [200, 400, 800, 1600];
 
export async function waitForAppCheckToken(): Promise<string | null> {
  const startedAt = Date.now();
 
  for (const delay of BACKOFF_MS) {
    if (Date.now() - startedAt > MAX_WAIT_MS) break;
    try {
      // forceRefresh: false — returns a cached token without a network round trip
      const { token } = await appCheck().getToken(false);
      if (token) return token;
    } catch {
      // Attestation key is still being provisioned; back off and retry.
    }
    await new Promise((resolve) => setTimeout(resolve, delay));
  }
 
  return null; // Continue in degraded mode.
}

forceRefresh stays false on purpose. From the second launch onward the cached token comes back immediately, so the gate costs nothing. Setting it to true would tax every launch for every user with a network round trip, just to solve a problem that only exists on first install.

The 4-second ceiling is derived from how long a splash screen can reasonably stay up, not from any property of App Attest. Tune it to your own startup experience — but keep the invariant that the gate always exits before the user starts wondering whether the app is stuck.

Decide up front what degraded mode actually does:

The part people forget is the reconnect. Even after waitForAppCheckToken() returns null, retry appCheck().getToken(false) once in the background and re-attach the Realtime Database connection if it succeeds. Before I added that retry, first-install users had to kill and reopen the app before anything synced. It is a small slice of the userbase — and it is precisely the slice forming its first impression of the product.

A four-stage rollout driven by Remote Config

Firebase App Check enforcement is binary on the server side: unenforced or enforced. The way I get a staged rollout is by adding a percentage gate on the client side using Remote Config, then flipping the server enforcement only after the client cohort is fully in.

The four stages I run through:

Stage 0 — appCheckMode = "monitor". Clients fetch and send App Check tokens. The server side is still unenforced. The goal is one full week of looking at the Firebase console's "Request metrics" panel to see what percentage of your own legitimate traffic is showing up as unverified.

Stage 1 — appCheckMode = "enforce" plus appCheckRolloutPercent = 10. Clients hash their user id and only the bottom 10% of buckets actually route Crashlytics and Realtime Database through the App Check path. The rest of the userbase is unchanged.

Stage 2 — appCheckRolloutPercent = 50. At this point you can compare crash-free sessions, Crashlytics report volume, and Realtime Database event throughput between the enforced and non-enforced halves. If anything diverges, the enforcement path is rejecting legitimate traffic.

Stage 3 — appCheckRolloutPercent = 100. Then, and only then, flip the Firebase console enforcement to "enforced."

The bucketing on the client looks like this. A stable hash of the user id keeps individual users on the same side of the rollout boundary as you raise the percentage, which is essential for valid A/B observation.

import remoteConfig from '@react-native-firebase/remote-config';
import auth from '@react-native-firebase/auth';
import sha256 from 'crypto-js/sha256';
 
export function isAppCheckEnforced(): boolean {
  const mode = remoteConfig().getString('appCheckMode'); // off | monitor | enforce
  if (mode !== 'enforce') return false;
 
  const percent = remoteConfig().getNumber('appCheckRolloutPercent');
  if (percent <= 0) return false;
  if (percent >= 100) return true;
 
  const uid = auth().currentUser?.uid ?? 'anonymous';
  const bucket = parseInt(sha256(uid).toString().slice(-2), 16) % 100;
  return bucket < percent;
}

I reach for the same hash-bucket primitive for every ad-related rollout I run. It is the cheapest stable bucketing I have found that does not require any server-side state. The literal 'anonymous' fallback keeps signed-out users in a deterministic bucket; whether to include them at all is governed by a separate Remote Config flag, because some apps want anonymous traffic excluded from sensitive enforcement during the rollout window.

The order in which you enforce Firebase products matters

Among the Firebase products you can put behind App Check, two of them — Crashlytics and Realtime Database — are by far the most dangerous to enforce first, because their failure mode is invisible. The order I recommend is:

Authentication and Cloud Functions go first. Failures here surface as user-facing errors and in server logs almost immediately, which gives you a fast feedback loop.

Cloud Storage goes second. For image-heavy apps the visible impact is large, but precisely because it is visible — broken thumbnails — you discover the problem quickly.

Realtime Database and Crashlytics go last. These are the silent ones. When Realtime Database stops accepting listeners, your UI may look perfectly normal but stop updating live. When Crashlytics stops accepting reports, your crash-free number actually looks better than it is.

Before flipping enforcement on the last two, I let monitor mode run until the Firebase "App Check → Request metrics" panel shows the unverified rate below 1% of your own legitimate traffic. Then I move through the percentage rollout one notch per day, comparing Crashlytics report arrival counts to the previous day. If reports drop more than 20% day over day with no change in active sessions, I treat that as a positive signal that something legitimate is being rejected, and roll back.

A three-minute rollback path with a single flag

If something does break, rolling back at the Firebase console takes a few minutes to propagate. Rolling back via a client-side Remote Config flag is much faster because clients can fetch and apply it on their next interval, which in my apps I keep at 60 seconds during incidents.

The three flags I always keep ready:

• appCheckMode — one of off, monitor, enforce.
• appCheckRolloutPercent — integer 0 through 100.
• appCheckEmergencyDisable — boolean. When true, ignore the other flags and bypass App Check entirely.

In an emergency, set appCheckEmergencyDisable = true first. That flag is wired into the gating function so that within the next Remote Config fetch interval, every active client stops routing requests through the App Check verification path. Then return the Firebase console to "unenforced," and as a belt-and-braces measure, enable a 24-hour bypass route in Cloud Functions that accepts requests without a valid App Check header.

The Cloud Functions side of that looks like this. Most of the year APP_CHECK_EMERGENCY_BYPASS is false, and the bypass branch is dead code. Having it pre-wired turns a midnight outage from "scary judgement call" into "set one env var and redeploy."

// functions/src/utils/appCheck.ts
import { Request } from 'firebase-functions/v2/https';
import { getAppCheck } from 'firebase-admin/app-check';
 
export async function verifyAppCheckOrFallback(req: Request) {
  const emergency = process.env.APP_CHECK_EMERGENCY_BYPASS === 'true';
  if (emergency) return { verified: false, bypassed: true };
 
  const token = req.header('X-Firebase-AppCheck');
  if (!token) return { verified: false, bypassed: false };
 
  try {
    const decoded = await getAppCheck().verifyToken(token);
    return { verified: true, decoded };
  } catch (e) {
    return { verified: false, bypassed: false, error: e };
  }
}

gcloud functions deploy --set-env-vars APP_CHECK_EMERGENCY_BYPASS=true and you are back in production while you investigate. The difference between having and not having this rail is, in my experience, the difference between a 30-minute incident and a 3-hour one.

What App Check actually does to AdMob revenue

This question comes up constantly in indie developer Discords. Some measurements from my own catalogue, which I think travel reasonably well to other AdMob-funded indie apps.

Across the four titles where I can measure eCPM cleanly, enforcing App Check did not move eCPM in either direction in a way I could distinguish from normal weekly noise. AdMob's invalid traffic filtering and click-quality systems appear to operate independently of App Check. What I did see, gradually over the following month, was a small decline in the "invalid traffic" share reported by AdMob — possibly because the denominator shrank, possibly because the AdMob trust score moved. Either way, payout stability got measurably better.

In the opposite direction, the AdMob SDK itself does not consume App Check, so enforcing Realtime Database or Crashlytics does not change AdMob fill rates. A common misconception is that App Check will somehow stop AdMob from serving ads — that is not how it works. AdMob behavior is essentially orthogonal to App Check enforcement.

The practical recommendation, from someone whose entire indie business runs on AdMob, is that the more central AdMob is to your revenue, the sooner you want App Check in. Combined with Play Integrity, it reduces the chance of policy-violation reports and stabilizes payouts in a way that compounds over months.

Where each rejection shows up — and where it doesn't

Staging the rollout only helps if you know where to look for rejections. The awkward part is that App Check rejections surface in a different place for each Firebase product — and for one of them, nowhere at all. Here is what I found by checking them one at a time against my own apps.

The bottom two rows cannot be caught by hunting for rejection logs. That Monday morning I described at the top was exactly this: I was looking for something that had failed, and the place I was looking had itself gone quiet.

You cannot count rejections. You can only count arrivals. For as long as I had that backwards, none of my alerts ever fired.

So alongside the real request paths, I keep one callable whose whole job is to report the verification result instead of acting on it. Leave enforceAppCheck as false on that one function and log whether request.app was populated — the outcome lands in your logs as data rather than as a failure.

// functions/src/appCheckHeartbeat.ts
import { onCall } from 'firebase-functions/v2/https';
import { logger } from 'firebase-functions';
 
export const appCheckHeartbeat = onCall(
  // This path exists to count arrivals, so it must never reject
  { enforceAppCheck: false },
  async (request) => {
    logger.info('app_check_heartbeat', {
      // request.app is only populated when the App Check token verified
      verified: request.app !== undefined,
      enforced: request.data?.enforced === true,
      version: request.data?.version ?? 'unknown',
    });
    return { ok: true };
  },
);

The client calls it once per session and swallows the result. Failure to arrive is the signal, so nothing here may throw.

// lib/appCheckHeartbeat.ts
import functions from '@react-native-firebase/functions';
import { nativeApplicationVersion, nativeBuildVersion } from 'expo-application';
import { isAppCheckEnforced } from './appCheckGate';
 
let sentThisSession = false;
 
export async function sendAppCheckHeartbeat() {
  if (sentThisSession) return;
  sentThisSession = true;
 
  try {
    await functions().httpsCallable('appCheckHeartbeat')({
      enforced: isAppCheckEnforced(),
      version: `${nativeApplicationVersion}(${nativeBuildVersion})`,
    });
  } catch {
    // Not arriving is the measurement. Nothing to do here.
  }
}

In the morning, this is the only query I run. Unverified sessions come back broken down by app version.

gcloud logging read \
  'jsonPayload.message="app_check_heartbeat" AND jsonPayload.verified=false' \
  --project "$FIREBASE_PROJECT_ID" --freshness=24h \
  --format='value(jsonPayload.version)' \
  | sort | uniq -c | sort -rn

If old build numbers sit at the top of that list, the cause is not your enforcement — it is those versions still being out in the wild. If the newest build is at the top, suspect a forgotten debug provider or the first-launch attestation window instead. The App Check console cannot split unverified requests by app version, and this heartbeat log has been the only practical way I have found to do it.

The cost is honest enough: one extra callable per session. I run it for everyone during the two weeks of a rollout, then dial it down to about 10% with a Remote Config percentage once things settle. Every real request path stays at enforceAppCheck: true. This single function is the only thing I loosen.

What to watch in the first week after 100%

When appCheckRolloutPercent = 100 and the Firebase console is set to enforced, here is the metric set I check every morning for seven days.

Daily crash-free sessions in Crashlytics, compared to the prior week. Anything more than a 0.05 percentage point drop is worth investigating, because App Check rejecting Crashlytics traffic will raise the number while hiding real crashes.

Remote Config fetchAndActivate success rate. If the 200-response ratio for the Remote Config fetch endpoint dips below 99%, you are seeing App Check rejecting your own Remote Config traffic, which is recursively bad because Remote Config is your rollback channel.

The AdMob ad_request → impression ratio. App Check should not move this directly, but if your ad routing depends on Realtime Database flags and Realtime Database is being rejected, fill rate will quietly slip.

The "unverified requests" count in the App Check console itself. If this is still non-zero after a full 100% rollout, the most likely culprits are forgotten debug providers on staff devices, or older app versions still in the wild. Which of the two it is comes straight out of the heartbeat log from the previous section, so that is the first thing I open. Older versions need a forced upgrade strategy of their own, but in the meantime a Remote Config flag like appCheckMinVersion lets you scope enforcement only to clients above a given build number.

If I keep those four numbers on a single spreadsheet and look at them for seven minutes each morning, App Check stops being scary and becomes routine. If I skip that habit and just leave enforcement on, I end up on the wrong side of a Monday morning where Crashlytics is "wonderfully quiet."

Done right, App Check pays off twice — once in more stable AdMob payouts, once in lower Firebase backend abuse. Hope this saves someone a 3am incident.