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

The app is ready, the launch has a date and the campaign is already paid for. Then the app gets stuck in Apple's review, or Google asks for two weeks of testing nobody put on the schedule. Publishing to the stores isn't a click at the end of the project. It's a step with its own rules, company documents and timelines that don't depend on the developers.

And the rules changed again. Since September 30, 2026, Brazil is one of the first four countries where Android requires every app to come from a verified developer. In this article I show what each store asks for, how long each step takes and what you need to sort out before the code is ready.

What you need before submitting the app

Two developer accounts, one in each store. They're the registration that lets you publish and get paid.

• Apple Developer Program: US$99 a year, according to Apple's enrollment page. The fee shows in local currency when you sign up.
• Google Play Console: a one-time fee of US$25, according to Play Console Help. Prepaid cards aren't accepted, and if your identity details are rejected, the fee isn't refunded.

If the app belongs to your company, both accounts should be organization accounts, not individual ones. That's where requirements come in that catch a lot of people off guard:

• D-U-N-S number. Apple uses it to confirm the company's identity, legal status and address. Google is blunter: without a D-U-N-S, you can't create an organization account. The number is free, but it isn't issued instantly.
• Registered company. Apple doesn't accept trade names or branches. The account belongs to the legal entity that signs contracts.
• Live website and email on the domain. Apple requires a public, working website on a domain tied to the company. A social media page or a near-empty site won't do. The email of the person enrolling must be on the same domain.
• Verified phone and email. Google confirms them with a code and requires them to keep working for as long as the account exists.

A rule I repeat on every project: the accounts stay under the client's CNPJ. Whoever owns the account owns the app in the store, the reviews and the download history. If the development company publishes on its own account, switching vendors later becomes a bureaucratic transfer, and sometimes a fight.

How long Apple's review takes

Every app and every update goes through a person on Apple's review team. According to the App Review page, Apple reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours.

The queue is short. The problem is rejection. In its 2025 transparency report, Apple says it reviewed 9,100,620 submissions and rejected 2,093,244, about 23%. Only 387,087 were approved after an initial rejection. Every rejection means fixing, resubmitting and going back into the queue.

Why Apple rejects apps (and how to avoid it)

The same report breaks down rejections by guideline section. A submission can be rejected for more than one reason, so the numbers add up to more than the total:

• Performance: 1,354,418. By far the biggest cause. It covers apps that crash, broken links, features that don't work and apps that look unfinished.
• Legal: 495,673. Privacy, data collection without notice, usage rights.
• Design: 415,532. Apps that just repeat a website, copies of other apps, poor experience.
• Business: 283,820. Payment methods outside the store's rules.
• Safety: 151,159. Objectionable content, lack of moderation for user-generated content.

Almost all of this can be fixed before submitting. What's usually missing on the first submission:

1. A test account for the reviewer. If the app has a login, Apple needs a username and password that work. Without them, the reviewer can't get past the first screen.
2. A published privacy policy that matches what the app actually collects.
3. An option to delete the account inside the app, for apps that let users create one.
4. No buttons that do nothing. “Coming soon” screens and links to empty pages are a common reason for rejection.
5. Payments within the rules. If the app sells something digital, the payment rules change the flow. I explained what pays a commission and what doesn't in App Store and Google Play fees.

The 14 days Google Play may require

With Google, the deadline that catches people off guard comes before review. According to Play Console Help, personal accounts created after November 13, 2023 must run a closed test with at least 12 testers, opted in continuously for at least 14 days, before releasing the app to the public.

That's two weeks you can't compress. And 12 real people with Android phones who accept the invite and stay in the test the whole time. If one drops out midway, the count may come up short.

This requirement applies to personal accounts. It's one more reason to open the organization account under the company's CNPJ from the start: besides putting the app in the right name, it follows a different verification path.

What changed on Android on September 30

Until now, Android installed apps without confirming who made them. According to the official Android documentation, since September 30, 2026, developer verification applies to users in Brazil, Indonesia, Singapore and Thailand. Google says the rule goes worldwide in 2027, on all certified Android phones.

There are three steps:

1. Have an Android Developer Console account. If you publish on Google Play, you're registered automatically.
2. Verify your identity, as an individual or as a company, with documents.
3. Register the app's package name, proving ownership with a file signed by the private key.

If your app is only on Google Play, you complete verification through the account you already have. If it's distributed outside the store, say through a direct link for your field team, it's a different story: you need to open the account, verify your identity and register the app. According to TechRepublic, the rule is enforced on certified Android phones, and Google has already said verification will reach all third-party stores.

For companies with an internal app installed outside the store, this goes on the to-do list now.

How much time to set aside

Putting it all together, here's what I recommend planning before launch:

• D-U-N-S and organization accounts: at the start of the project, alongside design. Issuing the number and verifying the company can take days, and they don't depend on code.
• Google Play closed test: 14 days, if the account is personal and new. Start as soon as there's a stable build.
• Apple review: the queue is one to two days, but set aside a week to absorb a rejection.
• Store copy, images and privacy: description, screenshots, icon and the data collection form in both stores. This is part of the scope, not a last-minute detail.

Publishing time is not the same as development time. I showed how each project step weighs on the calendar in how long it takes to build an app. The launch date you announce has to account for both.

What this means for you

If you're hiring someone to build an app, put publishing in the contract. Three questions to ask whoever will build it:

1. Whose name are the store accounts in? The right answer: your company's CNPJ.
2. Who prepares the submission and handles rejections? This needs to be in the scope, with a deadline.
3. Does the launch date already account for review and Google's test? If the date is the day the code is ready, it will slip.

At the Studio, publishing is part of the project from discovery onward. The price is fixed and the deadline is written into the contract. Code, files and access stay in the client's name, including the App Store and Google Play accounts. The dev team is in-house, and every system ships with an AI agent that runs daily, flags failures and checks that the data makes sense.

If you have an app to get into the stores, see how we work on app development and bring your launch date to discovery.