Forem: Guillermo

How to Automate Google Play Releases Without Losing Your Mind

Guillermo — Fri, 20 Mar 2026 10:35:25 +0000

Intro

Let’s be honest.

Publishing an Android app to Google Play manually is already annoying…

but automating it? That’s where things usually get messy.

If you’ve ever tried, you probably ended up with:

a random JSON key sitting in your repo 😬
a CI pipeline you don’t fully trust
or a setup you’re afraid to touch because “it works… somehow”

I’ve been there.

So this post is the version I wish I had earlier:

a clean, secure way to automate Google Play releases without hacks, without leaking secrets, and without overcomplicating everything.

The Key Idea

Instead of storing a Google service account key in your repo (please don’t), we use:

Workload Identity Federation (WIF)
Service account impersonation

In plain English:

Your CI logs into Google using short-lived tokens — no permanent secrets needed.

What You’ll Get

By the end of this:

Your app builds automatically
Your AAB gets uploaded to Google Play
No credentials stored in your repo
A setup you won’t be scared to touch later

Quick Setup (Copy & Paste)

1. Define variables

PROJECT_ID="your-project-id"
PROJECT_NUMBER="your-project-number"
POOL_ID="github"
PROVIDER_ID="ci-provider"
SERVICE_ACCOUNT_NAME="ci-publisher"
SERVICE_ACCOUNT_EMAIL="ci-publisher@your-project-id.iam.gserviceaccount.com"
REPO="your-org/your-repo"
PACKAGE_NAME="com.your.app"

2. Create service account

gcloud iam service-accounts create "$SERVICE_ACCOUNT_NAME" \
  --project="$PROJECT_ID"

3. Create identity pool

gcloud iam workload-identity-pools create "$POOL_ID" \
  --project="$PROJECT_ID" \
  --location="global"

4. Connect your CI (OIDC)

gcloud iam workload-identity-pools providers create-oidc "$PROVIDER_ID" \
  --project="$PROJECT_ID" \
  --location="global" \
  --workload-identity-pool="$POOL_ID" \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository,attribute.ref=assertion.ref" \
  --attribute-condition="assertion.repository == '$REPO'"

5. Allow impersonation

gcloud iam service-accounts add-iam-policy-binding \
  "$SERVICE_ACCOUNT_EMAIL" \
  --project="$PROJECT_ID" \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/projects/$PROJECT_NUMBER/locations/global/workloadIdentityPools/$POOL_ID/attribute.repository/$REPO"

6. Enable Play API

gcloud services enable androidpublisher.googleapis.com \
  --project="$PROJECT_ID"

7. Configure Play Console (manual)

Go to Users and permissions
Add the service account email
Give access to your app
Grant publish permissions (internal track is enough)

8. Add CI secrets

Workload Identity Provider

projects/YOUR_PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL/providers/PROVIDER

Service Account

ci-publisher@your-project-id.iam.gserviceaccount.com

9. Add CI workflow

name: Publish Android to Play

on:
  push:
    tags:
      - "v*"

permissions:
  contents: read
  id-token: write

jobs:
  publish:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@vX

      - name: Authenticate
        uses: google-github-actions/auth@v3
        with:
          workload_identity_provider: ${{ secrets.WIF_PROVIDER }}
          service_account: ${{ secrets.SERVICE_ACCOUNT }}

      - name: Build
        run: ./gradlew bundleRelease

      - name: Upload
        uses: r0adkll/upload-google-play@v1
        with:
          serviceAccountJson: ${{ steps.auth.outputs.credentials_file_path }}
          packageName: com.your.app
          releaseFiles: app/build/outputs/bundle/release/*.aab
          track: internal

10. Trigger a release

git tag v1.0.0
git push origin v1.0.0

Debug Checklist

If something breaks, check this first:

Is the provider pointing to the correct repo?
Does your secret include /providers/...?
Did you add id-token: write?
Is the service account added in Play Console?

Common Mistakes

Auth works but upload fails

Play Console permissions are wrong.

Auth fails completely

Repository or branch does not match the provider condition.

Token errors

Missing id-token: write permission.

Final Thoughts

This setup might look complex at first…

but once it’s in place, it just works.

And more importantly:

no leaked keys
no fragile hacks
no future headaches

Just a clean pipeline doing its job.

TL;DR

Don’t store Google service account keys
Use Workload Identity Federation
Let CI impersonate a service account
Upload with a GitHub Action
Sleep better at night 😄

Why `bizimobile` Feels Like a Real-World Kotlin Multiplatform Project, Not Just a Demo

Guillermo — Sat, 14 Mar 2026 12:26:57 +0000

When "just build the app" turns into four apps overnight

We all know the feeling. The Android version is finally coming together, and then the inevitable request drops: “Can we get this on iPhone too?” A week later, it’s “What about Wear OS?” Then Apple Watch joins the chat. And because the universe has a sense of humor, someone asks, “Could Siri or Assistant just answer quick questions?”

Suddenly, you aren't building a single app anymore. You’re managing a whole ecosystem of apps, devices, APIs, permissions, sync rules, and UX expectations that desperately want to drift apart the second you look away.

That’s exactly why the gcaguilar/bizimobile repository is so interesting. It’s not just another simple bike-station app for Zaragoza. It reads like a practical, battle-tested reference for shipping a cohesive product across Android, Wear OS, iOS, and Apple Watch—all while keeping the messy logic exactly where it belongs: shared. (GitHub)

The Pain: The headaches this repo actually solves

The real challenge this project tackles isn't showing bike stations on a map. That’s the easy part. The hard part is everything that surrounds it:

Duplicated logic: Writing the exact same business rules for Android and iOS.
Different UI stacks: Managing entirely different interfaces for phones and watches.
Location limbo: Dealing with users denying permissions or GPS taking forever to lock on.
Flaky APIs: Relying on public civic data sources that aren't always in a great mood.
Cross-device sync: Making sure a "favorite" on your phone actually shows up as a "favorite" on your watch.
Voice integrations: Trying to add Siri or Assistant without accidentally building a second, parallel version of your app.

bizimobile tackles all of these head-on. By splitting responsibilities into shared:core, shared:mobile-ui, androidApp, wearApp, and apple, it sends a strong architectural message: share the logic and as much UI as possible, but keep native shells for the parts that truly need native APIs. The shared core uses Kotlin Multiplatform (KMP) with Ktor, serialization, Okio, and Metro DI. Meanwhile, the shared mobile UI is built with Compose Multiplatform and exported to iOS as static frameworks. (GitHub) The practical value here is huge: it stops the classic “same feature, four different implementations” trap before it even starts.

The Solution: Shared where it matters, native where it pays off

What makes this repo so elegant is that it doesn’t force everything into a single, massive abstraction blender. Instead, it uses a highly pragmatic split:

1. Shared core for domain and data

The shared core owns the models, repositories, configuration, platform contracts, API clients, station matching, settings, and assistant-resolution logic. In plain English: the rules of the app are written exactly once. (GitHub)

2. Shared mobile UI for Android and iOS

There’s a dedicated shared:mobile-ui module that relies on the core, uses Compose Multiplatform, and gets exported as an iOS framework. Android loads that UI directly, while the Apple side imports BiziMobileUi and wraps it with SwiftUI/App Intents glue. It’s the perfect middle ground—one product experience, without pretending iOS and Android are identical under the hood. (GitHub)

3. Native shells for platform superpowers

On Android, MainActivity creates platform bindings, feeds them into the shared UI, parses shortcut payloads, and handles location permissions. Over on Apple, Swift files wrap the shared graph for Siri, App Intents, and WatchConnectivity. For Wear OS, the watch app builds the same shared graph but renders a watch-specific Compose UI. (GitHub)

It’s the kind of architecture that feels grown-up: shared brain, native hands.

How it works under the hood

1) The data layer is built for reality, not the happy path
One of the smartest details in the repo is how it fetches station data. It tries the official Zaragoza City Council feed first. If that fails, it quietly falls back to CityBikes. It handles pagination, merges results, filters out out-of-service stations, calculates your distance, and sorts by proximity. (GitHub)

It’s an excellent example of defensive product engineering. It’s like carrying an umbrella in a city where weather apps lie to you—not glamorous, but deeply practical.

2) GPS gets a timeout (because users hate waiting)
StationsRepositoryImpl does something every app should do: it refuses to block the whole UI while waiting for a perfect GPS fix. It tries to get your location, but only gives it a short timeout. If it fails (or if the user says "nope" to permissions), it falls back to a default location in the city center. The user immediately gets useful data instead of staring at an endless loading spinner. (GitHub)

3) Favorites are actually synchronized, not just stored
Favorites are treated as shared user state. The repository saves a JSON snapshot locally, pulls the latest from the watch sync bridge, merges them, deduplicates, writes back to disk, and pushes the update back to the watch. On Apple platforms, it uses WatchConnectivity to turn the watch-and-phone relationship into a real, two-way sync channel, not just a fake "companion app." (GitHub)

4) The Dependency Injection is intentionally boring
The repo uses Metro DI for compile-time dependency injection. If you haven't used compile-time DI, think of it like wiring a house before you move the furniture in: everything is securely connected ahead of time, rather than relying on runtime magic to find the right outlet. This keeps the shared layer completely portable without blinding it to native capabilities. (GitHub)

5) Voice shortcuts aren't just bolted on
Instead of duplicating logic for voice assistants, the shared core defines the actions ("nearest station", "station status", etc.) and handles the query matching. On Apple platforms, the AppleShortcutRunner simply asks the shared KMP graph for the answers. This is exactly how you avoid the dreaded "Siri says one thing, but the app shows another" bug. (GitHub)

6) Wear OS is a first-class citizen
The Wear app isn't an afterthought. It builds the shared graph, refreshes data, and lets users browse stations and launch routes using a UI actually built for a watch screen. It proves a great point: shared logic doesn't mean shared screens; it means shared decisions. (GitHub)

Why you should study this (even if you don't care about bikes)

The bike-network use case is just the vehicle. What you’re really looking at is a highly reusable blueprint for apps that need:

Cross-platform domain logic
Shared mobile UI
Native integrations at the edges
Resilient API consumption
Real watch/mobile state sync
Assistant and shortcut support

Even the CI/CD pipeline is mature, building Android, iOS, and watchOS jobs in parallel and distributing them through Firebase. That’s release-minded engineering, not toy-project behavior. (GitHub)

The Takeaway

bizimobile is worth your time because it showcases a version of Kotlin Multiplatform that is practical, not ideological. It proves you can share the heavy lifting, keep the native UX where it counts, and build something that actually behaves coherently across phones, watches, and voice assistants. (GitHub)

If you get even one "ah, that's a smart way to do it" moment out of it, go drop a star on the repo. The best technical examples aren't the ones shouting the loudest—they're the ones quietly solving the messes we deal with every day.

I got fed up with my city’s bike-share, so I built BiziData

Guillermo — Thu, 12 Mar 2026 20:37:08 +0000

Like many of you, I use bike-share system pretty regularly. And, honestly, it drives me nuts: either there’s not a single bike when I need one, or the station is packed and I can’t return mine. It feels inefficient—but is it really, or is it just bad luck?

That nagging question led me to start tinkering with BiziData, a little side project to dig into the data behind the system.

Why this matters
Cities release mobility data all the time, but it’s usually buried in APIs or spreadsheets that are a pain to make sense of. So, I thought: What if we could actually see what’s going on?

So I started exploring things:

How does bike availability change throughout the day?
Where do the biggest imbalances happen?
What patterns emerge in how people move around?
I’m also curious about how outside factors play into usage:
Do big events in the city spike demand?
How does weather mess with usage patterns?
How do other transport options (like buses or scooters) interact with bike-share?
Could changes in bike lanes or infrastructure make a difference?
The big picture? Using data to understand—and maybe even improve—how urban mobility works.

What’s built so far
Right now, BiziData pulls data from Zaragoza’s bike-share and turns it into a simple dashboard. It shows:

Real-time station availability
Historical usage trends
Visualizations of system activity Tech stack: Next.js, TypeScript, Prisma, Redis

Could this work in other cities?
For now, it’s just Zaragoza—but here’s the cool part: a lot of bike-share systems (especially those run by Lyft) use similar tech. That means the same approach could work elsewhere, and even let us compare how different cities handle mobility.

The tough parts
Some things were harder than I expected:

Building a reliable data pipeline from open APIs
Figuring out which metrics actually matter (and not drowning in noise)
Resisting the urge to scope-creep—there are so many directions to take this!

Monetization? Still a mystery
~~Honestly, I haven’t figured this out yet.~~ I've been battling AI with the role of an investor who doesn't want to part with a penny, and it's won..But I do think there’s potential: if data can help cities manage bike-share better—like improving bike distribution, guiding infrastructure decisions, or cutting inefficiencies—everyone wins.

I’d love your thoughts!
If you’ve got experience with mobility data, bike-share systems, or just ideas, I’d love to hear:

What metrics would you want to see in a mobility dashboard?
Would cross-city comparisons be useful?
Have you worked with similar data before?

Check out the repo if you’re curious: https://github.com/gcaguilar/bizidashboard

Spoiler: There’s more coming…
(Shhh… I’m already working on a mobile app to help you find the nearest station with available bikes or free slots. Because, let’s be real, nobody wants to walk five blocks just to find out they can’t park their bike.)

Thanks for reading—and let me know what you think! 🚴‍♂️