When you build and ship apps on your own, your day never splits cleanly into "time writing code" and "time staring at dashboards." One moment I am moving an implementation forward in Xcode; the next I am checking yesterday's eCPM in the AdMob console, replying to an App Store review, and watching ranking shifts in Search Console. That back-and-forth itself was draining more of my focus than I had realized.
Once I started using both Claude Code and Claude in Chrome, I was finally able to organize that back-and-forth around a single question: which one should own this task? Here is the line I have settled on after running it for the month of May.
I'm Masaki Hirokawa, an artist and creator. I have been developing iPhone and Android apps on my own since 2014, and the cumulative downloads have grown past 50 million. I also make visual art in parallel, so cutting down operational overhead to protect creative time is something I think about constantly.
The two tools cover different ground
The first thing I let go of was the urge to rank one above the other. I treat them as tools with different coverage. Roughly speaking, Claude Code owns "work that stays inside my Mac and my GitHub repositories," and Claude in Chrome owns "work that can only happen inside a logged-in console."
This line holds up because the overlap between the two is smaller than you might expect. Code lives as files; dashboard actions live as on-screen state. Once I started asking which form the deliverable takes, where to send each task became obvious.
What I lean on Claude Code for
Anything that completes inside the editor and the repo goes to Claude Code.
- Clearing Swift warnings and small refactors—anything that touches code directly
- Searching and replacing strings across multiple repositories at once
- Investigating the root cause of build errors and writing up reproduction steps
- Batch-processing the MDX for this blog, such as front-matter consistency checks
It shines most on cross-cutting work when I am juggling six apps at once. To apply the same SDK update across every repo, handing over the change plan and reviewing the resulting diffs beats opening each project one by one—it is faster overall, and I miss fewer things. There is a real sense of separating the time spent doing from the time spent deciding.
What I lean on Claude in Chrome for
Work that can only finish inside an authenticated console goes to Claude in Chrome.
- Drafting replies to user reviews in App Store Connect
- Checking eCPM in AdMob and drafting mediation priority reorderings
- The morning crash check in Crashlytics and mapping out the blast radius
- Watching ranking changes in Search Console
What these share is that there is no public API, or only a weak one, so reading the screen with your own eyes carries most of the weight. Just having something read the console while keeping the session alive and pulling out the numbers I need makes the daily rounds much lighter.
The gray area, and how I decide
The hard cases were tasks that straddle both tools. The classic example is "fix the crash showing up in Crashlytics." Its nature changes between the first and second half.
I let Chrome handle the front half—pulling the crash event and narrowing down the reproduction conditions—then hand the back half, the actual code fix, to Code. In practice the handoff looks like this:
# What I ask the Chrome side (read the browser console)
From Crashlytics, pull crashes that newly increased in the last 24 hours.
List the device, OS version, and the top 3 stack-trace frames as bullets.
Do not save anything or change any settings.
# Pass that result to the Code side (fix the repo)
Using the stack trace above, locate the relevant code and
propose a fix as a diff. Suggest a test to add as well.
The deciding rule that remained was simple: does the final deliverable persist as a file, or as on-screen state? File means Code; screen state means Chrome. If the form of the deliverable changes midway through a task, that is exactly the handoff point. Once I reduced it to that one question, the time I spent hesitating over which to open all but vanished.
What changed after a month
For all of May, I had the Chrome side draft my morning dashboard rounds—the four of AdMob, Crashlytics, App Store Connect, and Search Console. Rounds that used to take 30–40 minutes every morning turned into skimming the extracted numbers and only checking the spots that caught my eye, finishing in around 10 minutes.
The biggest felt change was how often I bounced between editor and browser. I did not count precisely, but the number of times I switched to the browser mid-coding because "I should really check those numbers" feels like it dropped by more than half. Keeping the implementation flow from breaking mattered even more than the minutes I saved.
There were misses, too. Once, the Chrome session had expired, the rounds stalled halfway, and I missed that morning's numbers. With a tool that assumes authentication, session expiry is something you have to plan around.
Both of my grandfathers, on my mother's and father's side, were miyadaiku—traditional shrine carpenters. From watching them work as a child, a respect for the act of working with your hands has stayed with me. That is exactly why I did not want to give everything away; I keep the final judgment and the save action in my own hands. Deciding what to delegate and what to hold onto feels, to me, like part of the craft itself.
What I want to tidy up next
Next I want to automate the handoff. Right now I copy the crash summary Chrome produces and paste it into the Code side by hand. If I can smooth that bridge one more notch, I should be able to connect morning checks to starting a fix almost without stopping.
If you, too, keep hopping between several tools, try sorting your work once by "does this persist as a file, or as on-screen state?" I think you will find the choice of which tool to reach for gets a lot lighter. Thank you for reading.