Shipping a Flutter App Both App Stores Will Actually Approve

I built and shipped two production Flutter apps — a driver app and a parent app — for a transport platform running thousands of real journeys. Flutter let one engineer credibly own both iOS and Android. But the code was never the hard part of *shipping*. The stores were.

Review is a system; treat it like one

Apple and Google reject for reasons that have nothing to do with whether your app works: a permission prompt without enough justification, a login wall with no demo account, a background-location use the reviewer doesn't understand. I learned to write the review notes as carefully as the code — demo credentials, a plain-English explanation of every sensitive permission, screenshots of the flows. Treat the reviewer as a user who's actively looking for a reason to say no.

Background location is the boss fight

For a real-time tracking app, location-in-background is both the core feature and the single most scrutinised permission on both platforms. You justify it precisely, you degrade gracefully when it's denied, and you never ask for more than the feature genuinely needs. Over-asking is the fastest path to rejection.

Build pipelines that make release boring

Manual App Store and Play Store submissions are where days disappear and mistakes happen. Automating the build, signing, and upload steps cut our release cycle dramatically and — more importantly — made releasing unremarkable. The goal with mobile is that shipping an update is a Tuesday, not an event.

One codebase, two platforms, real discipline

Flutter's promise is genuine: shared code across iOS and Android. The catch is that the platform differences you can't share — permissions, store policy, push, deep links — are exactly the ones that bite. Plan for them up front and the cross-platform win is real.