In early May I started migrating a portfolio of iOS wallpaper apps from CocoaPods to Swift Package Manager (SPM). As an indie developer, I have been shipping these apps since 2014, and the combined download count crossed 50 million some time ago. With Firebase iOS SDK quietly tightening its SPM-first stance, my own stack could no longer postpone the move.
What surprised me was not the migration itself, but the research that came before it. Each submodule (Analytics, Crashlytics, Remote Config, Cloud Messaging, the AdMob bridge) has its own SPM support timeline, minimum iOS bump, dependency graph, and the always-fun question of how Podfile.lock should be mapped over to Package.resolved. Reading scattered blog posts and GitHub Issues by hand felt inefficient, and I wondered whether I could offload some of the organising work to a tool.
So I decided to run NotebookLM and Gemini Deep Research in parallel against the same research tasks for two weeks. Both are Gemini-backed "research assistants" on paper, but their design centers are different enough that their strong scenes and weak scenes diverge quickly. Below are the patterns I observed.
The two-week ground rule: send the same question to both
To keep the comparison honest, I made one rule for the two weeks.
- Every migration question goes to both NotebookLM and Deep Research, by default.
- NotebookLM only sees primary sources I curated myself (Firebase docs as PDF, the
Package.swiftof the SDK repo, my own past notes). - Deep Research gets the same question as a free-form prompt.
- Both answers go side by side in a Google Doc, and I add a one-line judgement of my own at the bottom.
Subjective "which felt better" gets noisy, so I tracked one metric instead: whether each answer ended up in my SPM migration checklist. Across 38 research queries over the two weeks, the adoption rate was roughly 71% for NotebookLM and 53% for Deep Research. On the surface that looks like a NotebookLM landslide, but the truth is that their strong scenes were cleanly separated.
NotebookLM is strongest when working with sources you curated yourself
NotebookLM shines when you feed it primary sources and ask it to pull answers from inside that envelope. For this migration I loaded in the Firebase iOS SDK CHANGELOG.md, the Package.swift of the firebase-ios-sdk repo, and the release notes for the AdMob-Firebase bridge module.
Asked things like "from which version does Firebase Crashlytics fully support SPM?" or "where should the Performance Monitoring symbol-upload script live under SPM?", NotebookLM gave back answers that cited the exact spots in my sources. Because everything came with citations, I never had to second-guess where to look in the actual repo.
The bigger win was that I could load in my own past notes. I dropped in several PDFs of work notes I had written since 2024 about Firebase, and then asked "the pod install error I hit before — does it reproduce under SPM with the same conditions?" The answer pulled my own past workaround back into view alongside the official docs. Deep Research cannot see my private notes, so structurally NotebookLM has the edge here.
Where NotebookLM struggles is anything outside the sources you fed it. It is deliberately built not to wander, so the latest GitHub Issue discussions or undocumented edge cases will quietly fall through.
Gemini Deep Research is strongest when you need to chase what is happening outside
Deep Research filled the opposite role: it was the one that went looking outside. For example, "what was the path of changes to the AdMob mediation adapter's minimum iOS version across recent major firebase-ios-sdk releases?" is the kind of question that needs you to hop across release notes, Issues, and StackOverflow threads to land on an answer.
Deep Research walks the web on its own, builds a research plan, and hands back a citation-attached report. The same thing done by hand would take half a day; Deep Research gets to a usable draft in 20–30 minutes of generation time.
What I appreciate is that the cited links are clickable. I never adopt a Deep Research conclusion verbatim — for anything load-bearing I open the original sources and re-read them — but having a map of "where to read" already lowers the cognitive cost.
Deep Research has its own ceiling, though. It cannot ingest my private app context, so questions of the form "this is how my app is structured today; how does that change under SPM?" come back at a general level. The final judgement still has to be mine.
Comparing both tools' answers to the same concrete question
One contrast that stuck with me involved "where to place the dSYM upload script for Firebase Performance Monitoring under SPM?"
NotebookLM quoted directly from the README section I had loaded in, and returned the concrete path: place a Run Script Phase that invokes ${BUILD_DIR%/Build/*}/SourcePackages/checkouts/firebase-ios-sdk/Crashlytics/upload-symbols. Citations were attached, so I could wire it into Xcode's build phases without second-guessing.
Deep Research, asked the same question, layered together the official doc text, a StackOverflow thread from someone who hit a related issue, and a recent supplementary note from a firebase-ios-sdk Issue. It also surfaced an Apple Silicon-specific path detail that I would have missed reading only the primary source. Different angle, equally helpful.
Put another way: NotebookLM is better at organising thoroughly within a world you already know. Deep Research is better at walking the world you do not yet know. The same question yields a different angle from each.
The division of labour I landed on
After two weeks, here is the split I settled into.
- Cross-source research within material I curated (official PDFs, my past notes, repo
Package.swift) → NotebookLM. - Chasing live discussion outside the official docs (GitHub Issues, StackOverflow, recent posts) → Deep Research.
- Final design call → put both answers side by side and add a one-line judgement of my own.
Running both takes more effort, but the habit of writing one personal line per question turns the research notebook itself into a migration checklist. By the end of the migration, mine had grown to about 80 lines — none of it written by AI, all of it accumulated decisions I can defend later.
Keeping both tools around after the SPM migration
The SPM migration itself wrapped up by the second half of May, but I decided to keep this NotebookLM + Deep Research pair as a standing setup. Whenever the next Firebase iOS SDK major bump or AdMob mediation adapter rev comes, the same parallel workflow will likely earn its keep again.
Both of my grandfathers were temple carpenters, and growing up around their work left me with the instinct that "things assembled carefully tend to last." I feel the same is true of a research notebook, not just a codebase. Running NotebookLM and Deep Research in tandem turned a lot of my previously implicit Firebase knowledge into a tangible source set and a stack of reports. Next time I face a migration, I can drop my own notes back into NotebookLM and start from a slightly more advanced position.
If you are an indie developer facing a Firebase-related migration, I would recommend trying both tools in parallel against the same questions, at least once. The first few queries may look like duplicate answers, but by question four or five the division of labour between the two starts to surface on its own.