Skip to content

gplay vs Fastlane supply: which Google Play CLI in 2026?

Fastlane supply has been the default answer to “how do I publish to Google Play from the command line?” for a decade. It’s battle-tested and it works. But it was designed for one job — pushing builds and metadata — and the Play Console has grown far beyond that: subscriptions with base plans and offers, purchase verification, vitals, reviews, permission management, private app publishing.

Here’s an honest look at where each tool stands.

  • Both handle the classics well: AAB/APK upload, track assignment, staged rollouts, store listings, screenshots.
  • gplay goes further: full monetization stack, purchase verification, vitals, reviews, reports, user management, Managed Google Play.
  • Runtime footprint is the sleeper difference: Fastlane needs a Ruby environment; gplay is one static Go binary.
Capability gplay Fastlane supply
Upload AAB/APK, tracks, rollouts
Store listings & screenshots
Subscriptions, base plans, offers ✅ Full
In-app products & one-time purchases
Purchase verification & refunds
Vitals: crashes, ANRs, performance
Reviews: read + reply
Financial & statistics reports
Users & permission grants
Managed Google Play (private apps)
Output format Minified JSON Human-oriented logs
Runtime Single Go binary Ruby + gems

Fairness matters:

  • Ecosystem breadth — Fastlane is a whole automation framework (screenshots via screengrab, iOS support, plugins). If you already run a Fastfile for both platforms, that inertia is real.
  • Maturity — a decade of production use and a huge community.

If all you do is supply an AAB once a sprint, Fastlane keeps doing that fine.

Modern Play operations are mostly not uploads. Checking crash clusters before expanding a rollout, replying to reviews, creating a promotional offer, verifying a purchase token server-side — with Fastlane these all mean opening the web console. With gplay:

Terminal window
gplay vitals crashes query --package com.example.app --from 2026-06-27 --to 2026-07-04
gplay reviews reply --package com.example.app --review-id <ID> --text "Fixed in 2.1!"
gplay purchases subscriptionsv2 get --package com.example.app --token <TOKEN>

Every gplay command emits minified JSON, so it pipes into jq, scripts, and AI agents without parsing log text:

Terminal window
gplay tracks list --package com.example.app | jq '.tracks[].track'

CI images and dev machines don’t need Ruby. Install is one line, and startup is instant:

Terminal window
brew install tamtom/tap/gplay

Explicit flags, --help everywhere, --dry-run on every write, no interactive prompts — plus ready-made Agent Skills so Claude Code or Cursor can run your whole release flow.

Already have a Fastlane metadata/ directory? gplay imports it directly:

Terminal window
gplay migrate fastlane --package com.example.app --dir ./fastlane/metadata/android

Your existing translations, descriptions, and screenshots come along; nothing is lost.

If your Play workflow is “upload an AAB, sometimes update a listing,” either tool works — pick whichever fits your stack. The moment your workflow touches subscriptions, purchase verification, vitals, reviews, or agents/automation beyond the upload, gplay covers ground Fastlane simply doesn’t.