Google Play is not available on mainland Chinese devices, and neither are the Google services an Android application built in Europe is usually resting on. The consequence is not that Android distribution is hard in China; it is that it is a different activity. Users get applications from stores operated by the manufacturer of their phone, or from large platform stores, and each of those is a separate commercial relationship with a separate set of documents to produce. A team that budgeted one submission finds it has several, and a team that budgeted one update finds the same.
There is no store, there are several
The stores that matter divide into two families. The first is the manufacturers': the store preinstalled on the phone, which is where most users of that brand get their applications, and which has the advantage of being there by default and the disadvantage of reaching only that brand's users. The second is the platform stores, which are not tied to a handset and reach across brands. Apple's store exists in mainland China as a separate storefront with its own review and its own filing requirements, which makes iOS simpler in structure and not simpler in substance.
The practical choice is not « all of them » and not one. It is to look at which handsets your actual users carry — which, for a B2B application, is a question you can answer by asking a dozen of them — and to publish in the two or three stores that cover most of that population, then add others if the application turns out to matter. Each additional store costs a submission, a review cycle and, for ever afterwards, a place in the update routine.
| Manufacturer stores | Platform stores | |
|---|---|---|
| Who they reach | Users of that brand of handset, on the store that is already on the phone | Users across brands, who went looking for a store rather than using the default |
| What they ask for | A verified corporate identity, the usual software ownership evidence, and compliance with that manufacturer's own technical rules | Much the same documents, with review criteria and content rules that differ in detail from one store to the next |
| What they cost you over time | One review queue per manufacturer, and device-specific behaviour to test on that brand's handsets | Another review queue, and a second set of store listings and screenshots to keep current |
What a store asks for before it will publish
The documents vary in detail between stores and they change, so treat what follows as the shape of the requirement rather than a checklist to rely on, and confirm the current list with each store before planning a date. The shape is consistent: a store wants to know which registered company is publishing, that the company owns the software, and that the application complies with the rules that apply to its category.
Three things follow from that, and they are the ones that surprise European teams. First, publishing normally supposes a Chinese corporate entity, because the identity a store verifies is a domestic business registration; an application can sometimes be published through a partner's entity, which is a real arrangement and also one that puts your listing, your reviews and your users under someone else's name. Second, the stores ask for evidence that the software is yours, which in China ordinarily means a software copyright registration — a filing with its own lead time, which should be started long before you want to publish. Third, anything the application connects to that is hosted in China needs the hosting filing that applies to domestic services, and any application handling personal data has to be able to say what it collects and why, in the form local rules require. Some categories — games and anything financial or medical among them — carry additional authorisations that are a project in themselves; if you are in one of those, find that out before anything else, because it determines the whole timeline.
Signing, and the update you will do several times
An Android package is signed, and the signing key is the identity of the application as every store and every device understands it. Lose it and you cannot update what you published; let a third party hold it and they can. Decide where that key lives and who can use it before the first submission, and keep the arrangement written down somewhere other than in one person's memory. Where a store offers to manage signing on your behalf, understand what that means for the package users receive and for your ability to publish the same application elsewhere.
The update is the part nobody plans for properly. A new version has to be submitted to every store separately, each one reviews on its own schedule, and they do not finish together. For a few days or longer your users are therefore running different versions depending on which store they came from, which has one practical consequence: anything on your side that the application talks to has to tolerate the previous version for as long as a review can take. Teams used to a single store ship a breaking change on the assumption everybody updated at once, and find out otherwise from the people whose store was slowest.
When a mini-program replaces the application
Before any of this, the question worth asking is whether a native application is what you need. A WeChat mini-program needs no store, no store listing and no installation; it is found inside an application the user already has, it opens from a message, a code or a search, it inherits an identity and a payment method, and it is updated in one place by you. For a catalogue, an order form, a configurator, a documentation library, a booking tool or a service portal, that is not a compromise — it is the better instrument, and the fact that there is nothing to install is most of the reason.
A native application earns its cost when it needs something the mini-program cannot give: sustained background work, deep access to the device, heavy local computation, operation without a network, connection to specific hardware, or an interface that has to be on the home screen because it is used all day. Those are real cases and they are rarer than they seem in a specification. If you are not clearly in one, the mini-program is worth building first, and it tells you whether the application anybody asked for would have been used.
What breaks when a European application is simply recompiled
- Everything resting on Google services. Push notifications, maps, sign-in, location, crash reporting, the store's own billing: these are not part of Android, they are a layer that is absent from the devices your users have. Each one needs a local replacement, and push needs one per manufacturer.
- Anything loaded from outside the country. Fonts, scripts, analytics, images on a foreign content network, an embedded map, a video player: each one is a request that may be slow or may not complete, and a screen that waits for all of them never appears.
- Sign-in and payment. An account created with an email address and a password, paid for with a foreign card, describes a user who does not exist here. Expect a phone number as the identity and a local payment method as the only one, and treat both as part of the product rather than as integrations.
- Permissions and privacy declarations. Local rules and store reviews both look closely at what an application asks for and whether it needs it. A permission requested at launch « to improve the experience » is a rejection in several stores and a problem in all of them.
- The device mix. Screen shapes, system versions, manufacturer modifications to Android and aggressive battery management vary more than the European range an application was tested against. Background work in particular behaves differently, and it behaves differently per brand.
Taken together, these are not a port but a version. The honest way to plan it is to treat the Chinese release as its own product with its own test devices, its own identity and payment design, and its own release calendar — and to start by deciding, with that cost in front of you, whether a mini-program would have done the job.
Settle the entity question before anything technical. Which registered company publishes decides which stores you can use, whose name is on the listing, who holds the signing key, and who owns the users — and it is the decision that is most painful to reverse once an application has been downloaded under somebody else's name.