PreviousNext

How We Ship Mobile Apps to Google Play from Kampala (Expo + Go)

The real pipeline behind two live Play Store apps — Expo and React Native on the front, a Go API on the back, EAS builds, OTA updates, and the store-review hurdles that trip Ugandan teams up.

Getting a mobile app built is the easy part. Getting it live on the Play Store — signed, reviewed, approved and updatable — is where most Ugandan app projects stall. We recently took two apps the whole way: Committed, a developer-activity leaderboard, and Stride, a team step-challenge app. Both are live on Google Play. Here is the pipeline that got them there.

Table of Contents

  1. The stack: Expo and Go
  2. Why one Go API behind the app
  3. Builds and OTA updates
  4. Surviving Play review
  5. What this means for your app
  6. FAQs

The stack

Both apps share the same shape:

  • Front end — Expo / React Native and TypeScript, one codebase targeting Android and iOS.
  • Back end — a Go (Gin) API with a PostgreSQL database, built on our Grit framework, which ships auth, background jobs, file storage and more pre-wired.
  • Auth — JWT with refresh tokens held in the device's secure store, not in plain local storage.

One language on the client, one on the server, and a shared set of TypeScript types so the two can't silently drift apart.

Why one Go API

A mobile app is a client, not a system of record. The moment you have a leaderboard, a chat feed, push notifications or anything multi-user, you need a server that owns the truth. Putting a Go API behind the app means:

  • Scores, rankings and balances are computed server-side, so no one can tamper with them from a jailbroken phone.
  • Background jobs do the heavy lifting — ingesting GitHub webhooks and recomputing scores for Committed, rolling up daily step totals for Stride.
  • The same API can later feed a web dashboard or admin panel without rebuilding anything.

Builds and OTA updates

We build release binaries with EAS Build — a signed Android App Bundle (AAB) for Play, and an iOS build where needed — from the same Expo project. The win that teams underrate is OTA updates: once the app is installed, we can push JavaScript changes over the air without a new store review. A scoring-formula tweak or a copy fix ships the same day instead of waiting days for re-approval.

One caveat we have hit: an OTA update ships JavaScript, not native build-time configuration. So anything the app needs at runtime — like the production API URL — must have a safe fallback compiled into the build, because a missing value can't be fixed by an over-the-air update.

Surviving Play review

This is where projects die. What actually gets apps approved:

  • Say exactly what the app does. Play rejects vague data-safety and permissions answers more often than bad ones. For Stride, every permission has a one-line justification tied to a real feature.
  • Declare data honestly. What you collect, whether it's shared, and that users can delete their account in-app. Stride sends one number a day — the step count — and says so plainly.
  • Block permissions you don't use. If you don't use location, block it in the manifest so a scan agrees with your declaration.
  • Health and finance apps get extra scrutiny. A fitness app that reads Health Connect must justify each health permission and state clearly that it offers no medical advice.

What this means for your app

If you are a Ugandan business or founder planning an app, the lesson from Committed and Stride is that the store is part of the build, not an afterthought. Budget for signing, store assets, a privacy policy on a public URL, and an honest data-safety declaration from day one. Build on a stack — Expo plus a real API — that lets you ship fixes the same day and grow into web and admin surfaces later without a rewrite.

FAQs

Can one codebase serve Android and iOS? Yes — Expo / React Native targets both from a single TypeScript codebase, which is how we keep two platforms affordable.

Do app updates always need store review? No — JavaScript changes ship over the air with EAS Update. Only native changes need a new store build and review.

Why a Go backend instead of a serverless/BaaS? For anything with server-authoritative logic — scores, balances, multi-user state — a real API you own is more robust and cheaper to evolve than stitching managed services together.

How long does Play approval take? Days, not weeks, if your data-safety and permissions declarations are clean. Vague answers are the main cause of delay and rejection.


Planning a mobile app you actually want on the Play Store? Request a quote — we've shipped the whole pipeline end to end.