How to Publish an App on the App Store and Google Play: A Business Guide

A finished app is not yet an app in the store. Between your final build and the icon on a user's screen sit two review pipelines, each with its own rules, and breaking even a minor clause can push your release back by days or sometimes weeks. Below is a practical breakdown of the entire path: from setting up developer accounts to passing review and supporting the app after launch.

Developer accounts: where it all begins

Publishing is impossible without a developer account in each store. This is not a formality: it is exactly where Uzbekistan-based teams most often get stuck, because registration requires a valid payment and sometimes legal documents.

• Apple Developer Program — 99 USD per year, renewed annually. You can register as an individual or as an organization. For an organization, Apple requires a D-U-N-S Number, an international company identifier that is issued free of charge, but processing it takes anywhere from a few days to a couple of weeks.
• Google Play Console — a one-time 25 USD, with no annual renewals. Since 2023 Google has tightened verification: new personal accounts must confirm identity with documents, and before the first publication you may be required to test the app with at least 12 real testers over 14 days.

Paying from Uzbekistan: the first practical barrier

Both programs are paid for with an international card. In practice, Uzbekistan-issued Visa/Mastercard cards do not always go through for Apple, and Google requires the payment profile to match the account's country. This is solvable, but budget time for possible bank declines and retries. We recommend preparing accounts early, during the development stage, so the payment question does not turn into a blocker right before release.

What to prepare for publication

The build itself is only part of the package. Both stores require a full set of supporting materials, and an incomplete set is a frequent cause of delays.

• Icon and screenshots for every required screen size; for iOS, separately for iPhone and iPad if the app supports them.
• Description, keywords, category — ideally localized for your audience (Uzbek, Russian, English).
• Privacy policy — mandatory, with a link to a working page. Without it you will not pass.
• Data declarations — Apple App Privacy (the "nutrition labels" describing what data is collected) and Google Data Safety. Fill them in honestly: any mismatch with the app's actual behavior is grounds for rejection.
• Age rating via the store's questionnaire.

Common reasons for rejection

Most rejections are predictable and repeat from project to project. Knowing them in advance lets your release pass on the first try.

• Broken or incomplete demo access. If the app has a login, give the reviewer a working test account in the App Review Information field. No access means a near-guaranteed rejection.
• Payments bypassing the store. Selling digital content and subscriptions inside the app must go through In-App Purchase on Apple. A link to external payment for digital goods means rejection.
• Broken features and crashes. The reviewer actually taps through the app; a crash on launch is an instant rejection.
• Requesting excessive permissions (camera, location, contacts) without a clear explanation in the request text.
• Mismatch between the data declaration and actual data sent to third-party SDKs (analytics, ads).

Timelines: what to plan for

Real timelines depend heavily on how ready your materials are and whether you hit a typical rejection.

• App Store: review is usually 24–48 hours, but the first publication on a new account can take longer. Every rejection means another round in the queue.
• Google Play: for new personal accounts, a 14-day closed test plus review means a release realistically takes 2–3 weeks from zero. Updates to an existing app are faster, often within hours to a day.

A reasonable estimate for a business: budget 2–4 weeks from a finished build to publication in both stores, allowing for one possible revision cycle.

After publication: this is not the finish line

The store is a living environment. Apple and Google regularly raise the minimum SDK version: an app that has not been updated to the new target API stops being accepted for updates and, over time, gets hidden from search. So publication is the start of a support cycle, not its end.

Support includes: responding to reviews and ratings, releasing updates for new OS versions, tracking crashes and metrics, and answering review queries when rules change. For a business, this means the app needs a process owner, and account access should be registered to the company, not to a developer who has since left.