Publishing an app, from local stores to Google Play

What does publishing an app actually involve?

The Android documentation splits the whole job into two halves, and that split is enough to plan with: preparing the app for release, and then getting it to users.

The first half is a set of mechanical tasks, none of them creative, each of them forgotten once. Logging has to be disabled and removed, the debuggable flag has to be off in the release variant, the version information has to be set, and then the release build is made and signed. The documentation separately insists that you test the release version on at least one real handset and one tablet before distributing, and that any servers and services the app depends on must be production ready.

The second half is choosing the distribution route. The Android documentation puts three side by side: through a marketplace, on your own website, or by sending the app straight to a user. And it writes plainly that you can distribute through any app marketplace and can use multiple marketplaces. For an Iranian product that sentence is not trivial, because it means the choice of store is reversible and additive, unlike the next decision.

One technical point that changes the order of work: since August 2021 Google accepts new apps only as an App Bundle rather than an APK file. The Android documentation explains that an App Bundle is a publishing format and cannot be installed on a device; the store builds the APKs from it. The difference between the two formats is opened up in how an app works. The Iranian stores still work with APKs, so if you want both routes you have to produce both outputs from one project from day one.

Why is the signing key the most important file in the project?

Android installs or updates no app without a digital signature. That signature acts as the identity card of the app: the operating system uses it to know that the new version really came from whoever made the previous one.

And here is the one sentence worth memorising from this lesson. The Android documentation writes, about apps that have not opted into Play App Signing, that if you lose your app signing key you lose the ability to update your app. No backup, no recovery, no administrative process; the app stays on a thousand phones and forever after you can only publish a new app under a different package name.

Google Play separated two keys for exactly this reason. One is the app signing key, which Google itself holds and uses to sign the builds that reach users, and one is the upload key, which stays with you and is used only to send the file to the Console. If the upload key is lost, a reset can be requested. The same documentation warns that once this is configured you cannot retrieve a copy of your app signing key.

One decision that matters especially for an Iranian product and is usually understood too late: if you want the same signing key to work across several stores, the documentation says you must provide your own signing key when configuring Play App Signing instead of having Google generate one for you. Somebody who publishes on a local store first and goes to Google Play later will otherwise end up with two versions of one app carrying two different identities.

In practice: on day one, put the signing key and its password somewhere that survives the loss of the laptop, and that somewhere must not be the code repository. It is the only file in the project that money and time cannot replace.

Google Play from Iran: what does Google own table say?

Instead of any analysis, this section is written off one official page, and we give you the reading method so you can do the same thing yourself.

Google has a page called supported locations for developer and merchant registration, which is a table with three columns: supports developer registration, supports merchant registration, and default currency. We read that page today and counted it. The table carries 214 country rows, and in the developer registration column all 214 of them are ticked.

What only counting reveals: the legend above that table defines both a tick and a cross for the first column, yet today version of the table contains not a single cross. Which means this is not a list of places whose status was assessed; it is the list of places that are supported. And Iran is not in it, neither ticked nor crossed. For comparison, Iraq, Afghanistan and Türkiye all have rows.

That is what we say and no more. We do not say no route exists, because this table said nothing about routes not existing; and we do not suggest a way around it, because that is neither teaching nor something we do. If somebody tells you there is a path, this is the test: is that path consistent with the rules of the Google account, or does it merely work until it is noticed.

There is also a technical constraint that has nothing to do with country, catches everybody, and carries a date. The Android documentation says that starting August 31 2026, new apps and app updates must target Android 16, meaning API level 36 or higher, to be submitted to Google Play, and that existing apps must target Android 15 or higher to remain available to new users. The same page says that if you need more time to update, you will be able to request an extension to November 1, 2026. These numbers change every year, so check the verified date on this page, and if it has passed, open that page yourself.

Cafe Bazaar and Myket: what we could check and what we could not

For an Android app whose audience is inside Iran, Cafe Bazaar and Myket are the two places a user actually installs from. That we have written nothing here about their rules is a decision rather than an omission, and the reason is our own measurement today.

We called both developer sites from this server. The result was that neither one hands over the text of its rules to a plain HTTP request. Both send an empty page whose content JavaScript builds later in the browser. Which means those rules effectively do not exist for any reader without a graphical browser, archives and checking tools included.

So we quote not one line of their rules, because we cannot claim to have read it at its source. What we can say with confidence is two things: both stores accept an Android app as an APK, and, exactly as the Android documentation itself writes, publishing to several stores at once is a normal and unobstructed thing to do. The rest you have to see yourself on those two sites with a browser, and our advice is to note the date you looked, because store rules change without notice.

One practical point that follows from this and depends on no store: everything you send to a store, from the title and description to the images, should be kept somewhere of your own. The second store asks for the same things and you will not feel like rewriting them that day.

The route that skips the store entirely

If your product is lists, forms, orders and a panel, and has no particular business with the phone hardware, there is a fourth route that skips this whole lesson: publish the same product as a progressive web app.

The Mozilla documentation defines it simply: an app built with web platform technologies that provides an experience like a platform specific app, runs on many platforms from a single codebase, is installable, and can work offline and in the background. For the user that means an icon on the phone home screen, and for you it means no signing, no store review, no waiting for approval.

Our position here is blunt, because saying it does not benefit somebody who sells apps: a large share of the projects that start as "an app" actually need a well built website rather than a store app. If everything the product does can be done from a browser, the store has only added a layer of cost and delay. Site builder or custom build looks at the same question from the web side.

And let us say honestly where this answer is wrong. If you need reliable, always on notifications, if you work with Bluetooth or particular sensors, if you want in app payment, or if your audience finds the app by searching a store, a web app is not enough and you have to walk the five stages above. The decision between the two routes is not technical; it depends on where your user goes looking for you. If that decision is heavy for your team, the RGB app service page says on what basis we recommend one over the other.