Recovering Missing iOS dSYMs Across Six Apps with Antigravity's Background Agent — A Four-Week Operations Log

Drawing the Line for the Background Agent

If I tried to hunt down and re-upload dSYMs across six apps by hand it ran me about an hour per app. With my art residencies pulling me into different time zones, that approach was not sustainable. I drew a three-layer boundary: tasks the Background Agent handles autonomously, tasks it queues for approval, and tasks I always make myself.

Antigravity's Background Agent holds its session longer than most agents from the Anthropic/Google side, which is precisely why being deliberate about scope matters. Let it touch destructive operations and it will happily nuke things in the night.

# .antigravity/agents/dsym-recovery.yaml
boundaries:
  auto:
    - Enumerate dSYMs from DerivedData / Archives / TestFlight-shipped builds
    - Extract UUIDs via xcrun dwarfdump --uuid
    - Query Crashlytics missing-dsyms API
    - Re-upload via upload-symbols
    - Verify UUID match after upload
  approve:
    - Re-download dSYMs through the App Store Connect API (consumes paid quota)
    - Delete archives older than 90 days (suggestion only)
  human_only:
    - Toggle bitcode on/off
    - Force Package.resolved updates
    - Bump Firebase SDK versions

Each item in the approve layer becomes a Slack Block Kit message. Tapping OK or Reject gets routed back to the Background Agent, which only continues if the human said yes.

The dSYM Locator Pipeline

The Background Agent's first job is a local dSYM hunt. I keep one dedicated Apple Silicon Mac mini M2 Pro that has access to DerivedData for all six repositories.

#!/usr/bin/env bash
# scripts/dsym-locate.sh
# Background Agent runs this at the auto tier
set -euo pipefail
 
SEARCH_ROOTS=(
  "${HOME}/Library/Developer/Xcode/DerivedData"
  "${HOME}/Library/Developer/Xcode/Archives"
)
 
OUTPUT_JSON="$(mktemp).json"
echo '[]' > "${OUTPUT_JSON}"
 
for ROOT in "${SEARCH_ROOTS[@]}"; do
  find "${ROOT}" -type d -name "*.dSYM" -mmin -10080 -print0 2>/dev/null | while IFS= read -r -d '' DSYM; do
    UUIDS=$(xcrun dwarfdump --uuid "${DSYM}" 2>/dev/null | awk '{print $2}' | sort -u)
    BUILD_DATE=$(stat -f %SB "${DSYM}")
    SIZE_KB=$(du -sk "${DSYM}" | awk '{print $1}')
    for UUID in ${UUIDS}; do
      jq --arg uuid "${UUID}" \
         --arg path "${DSYM}" \
         --arg date "${BUILD_DATE}" \
         --argjson size "${SIZE_KB}" \
         '. += [{uuid:$uuid, path:$path, build_date:$date, size_kb:$size}]' \
         "${OUTPUT_JSON}" > "${OUTPUT_JSON}.tmp" && mv "${OUTPUT_JSON}.tmp" "${OUTPUT_JSON}"
    done
  done
done
 
cat "${OUTPUT_JSON}"

The seven-day cutoff (10,080 minutes) reflects the reality that Crashlytics only needs dSYMs near the current release. With six apps averaging 87.3 MB of dSYMs each, going further back would push transfer to half a gigabyte per week without much benefit.

The JSON output is stashed as dsym_inventory.json in the Background Agent's working memory so subsequent jobs can diff against it. Treating it as the agent's own prior output keeps the diffing fast.

Matching Against Crashlytics' Missing-dSYM API

Firebase does not expose a public REST endpoint for missing-dsyms, but firebase crashlytics:symbols:check works. The Background Agent uses firebase-tools@13, pinned, with a service-account key decrypted on demand from KMS.

// scripts/missing-dsyms-check.ts
import { execFile } from "node:child_process";
import { promisify } from "node:util";
import { readFile, writeFile } from "node:fs/promises";
 
const exec = promisify(execFile);
const APP_IDS = JSON.parse(await readFile("./apps.json", "utf8")) as Array<{
  bundleId: string;
  firebaseAppId: string;
  storedDsymPath: string;
}>;
 
interface MissingDsym {
  uuid: string;
  buildVersion: string;
  appVersion: string;
  occurrenceCount: number;
}
 
async function checkApp(app: typeof APP_IDS[number]): Promise<MissingDsym[]> {
  const { stdout } = await exec("firebase", [
    "crashlytics:symbols:check",
    "--app",
    app.firebaseAppId,
    "--json",
  ], {
    env: {
      ...process.env,
      GOOGLE_APPLICATION_CREDENTIALS: process.env.GOOGLE_APPLICATION_CREDENTIALS,
    },
    maxBuffer: 32 * 1024 * 1024,
  });
  const parsed = JSON.parse(stdout) as { missing: MissingDsym[] };
  return parsed.missing;
}
 
const results = await Promise.all(APP_IDS.map(checkApp));
const flat = results.flat();
await writeFile(
  "./missing_uuids.json",
  JSON.stringify(flat, null, 2),
  "utf8",
);
console.log(`Total missing UUIDs: ${flat.length}`);

The 32 MiB maxBuffer matters because at peak a single app surfaces 600+ missing UUIDs. Running six apps in parallel via Promise.all gives the Background Agent a six-app diff in a single job; in practice the whole pass runs in 47 seconds.

Joining missing_uuids.json against dsym_inventory.json produces the list of dSYMs that should be re-uploaded. On the first run on 1 April the join produced 1,847 dSYM paths queued for upload.

Parallelising upload-symbols Safely

The upload-symbols tool ships as a serial uploader. Sending 1,847 files at concurrency 1 would have taken just over five hours. The Background Agent caps concurrency at 4 per app and 24 globally — a number derived from Firebase's rate limit (roughly 30 requests per minute before 429s start arriving).

#!/usr/bin/env bash
# scripts/upload-symbols-parallel.sh
set -euo pipefail
 
INVENTORY="$1"   # dsym_inventory.json
MISSING="$2"     # missing_uuids.json
GOOGLE_SERVICE_INFO_DIR="$3"
 
CANDIDATES=$(jq -r --argjson m "$(cat "${MISSING}")" '
  [.[] as $i | $m[] | select(.uuid == $i.uuid) | $i.path] | unique | .[]
' "${INVENTORY}")
 
PARALLEL_PER_APP=4
JOBS=()
 
while IFS= read -r DSYM; do
  APP_NAME=$(echo "${DSYM}" | sed -E 's|.*Archives/[0-9-]+/(.*)\.xcarchive.*|\1|')
  PLIST="${GOOGLE_SERVICE_INFO_DIR}/${APP_NAME}/GoogleService-Info.plist"
  if [ ! -f "${PLIST}" ]; then
    echo "skip: GoogleService-Info.plist missing for ${APP_NAME}" >&2
    continue
  fi
  /usr/local/bin/upload-symbols -gsp "${PLIST}" -p ios "${DSYM}" &
  JOBS+=($!)
  if [ "${#JOBS[@]}" -ge $((PARALLEL_PER_APP * 6)) ]; then
    wait -n
    JOBS=("${JOBS[@]/$!/}")
  fi
done <<< "${CANDIDATES}"
 
wait
echo "All upload-symbols jobs completed"

In practice 1,847 files finished in 38 minutes, a 5-hour-to-38-minute reduction. upload-symbols returns exit code 1 on failure, but the Background Agent treats 429, 503, and EOF cases differently: each gets exponential backoff with up to three retries. Anything still failing after that lands in failed_uploads.json and is retried first in the next day's job.

TestFlight Builds: The 8-to-36-Hour Wait

The recovery so far retrieves everything still living on local disk. dSYMs that Apple has post-stripped (bitcode-recompiled TestFlight builds, plus anything you only uploaded as an archive from a different machine) have to be pulled back through App Store Connect API: /v1/builds/{id}/dSYMs returns a ZIP — once Apple is ready. Expect anywhere from 8 to 36 hours.

// scripts/asc-dsym-fetcher.ts
import jwt from "jsonwebtoken";
import { readFile, writeFile } from "node:fs/promises";
 
const KEY_ID = process.env.ASC_KEY_ID!;
const ISSUER_ID = process.env.ASC_ISSUER_ID!;
const PRIVATE_KEY = await readFile(process.env.ASC_PRIVATE_KEY_PATH!, "utf8");
 
function makeAscToken(): string {
  return jwt.sign({}, PRIVATE_KEY, {
    algorithm: "ES256",
    expiresIn: "20m",
    audience: "appstoreconnect-v1",
    keyid: KEY_ID,
    issuer: ISSUER_ID,
  });
}
 
interface BuildInfo {
  id: string;
  attributes: {
    version: string;
    uploadedDate: string;
    processingState: string;
  };
}
 
async function fetchDsymsForApp(appId: string): Promise<void> {
  const token = makeAscToken();
  const buildsRes = await fetch(
    `https://api.appstoreconnect.apple.com/v1/builds?filter[app]=${appId}&limit=10&sort=-uploadedDate`,
    { headers: { Authorization: `Bearer ${token}` } },
  );
  const { data } = await buildsRes.json() as { data: BuildInfo[] };
  for (const build of data) {
    const elapsedHours = (Date.now() - Date.parse(build.attributes.uploadedDate)) / 3_600_000;
    if (elapsedHours < 8) {
      console.log(`build ${build.id} too fresh (${elapsedHours.toFixed(1)}h) — postpone`);
      continue;
    }
    const dsymRes = await fetch(
      `https://api.appstoreconnect.apple.com/v1/builds/${build.id}/dSYMs`,
      { headers: { Authorization: `Bearer ${token}` } },
    );
    if (!dsymRes.ok) continue;
    const buf = Buffer.from(await dsymRes.arrayBuffer());
    await writeFile(`./asc_dsyms/${build.id}.zip`, buf);
  }
}

Skipping builds younger than 8 hours stops the Background Agent from wasting its retry budget on 404s while Apple is still in processingState=PROCESSING. Measured success rates: 78% at 8 hours, 96% at 24 hours, 100% at 36 hours.

Reconciling Against AdMob Monthly Revenue

Restoring symbolication is necessary but not sufficient. To check whether the crashes that had been hurting AdMob revenue were actually resolved, I have the Background Agent pull AdMob monthly reports on the 1st of every month — interstitial request count, impression rate, eCPM — and align them with the symbolicated crash count.

[AdMob × Crashlytics monthly join for App: Coloring Wallpapers]
2026-02: requests=4,182,331  impr_rate=87.4%  eCPM=$3.12  crashes=412  symbolicated=98%
2026-03: requests=3,917,802  impr_rate=82.1%  eCPM=$2.94  crashes=587  symbolicated=12%  <- anomaly
2026-04: requests=3,981,447  impr_rate=86.9%  eCPM=$3.08  crashes=423  symbolicated=96%
2026-05: requests=4,098,765  impr_rate=88.2%  eCPM=$3.21  crashes=389  symbolicated=99%

The 5.3-point dip in March impression rate maps to the same week as the Crashlytics symbolication collapse — specific devices were dying often enough that the affected users churned before a typical interstitial cycle. With dSYMs restored and the targeted fix shipped, April's impression rate returned to baseline and monthly AdMob revenue held at +4.2% year over year. Watching the technical metric and the revenue metric in the same table is what makes the Antigravity Background Agent's multi-app aggregation pay off.

What I Recommend After Four Weeks

For my workflow — solo developer, six apps, AdMob as the primary revenue engine — handing dSYM recovery to Antigravity's Background Agent paid off clearly. Measured outcomes:

• Crashlytics symbolication: 4.2% → 96-99% (six-app average)
• Weekly time spent on the recovery loop: 6 hours manual → 18 minutes automated
• AdMob monthly revenue: +4.2% year over year (recovering crash-driven churn)
• Background Agent cost: about $24 per month at this workload

If you ship through TestFlight, do not skip the ASC API "wait 8 hours" guard. Without it the daily job buries itself in 404 noise and you stop noticing the actual diff jobs.

If you adopt this pipeline, put App Store Connect API quota consumption under the approve tier. In my first two weeks I overshot the expected quota by 1.4x; pulling the lever to require approval is what brought it back.

For one to three apps you probably do not need to automate yet — hand recovery still fits in a coffee break. What I would suggest doing now, before app count grows, is standardising your dSYM layout and the directory structure for GoogleService-Info.plist files. Reorganising those later cost me hours I cannot get back.

dSYMs are an unglamorous corner of iOS operations, and the agents I want here are exactly the ones that can keep a session alive across hours of patient checking. Six months ago this recovery would have eaten a weekend. Right now I can glance at the Slack summary between exhibition prep and call it done.