How to publish an app on the App Store and Google Play

To get an app into the stores you need a developer account in App Store Connect and Google Play Console, a build made with current SDKs, a declaration of the data you collect and a privacy policy. New personal Google Play accounts must run a closed test before production access: at least 12 testers opted in continuously for 14 days. Apple reviews most submissions in under a day, while Google takes up to seven days for some accounts.

What you need before you can publish

You need two developer accounts — one in the Apple Developer Program and one on Google Play — plus proof of the legal entity if you enrol as an organization. The first decision comes before the code: whose name the app ships under. The account defines who owns the product, who receives payouts, who sees the statistics and who can release updates, so for a commercial app it is registered to the owner's legal entity, not to an employee and not to a contractor.

A D-U-N-S Number is issued by Dun & Bradstreet and should be requested early: without it an organization cannot enrol in either programme. If the company details in the profile drift apart from the agency record, Google gives a deadline to fix them and then restricts the account and pulls the apps from the store.

• $99 per year — membership in the Apple Developer Program
• $25 one-off — developer account registration on Google Play
• 12 testers for 14 days in a row — the closed test for new personal Google Play accounts
• 90% of submissions are reviewed by Apple in less than 24 hours

Closed testing on Google Play: 12 people and 14 days

Personal Google Play accounts created after 13 November 2023 must run a closed test before production access: at least 12 testers opted in continuously for no less than 14 days. This is the most common reason release plans slip for teams that learn about the rule at the last moment.

Only testers who stayed in for all 14 days in a row count: somebody who opts in and drops out early does not. Once the condition is met, you apply for production access in Play Console and answer questions about how the testing went and how ready the app is.

Tip Build the tester list in parallel with development rather than after it: you need real Google accounts willing to keep the app installed for two weeks. Employees, partners and loyal customers work; random addresses do not.

The rule applies to personal accounts. Google does not impose it on organization accounts — one more argument for registering the product to a company.

Android developer verification: who it affects

Google is introducing identity verification for developers whose apps are installed on certified Android devices — not only for those who publish on Google Play. The rules and dates are on the Android developer verification page.

• From 30 September 2026 the requirement will apply in Brazil, Indonesia, Singapore and Thailand, including third-party app stores.
• Google then plans to extend the check to certified devices worldwide starting in 2027.
• Developers who publish on Google Play verify through Play Console; those who distribute an app file outside the store need the separate Android Developer Console.
• Students and hobby projects can use a limited distribution account: up to 20 devices, with no government ID and no registration fee.

The takeaway for a business is simple: even if you plan to distribute the app by link or from your own website, the product owner still has to confirm their identity or legal entity.

What to check before you submit

Most rejections have nothing to do with the code: the reviewer could not use the app or could not find mandatory information. This list closes the usual grounds for a rejection.

• A test account with a password, a confirmation code and short instructions, if some features are only available after sign-in.
• Account deletion inside the app: rule 5.1.1(v) of the App Store Review Guidelines requires it wherever sign-up exists.
• A privacy policy at a live URL that describes how the app actually behaves.
• Permission prompts: camera, location, microphone, contacts — only the ones a feature cannot work without, each with a clear explanation.
• A build made with current SDKs and target API levels: the versions and dates are covered in the article on mobile app development for iOS and Android.
• The store listing: name, description, icon, screenshots, category, age rating, support contacts.
• Completed data declarations in both stores.
• No unfinished screens, placeholders or links leading nowhere.

How to prepare the store listing

Two people read a store listing: the reviewer and the future customer. The first needs the description to match the features, the second needs to grasp in a few seconds why the app is worth installing.

• The name — short, with no keyword stuffing and no other companies' trademarks.
• The short description — one sentence on the problem the app solves and for whom.
• The full description — scenarios and features, not general claims about service quality.
• The icon — recognisable at a small size, without fine print and without a screenshot of the interface.
• Screenshots — the first answers what the app does, the rest show one scenario per frame.
• Category, age rating, support contacts and a link to the privacy policy.

For the Uzbek market the listing is filled in at least in two languages, Uzbek and Russian, and often in English as well. Write the text for each language separately: machine translation in a description is obvious and costs you trust.

Data declarations: App Privacy and Data safety

Both stores require the developer to describe what data the app collects — including data gathered by the third-party libraries it embeds.

Apple: App Privacy details are required to submit new apps and updates. You are answerable for the analytics and advertising SDKs whose code you added, and you must keep the answers current when your practices change.

Google: the Data safety form is filled in by the developer, who is also responsible for its accuracy. When Google spots a discrepancy between app behaviour and the declaration, it can block updates or remove the app from the store.

Draw up the data list together with whoever builds the server side: part of the information leaves the app not directly but through the backend and external services, and that belongs in the declaration too.

In-app purchases: when IAP is mandatory and when Payme and Click apply

Both stores follow the same logic: digital goods consumed inside the app go through in-app purchases, while physical and offline ones use ordinary payment methods. For products from Uzbekistan this is the least obvious part of the rules, and the one teams trip over on their first submission.

• Subscriptions, premium features, in-game currency and access to content inside the app are sold only through in-app purchases. Your own unlocking mechanisms — licence keys, QR codes, cryptocurrency — are banned by rule 3.1.1 of the App Store Review Guidelines.
• Physical goods and services a person receives outside the app — food, delivery, a salon booking, tickets — must be paid for by other means: rule 3.1.3(e) explicitly forbids using in-app purchase for them.
• Google Play draws the same line: its billing system is required for digital goods and subscriptions inside the app and does not apply to physical goods, transport, food delivery or bill payments.

For an online shop, a delivery service, a clinic or a salon this means payments run through Payme, Click or bank acquiring, and the store commission does not apply to them. How card payments are wired into a cross-platform app is covered in the article “Native or cross-platform development”.

If the product does sell digital access, calculate the commission up front. Under the Small Business Program Apple charges 15% to developers whose proceeds in the previous calendar year stayed below $1 million, and to everyone new to the App Store.

How long review takes and what gets rejected

Apple states it plainly: on average 90% of submissions are reviewed in less than 24 hours. Google warns that for certain accounts and apps review takes up to seven days, or longer in exceptional cases.

Neither store gives a guarantee, so a launch date is never tied to an event or an ad campaign without room for feedback and a second submission.

A rejection does not mean the product is bad. The reviewer's reply names the rule and usually the screen or feature involved; the job is to fix it and resubmit.

How to ship updates

After the first release every new version goes through review again, so updates follow one repeatable order.

1. Build a release candidate and run it on an internal or closed testing track.
2. Update the store listing and the data declarations if features or collected data have changed.
3. Submit for review early, leaving room for feedback and a second submission.
4. Roll out gradually: a small share of users first, then wider.
5. Watch crashes, reviews and metrics; halt the rollout and return to the previous version if something breaks.
6. Open the update to the whole audience and reply to reviews in the listing.

Both stores let you separate approval from release: wait until the version passes review and publish it on the day you need. That helps when a release is tied to a promotion or to the launch of a new service.

How we handle publishing

At Syntra Systems we prepare the builds, fill in the listings and data sections, set up testing tracks, assemble the closed test and handle correspondence with review until approval. Developer accounts are registered to the client's company: the app, the statistics and the payouts stay with the business, not with the contractor.

If the stores are not needed for the task — say you only need registration, bookings or incoming requests — the same job is done by a personal cabinet inside Telegram: no installation, no fees, no review. We build a bot for requests and bookings from $1,200.

Frequently asked questions