Publishing
From a debug build to a signed binary, ready to submit
Publishing to the Stores
An app that works on your emulator is halfway to publication, not 95% of the way there. The remaining distance isn't measured in lines of code: it consists of unique identifiers that can't be changed after the first upload, signing keys whose loss is irreversible, a release mode that reveals bugs invisible in debug, and store requirements that change several times a year.
This is a different kind of lesson from the previous ones. Code is the minority here; most of it comes down to decisions and checks. We'll follow the order in which they actually come up: first what is irreversible and therefore must be decided up front — package identifier, name, signing key — then producing the binary, and finally what remains to be prepared on the store side.
A word of honesty before we begin. The procedures of both stores, the required artwork formats, the minimum Android API levels, the privacy declarations, and the cost of developer accounts change regularly. This tutorial describes the technical steps on the Flutter side, which are stable. For anything related to publishing rules, the only reliable source is the console of the relevant store at the time you submit; don't trust any amount or timeframe you read in a tutorial, including this one.
Comments
Comments are powered by GitHub Discussions
Sign in with GitHub to join the discussion