My grandfather was a master carpenter — the kind who shaped wood by hand every single day, year after year. He used to say that the tools you choose reveal how seriously you take your work.
I've been building iOS and Android apps as a solo developer since 2014. With over 50 million total downloads across my apps, I still handle everything from concept to release on my own. That means I'm deliberate about adopting new tools. Chasing every trend wastes the time I need for actual development.
That said, Gemini CLI caught my attention enough to run a structured, one-week experiment — integrating it into my iOS development workflow and observing what worked, what didn't, and where it fits relative to tools like Claude Code. Here's what I found.
Why Try Gemini CLI for iOS Development at All?
Gemini CLI lets you interact with Gemini models directly from your terminal — either by typing prompts after the gemini command or by piping file contents into it. It's a different model from tools that open a chat interface in your editor; this one stays in the terminal and integrates naturally with shell pipelines.
Three things made me want to try it specifically for iOS work:
Cost. Google offers a generous free tier, which means I could experiment for a week without worrying about unexpected charges. For solo developers running lean, this matters — not because any individual usage is expensive, but because the psychological barrier to experimenting freely is lower when billing isn't part of the equation.
Text transformation hypothesis. I had a hunch that CLI-based AI tools shine at tasks where you have clear input and want transformed output: translation, rewriting, summarizing commit history into release notes. These map naturally to a piped workflow.
Personal comparison with Claude Code. I'd read plenty of comparisons online, but I wanted to build my own intuition through actual use. The Gemini CLI vs. Claude Code question comes up a lot in indie dev communities, and I wanted a grounded answer.
The specific pain points I set out to test against my actual iOS work:
- Writing App Store release notes in both Japanese and English (I release in both markets)
- Translating
Localizable.stringsfiles (some apps have 200+ entries) - Generating unit test boilerplate for Swift service classes
- Diagnosing Xcode build errors quickly
Setup: Five Minutes to Your First Useful Result
Installation via npm is the simplest path:
npm install -g @google/gemini-cli
gemini authRunning gemini auth opens a browser window for Google account authentication. Once that completes, you're back in the terminal and immediately operational. No API key management, no environment variable setup — the authentication flow handles everything.
A config file is written to ~/.gemini/config.json, where you can set your preferred model:
{
"model": "gemini-2.5-pro",
"temperature": 0.7
}For most of my iOS work, I switched between gemini-2.5-pro (better reasoning, slightly slower) and gemini-2.5-flash (faster, good for translation and text tasks). The flash model handled translation and release notes generation well; I defaulted to pro for code review.
# Sanity check
echo "What is the capital of France?" | geminiThat's all the setup required. The simplicity was genuinely surprising compared to what I expected.
Five Use Cases I Tested in Real iOS Projects
① Swift Code Review
I piped individual Swift files into Gemini and asked for targeted reviews:
cat NetworkManager.swift | gemini "Review this Swift code for memory leak risks. Focus on closures and NotificationCenter usage."For single-file reviews, this worked reasonably well. It identified missing weak self captures in async callbacks and caught a NotificationCenter observer that was never being removed. Both were genuine issues I'd overlooked.
The limitation showed up clearly when suggestions assumed context that existed elsewhere. It recommended restructuring responsibility into a separate class — which I'd already built in a different file. Without project-wide context, it couldn't know. This isn't a failure of Gemini CLI specifically; it's an inherent constraint of the piped approach.
Verdict: Useful for focused single-file reviews, not suited for architectural feedback.
② XCTest Unit Test Generation
I passed class definitions and asked for test scaffolding:
cat UserService.swift | gemini "Generate XCTest unit tests for this Swift service class. Use protocol-based mocking and cover the main success and error paths."About 70% of the generated code was usable without modification. The XCTestExpectation patterns for async testing were accurate, and the basic structure — test class setup, individual test methods, assertion patterns — was solid. The remaining 30% needed adjustment, primarily around project-specific dependencies that Gemini had to guess at.
Writing test boilerplate from scratch is tedious, not difficult. Having 70% generated and reviewing the rest is a real time saving. I'll keep using this.
Verdict: Solid boilerplate generator. Works best for self-contained service classes.
③ Localizable.strings Translation
This became the biggest workflow improvement of the entire week:
cat ja.lproj/Localizable.strings | gemini \
"Translate this Localizable.strings file to English. The target is iOS app UI copy — buttons, labels, alerts. Prioritize natural-sounding English over literal translation."Translation work for 200+ string entries normally takes me 2–3 hours when I write everything from scratch in both languages. Using Gemini's output as a first draft and editing from there brought that down to about 30 minutes. The quality was meaningfully better than generic machine translation — it understood that "設定" in a navigation context should be "Settings" not "Configuration", and that button labels should be concise.
App-specific proper nouns and feature names still need manual verification. That's a small fraction of the total work, though.
Verdict: This is where Gemini CLI earns its place in a localized app's development workflow. Highly recommended.
④ Release Notes Generation from Git History
I piped commit logs and asked for App Store-ready release notes:
git log --oneline v2.1.0..HEAD | gemini \
"Turn these git commits into App Store release notes. Convert technical language to user-friendly copy. Provide both Japanese and English versions."The output quality exceeded my expectations. The transformation from internal commit messages to user-facing language was consistently good. "Fix: crash when tapping notification" became "Fixed a crash that could occur when opening the app from a notification" — accurate, user-centric, the right length.
Producing release notes in two languages used to be two separate writing tasks. Now it's one prompt. The time savings compound across every release.
Verdict: Excellent. This alone justifies the setup time.
⑤ Xcode Build Error Diagnosis
I pasted error output directly and asked for causes and solutions:
gemini "Diagnose this Xcode build error and suggest a fix:
error: Build input file cannot be found: '/Users/xxx/MyProject/MyFramework.framework'
Target 'MyApp' (project 'MyApp')"Common error patterns were handled well — framework reference issues, Swift version mismatches, signing configuration problems. For these, the suggestions were accurate and saved me the manual search through Stack Overflow.
The limitation appeared with errors involving project-specific config files. Questions about xcconfig settings or Podfile.lock version conflicts often prompted "please share your configuration file." Understandable, but it breaks the quick-lookup use case.
Verdict: Good for common error types. Not a replacement for debugging complex project-specific issues.
Model Selection: When to Use Flash vs. Pro
After a week of switching between models, here's my rough guidance:
Use gemini-2.5-flash for:
- Translation tasks (it's fast and the quality difference from Pro is minimal for this)
- Release notes generation
- Short code explanations
Use gemini-2.5-pro for:
- Code review (better reasoning catches more subtle issues)
- Generating test code that needs to handle edge cases
- Anything where accuracy matters more than speed
The default in config.json should probably be Flash for daily use, with Pro invoked explicitly for code tasks.
What Didn't Work Well — Honest Assessment
No project-wide context
This is the fundamental constraint. Each command starts fresh. For reviews or refactoring suggestions that require understanding how a dozen files relate to each other, Gemini CLI isn't the right tool in this form. That's not a criticism — it's just an architectural reality of the piped CLI approach.
Large Swift files
View controllers over 2,000 lines occasionally ran into context limits, with Gemini processing only part of the file. Splitting into logical chunks before piping is a workable workaround, but it adds friction.
Response latency varies by time of day
During Japanese business hours, response times were noticeably slower. Early mornings and late evenings were consistently faster. If you're doing a large translation batch, consider scheduling it outside peak hours.
Gemini CLI vs. Claude Code: Where Each Wins
After a week of deliberate side-by-side use, my view is that these tools complement each other rather than compete:
Gemini CLI is stronger for:
- Text transformation tasks (translation, rewriting, summarization)
- Release notes generation from commit history
- Quick, contained single-file reviews
- Free-tier experimentation without billing pressure
Claude Code is stronger for:
- Understanding and working within a full project codebase
- Multi-file architectural suggestions and refactoring
- Extended coding sessions where context continuity matters
The honest answer for indie developers: use both. They're different instruments. Trying to pick one universally is like asking whether you need a hammer or a saw.
Where to Start If You're New to Gemini CLI
Release note generation is the lowest-friction entry point. Take your most recent set of git commits, pipe them in, and see what comes back. It's the kind of immediate, concrete result that makes the value tangible without requiring any workflow changes upfront.
From there, move to translation — if you support multiple languages in your apps, this is where Gemini CLI can return the most time per task. Code review is useful but requires more judgment about when to trust the output.
The full experiment is worth running on your own project. One week was enough to find the right role for this tool in my workflow.