●2.1.301 — Adds the vim % motion, LaTeX math rendering in the VS Code panel, and a retry-watchdog limit for usage-limit waits (10/15)●2.1.299 — Conversations over 200K tokens left idle about 54 minutes get compacted; MCP allow rules now match only the server they name●SONNET 4.5 — Retires on the Claude API on 11/30, 45 days left. Migrate to Sonnet 5.5●WINDOWS — Reports say hooks break silently only on Japanese-locale Windows; check the character encoding first●FAST MODE — Opus 5.5 fast mode is out of research preview and no longer needs the beta header (10/15)●NEW — I Put a Ten-Line Promise File at the To…●2.1.301 — Adds the vim % motion, LaTeX math rendering in the VS Code panel, and a retry-watchdog limit for usage-limit waits (10/15)●2.1.299 — Conversations over 200K tokens left idle about 54 minutes get compacted; MCP allow rules now match only the server they name●SONNET 4.5 — Retires on the Claude API on 11/30, 45 days left. Migrate to Sonnet 5.5●WINDOWS — Reports say hooks break silently only on Japanese-locale Windows; check the character encoding first●FAST MODE — Opus 5.5 fast mode is out of research preview and no longer needs the beta header (10/15)●NEW — I Put a Ten-Line Promise File at the To…
Semi-Automating Firebase SDK Upgrades with Claude on Xcode — Implementation Notes from Six Indie iOS Apps
How I used Claude on Xcode integrated into Xcode 16.4 to walk six iOS apps through Firebase SDK 12 to 13 upgrades and finish the CocoaPods to Swift Package Manager migration — with the actual prompts, regression tests, and the judgment calls along the way.
Open the Project Navigator in Xcode and check Firebase's Swift Packages, and you may find updates lined up from 12.0.0 all the way to 13.2.1. Pressing "Update Package" takes a second. The work that hides behind it — Crashlytics run scripts, SwiftLint configuration, Privacy Manifest entries, the order of ATT prompts — quietly differs across each of six apps. Missing a piece tends to surface as a slow drift of overnight Crashlytics notifications. Twelve years of running iOS apps as a solo developer has taught me how easy it is to repeat that mistake.
In early 2026, I added Claude on Xcode to my main IDE and substantially restructured the way I handle Firebase upgrades. With the combination of Xcode 16.4 and the Claude on Xcode 0.4 line, I worked through six wallpaper, relaxation, and inspiration apps — the lineup I have maintained for years — and walked them all into Firebase iOS SDK 13. These are the notes from that work.
This work sits directly on top of the same indie practice I've kept since 2014, so the Firebase upgrade material in this note is rewritten in the order I actually verified it for the App Store and Google Play releases.
The First 30 Minutes That Changed How Firebase Upgrades Feel
The first project I opened with Claude on Xcode installed was Beautiful HD Wallpapers. I had already documented the CocoaPods to SPM migration for that app separately, with Firebase pinned at 12.4 at the time.
With Xcode open, I docked the Claude panel into the right sidebar and started with the following prompt.
Read the Package Dependencies of this project.
What version is firebase-ios-sdk pinned to right now,
and where in the codebase might we hit breaking changes
when moving to the latest major version?
Pay particular attention to Crashlytics, Analytics,
and anything touching AdMob.
Claude on Xcode can read Package.resolved and the project.pbxproj file as IDE context, so it correctly identified the current firebase-ios-sdk version. In the first reply, it surfaced the likely change surface around setCrashlyticsCollectionEnabled, tighter Analytics event naming lint rules, and the compatibility matrix with Google Mobile Ads SDK 12. The reply was not perfect — I still went to the Firebase release notes manually for verification — but having the order in which to read those notes already settled in 30 minutes was a noticeable improvement over working with Xcode alone.
It's important to remember that Claude on Xcode can see Xcode-internal syntax and build settings, but not external systems like the Firebase Console or App Store Connect. Drawing that role boundary early on saves you confusion later.
Installation and Initial Setup — Xcode 16.4 / Claude on Xcode 0.4 Series
Following the official setup steps verbatim leaves a few gaps when you bring Claude on Xcode into an indie project.
Register an Anthropic API key in Claude on Xcode's settings. For team development, creating a Workspace in the Claude Console and scoping permissions there is the orthodox choice. For a one-person operation like mine, I settled on a dedicated key from my personal workspace and monitor monthly spend on the Console's Usage tab
Allow the Xcode Source Editor extension. Without enabling Claude on Xcode from System Settings → Privacy & Security → Extensions → Xcode Source Editor, you won't get code completion, and Project Navigator context will be unreachable as well
Wait until indexing is done before talking to the assistant. After dropping in a heavy SPM package like firebase-ios-sdk, Xcode's indexing run can take three to five minutes. Sending a query before that completes makes Claude on Xcode reply against a stale code graph, and the confidence of its responses drops dramatically
The third point is a quiet pitfall — the build doesn't fail, so it's easy to miss. I tripped on it three times in the first two weeks. Switching to the simple rule of "wait until XCBBuildService in Activity Monitor settles down before sending a prompt" stabilized things.
Once setup is done, I open a fresh session and send the following prompt to load project context into the assistant.
Summarize the overall structure of this project.
- Target structure (Main / Extension / Widget / Watch)
- Major versions for each Package Dependency
- Build Settings values for SWIFT_VERSION,
IPHONEOS_DEPLOYMENT_TARGET, and SWIFT_STRICT_CONCURRENCY
- Names and roles of each Run Script Phase
Return this as a markdown list.
The outline is something you'll reference repeatedly, so saving the result to .claude/project-overview.md after Claude on Xcode generates it makes it easy to resume context in later sessions.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦Run Claude on Xcode in the sidebar to do the research on Firebase SDK 12 to 13 changes while you focus on build verification, and reproduce the workflow across six apps with the exact prompts shown here
✦Rebuild the Run Script phase for dSYM uploads, .gitignore entries, and xcconfig consistency that CocoaPods left behind, all regenerated by Claude on Xcode within 30 minutes per app
✦From years of indie iOS maintenance, see the explicit list of workflow steps where Claude on Xcode helps (test runners, dependency graphs) and where I deliberately keep it out (Crashlytics triage, ATT order, App Store review replies)
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
Splitting the Firebase SDK 12.x to 13.x Upgrade Between You and Claude on Xcode
This is the heart of the workflow. Across the six apps, here's the split between what I delegated to Claude on Xcode and what I deliberately kept in my own hands.
Pre-Reading (Delegated)
The first step for each app is mapping out the release notes. There's no need to scroll through the official repository's Releases tab from 12.0 to 13.2 manually; specifying the range and asking Claude on Xcode is much faster.
Summarize the breaking changes in firebase-ios-sdk between
12.0 and 13.2.1.
Prioritize changes that may affect:
- FirebaseAnalytics
- FirebaseCrashlytics
- FirebasePerformance
- FirebaseRemoteConfig
For each change, estimate the file names and line numbers
in this project that might be impacted, using the
Project Navigator information available to you.
Claude on Xcode can read symbol information directly from the IDE, so it picks out FirebaseApp.configure() in AppDelegate.swift, Analytics calls in SceneDelegate.swift, and Crashlytics custom key setups in ViewController.swift, complete with line numbers. I treat that output as a "places to check" list rather than ground truth, and paste it into _documents/firebase-13-migration.md as a verification checklist.
The Upgrade Itself (Half AI, Half Manual)
Updating Package Dependencies itself is just File → Packages → Update to Latest Package Versions. The work begins after that.
The Crashlytics Run Script phase can throw warnings under SDK 13. Specifically, when the path ${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/run isn't aligned with the xcfilelist-style Input Files and Output Files declarations, Crashlytics can fail to resolve the dSYM upload path cleanly.
I have Claude on Xcode read the current Run Script phase settings and rewrite them in the recommended SDK 13 form.
Read the command, Input Files, and Output Files of the
"Crashlytics run script" Build Phase as it stands today.
Propose a rewrite that matches Firebase iOS SDK 13.x
guidance, presented as a before/after diff.
Be careful with Output Files in particular — incorrect
entries cause the Run Script to skip on incremental
builds, so explain that part carefully.
Because Claude on Xcode can read and write the PBXShellScriptBuildPhase section in project.pbxproj directly, it returns the change as something resembling a pull request diff. I personally apply the change manually in the Xcode UI, but you can ask the claude command to apply it directly. If something goes wrong, git restore brings everything back, so letting the AI write to disk is not unreasonable when starting out.
Lock Compatibility Check (Kept Manual)
I verify the Google Mobile Ads SDK and Firebase SDK compatibility matrix by hand every time. AdMob is the revenue source that produces over 1 million yen per month for the wallpaper apps, and the mediation configuration is part of that. Relying on Claude on Xcode's response alone here makes me uncomfortable.
I deliberately open the official documentation and confirm compatibility myself. My working mental model has become: the AI is a librarian who does the pre-reading; I am the operator who carries final responsibility.
Cleaning Up the "Pods/ Residue" Quietly with Claude on Xcode
Two of the six apps were still running with CocoaPods and SPM coexisting. Moving to SDK 13 was a good moment to retire CocoaPods entirely.
After removing Pods, the residue that lingers is surprisingly varied.
The Pods/ entry in .gitignore
Podfile and Podfile.lock
xxx.xcworkspace (the workspace CocoaPods generated)
The Pods group reference in Project Navigator
xcconfig file lines that #include "Pods/Target Support Files/.../*.xcconfig"
Build Settings variables like PODS_ROOT or PODS_CONFIGURATION_BUILD_DIR
Run Script Phases starting with [CP] Check Pods Manifest.lock
Walking through these by hand, file by file, is tedious. Instead, I have Claude on Xcode sweep the whole project and produce a removal list.
I want to fully remove CocoaPods from this project.
List every file, setting, and reference that should be
removed, organized by:
1. Files on disk
2. PBXFileReference / PBXGroup entries in project.pbxproj
3. xcconfig and Build Settings variables involving
${PODS_*}
4. Run Script Phases whose name starts with [CP]
5. Pods-related entries in .gitignore
For each item, note whether removal is safe; if you
have any concerns, explain the reason.
I used the same prompt across all six apps. Each one surfaced 15 to 20 removal candidates, and roughly 90 percent were safe to remove mechanically. The remaining 10 percent — things like a GoogleService-Info.plist reference that was actually being resolved through CocoaPods' Target Support Files — needed manual judgment.
Claude on Xcode can describe Project Navigator UI operations as well, so it will tell you to do things like "right-click → Delete → Remove Reference." It's fine to follow those instructions; if anything is off, git puts it back.
Letting the AI Regenerate the dSYM Upload Run Script Phase
When you use Firebase Crashlytics through CocoaPods, the Run Script phase that calls Pods/FirebaseCrashlytics/run is generated and maintained by CocoaPods. The moment you switch to SPM, that phase disappears. dSYM uploads stop, and "Symbolicate Unavailable" crashes start piling up in Crashlytics. It's a quiet but painful problem.
Regenerating this configuration is a comfortable fit for Claude on Xcode.
This project uses Firebase Crashlytics through SPM.
Add a Run Script Phase that uploads dSYMs to Crashlytics
automatically.
Requirements:
- Add it as the last Build Phase
- Add Info.plist and the DWARF dSYM as Input Files
- Leave Output Files empty (so the phase always runs)
- Use /bin/sh as the shell
- The script body should invoke upload-symbols from the
firebase-ios-sdk SourcePackages directory
- The path to GoogleService-Info.plist is
${PROJECT_DIR}/${PROJECT_NAME}/GoogleService-Info.plist
Claude on Xcode returns a patch that adds a PBXShellScriptBuildPhase to project.pbxproj. I personally still apply it through the Xcode UI as a final check, and reconcile it against Firebase's latest official example (Apple Silicon adjustments, for instance), adjusting as needed.
I add this script to all six apps, ship a TestFlight build for each, and confirm that dSYMs arrive on the Crashlytics dashboard. Only after that confirmation do I count the SDK upgrade as complete.
Regression Testing After the SDK Upgrade — Claude on Xcode as a Test Runner
A clean build is not the same as a safe Firebase upgrade. You still want minimal automated coverage that Analytics events go through, that manual Crashlytics reports (Crashlytics.crashlytics().log / record(error:)) still fire, and that Remote Config retrieval is intact.
Claude on Xcode is well suited to running xcodebuild-based tests on your behalf.
Run the unit tests for this project.
Target: XXXTests
Simulator: iPhone 15 Pro / iOS 17.5
If anything fails, summarize the failing test name and a
hypothesis about the cause.
After sending this, Claude on Xcode generates a command like xcodebuild test -workspace ... -scheme XXXTests -destination ... in the Xcode terminal and runs it. It reads the run log, and for any failing tests it opens the relevant test case in the editor and proposes fixes.
In my own workflow, I always run three smoke tests after a Firebase upgrade.
A smoke test that verifies FirebaseApp.configure() completes without crashing
A test that fires Analytics.logEvent(_:parameters:) once and confirms no console errors
A test that calls Crashlytics.crashlytics().setCustomValue(_:forKey:) to confirm Crashlytics initialization
None of these are recommended by official Firebase documentation. They come from 12 years of operating these apps and noticing where things break each time. Asking Claude on Xcode to "add the same tests to all six apps in a consistent style" produces a test file template I can roll out across six test projects in a fraction of the manual time.
Sticking Points Observed Across the Six Apps
The six apps didn't all follow the same script. Here are the actual sticking points I observed.
Wallpaper app A had old 32-bit-era .lproj folders that interacted strangely with Firebase 13's Privacy Manifest, generating odd warnings. Asking Claude on Xcode to "tidy up the Privacy Manifest warnings" led it to surface the .lproj folder inconsistency as well, and I ended up removing those legacy localization folders.
Relaxation app B had Firebase Performance initialized not in applicationDidFinishLaunching but in a custom setupAnalytics() method on a different file. Claude on Xcode's automatic migration proposal misread the code and suggested "rewriting line 24 of AppDelegate.swift" when the actual changes needed to land elsewhere. It reinforced the rule that proposals from the AI must always be confirmed via diff.
Inspiration app C had an older AdMob Mediation Adapter that caused unexpected dependency resolution errors when combined with the new Analytics For Firebase integration. Letting Claude on Xcode look at the dependency graph surfaced the need to upgrade AdMob to 12.x first, which turned out to be correct. Combined with watching the AdMob eCPM trend through Claude in Chrome, I rolled the upgrade out over three days.
The remaining three apps were of the same family as the first one, so I asked Claude on Xcode to "summarize this app's migration as a reproducible procedure," and saved it as docs/firebase-13-migration.md. From the second app onward, I worked against that document, and each subsequent upgrade took about a third of the time of the first.
Where I Decided Not to Use Claude on Xcode
For completeness, here are the parts of the workflow where I deliberately don't bring AI in.
Triaging crashes that arrive in Crashlytics. I find it more efficient to feed stack traces to Claude in Chrome, where I can see the Firebase Console UI directly. Claude on Xcode is strong at reasoning about code inside the IDE, but not at sweeping across server-side dashboards
Deciding on staged rollout. After a TestFlight release, I watch the 24-hour crash rate and decide whether to push to production myself. The downside of a mistaken call here is too high to delegate; keeping responsibility clearly assigned tends to produce better long-term operations
Replying to App Store review rejections. This sits outside Claude on Xcode's strength. I draft these in Claude.ai instead, then rewrite the final reply by hand before sending
Writing out the "we deliberately don't use AI here" list keeps the boundary between AI delegation and personal accountability honest. For my own setup, the line I've settled on is "anything that completes inside Xcode goes to Claude on Xcode; anything that crosses environments goes to the AI native to that environment."
What I'm Tackling Next
The Firebase SDK 13 migration is done, but my use of Claude on Xcode still feels early. The next thing I want to try is delegating Swift 6 Strict Concurrency adoption to Claude on Xcode. Conformance to Sendable and the design of @MainActor boundaries mix mechanical substitution with design decisions, which makes it a good experiment for thinking about the human-AI division of labor.
If you're another solo developer maintaining multiple apps and feel a quiet dread about Firebase upgrades, I'd encourage trying just the first-day setup of Claude on Xcode. Once you've experienced 30 minutes of "an assistant living inside the IDE," you can build out from there at your own pace, deciding what to delegate and what to keep.
Thank you for reading. Firebase SDK upgrades are one of those quietly recurring chores. With an AI as a working partner, the time saved can be redirected to the next app's design. I'll keep writing similar field notes as the next upgrades come around, and I appreciate you reading along.
Share
Thank You for Reading
Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.