How to Publish an App to the App Store and Google Play

By Cody Wise, founder of Wise Media. Wise Media builds and ships apps and web platforms for Canadian founders. Fees and policy requirements below are quoted from Apple’s and Google’s own published developer documentation as of November 2026 and are listed by those companies in US dollars unless stated otherwise. Store policies change often, so verify against the linked source before you plan a launch date.

Summary

Most teams treat app store submission as the last afternoon of a project. It is not. It is a separate workstream with its own identity verification, its own paperwork, its own waiting periods and its own failure modes, and almost all of it can be done in parallel with development instead of after it.

• Two accounts, two models. Apple charges annually and verifies organizations through D-U-N-S. Google charges once and verifies identity at signup, but requires D-U-N-S before an organization account can be created at all.
• The D-U-N-S number is the long pole. Google states the application process through Dun & Bradstreet “can take up to 30 days.” It is free. Start it on day one.
• New personal Google Play accounts cannot publish immediately. Accounts registered as individuals after mid-November 2023 need a closed test with a minimum of 12 testers opted in continuously for at least 14 days before they can apply for production access.
• Most rejections are completeness failures, not policy failures. Apple’s guideline 2.1 rejects placeholder content, broken links, missing demo accounts and offline back ends before a reviewer ever considers what your app does.
• Neither company publishes a committed review time. Anyone quoting you a guaranteed 24-hour review is quoting a blog post, not a vendor commitment.
• A privacy policy is mandatory, not optional. Apple requires a link in App Store Connect metadata and inside the app itself.

If you are still deciding whether you need a native app at all, read mobile app vs mobile website first. Everything below assumes the decision is made. If it is made and you want the build and the submission handled as one piece of work, that is what our app development service exists for.

Table of contents

1. What the developer accounts cost and who can open them
2. The D-U-N-S number, and why it decides your launch date
3. Why a new Google Play account cannot publish right away
4. What actually gets apps rejected
5. How long review takes, honestly
6. The submission sequence, start to finish
7. Common mistakes
8. What the whole thing costs in CAD
9. FAQ

What do the developer accounts cost and who can open them?

Apple and Google both gate publishing behind a paid, verified account, but they price and verify it in opposite ways. Apple charges every year and is strict about who the legal publisher is. Google charges once and is strict about whether you are a real, reachable organization.

The Apple Developer Program

Apple’s program page lists a “$99 annual membership”. That membership is what lets you distribute on the App Store at all, and it also carries TestFlight for beta builds, App Store Connect analytics and sales reporting, and code-level technical support. It renews annually, so treat it as a recurring line item for the life of the app, not a launch cost.

The decision that matters here is not the fee. It is whether you enroll as an individual or as your organization. Enrolling as an individual is faster and lists your personal legal name as the seller on the App Store. Enrolling as an organization lists the company and keeps the account transferable when a staff member leaves. For any business that intends to sell, raise, or be acquired, enroll the company.

The Google Play Console

Google’s developer help states plainly: “There is a US$25 one-time registration fee.” Prepaid cards are not accepted. Google also asks you to complete identity verification during signup, and the same page warns that if the information you provide is judged invalid, the registration fee is not refunded. That is worth reading twice before you type a name that does not match your government ID.

Individual or organization: pick once, carefully

On Google Play this choice is close to irreversible in practice and it changes what you have to produce. An organization account requires, per Google’s own requirements page, a D-U-N-S number on the linked Google Payments profile, the organization name and address, an organization phone number and website, a contact name, email and phone for Google to reach you, and a developer email and phone that appear on your public Play developer profile. Those contact details “must be verified using a one-time password and remain operational for the duration of your developer account.”

One more structural question belongs here, before either account exists: who owns the code and the signing keys once the build is done. If an agency enrolls in its own name and holds the keystore, you do not control your own listing. We wrote the Canadian version of that problem in who owns the code when you hire an app developer. Settle it in the contract, not after launch.

The D-U-N-S number, and why it decides your launch date

A D-U-N-S number is a unique nine-digit business identifier assigned by Dun & Bradstreet. Google describes it as “a unique nine-digit identifier” and confirms that “applying for a D-U-N-S number through Dun & Bradstreet is a completely free process.” Google also says the quiet part out loud: “This process can take up to 30 days so you should plan ahead,” and “You will not be able to create a developer account for an organization without one.”

That single sentence is the most common reason a Canadian app launch slips a month. The build is finished, marketing is booked, and nobody can open the publisher account.

• Check first, do not apply blindly. Google explicitly tells you to check whether your organization already has a number before requesting a new one. Many incorporated Canadian businesses already do, especially if they have ever had commercial credit pulled.
• Never pay a third party for one. Google calls the process free and warns about services that charge. If someone quotes you a fee to obtain a D-U-N-S number, that is the fee, not the number.
• Make the names match exactly. Google requires that the legal name and address in your Google Payments profile “match those in your Dun & Bradstreet profile.” A mismatch triggers a banner in Play Console with a deadline, and Google states that failing to fix it means your account “may be restricted, which would remove all of your apps from Google Play.”
• Large companies may have several. Use the one whose registered details match the entity that should appear as the publisher.
• There is a narrow exception. If Dun & Bradstreet does not support your region, Google says you can contact Play support for an alternative verification method, but only organizations genuinely unable to obtain a number qualify, and incomplete requests are not considered.

Practical sequencing: start the D-U-N-S application the same week you approve the app scope. It costs nothing, it runs in the background, and it is the only item on this page with a stated 30-day ceiling.

Why can a new Google Play account not publish right away?

Because Google added a testing gate to fight low-quality and fraudulent listings. If your Play account is registered as an individual and was opened after mid-November 2023, you must run a closed test before you can even apply for production access. Google’s requirement is “a minimum of 12 testers who have been opted in continuously for at least 14 days.”

Read that carefully, because three words in it cause most of the failures.

• “Minimum of 12.” Not 12 email addresses you added. Twelve people who actually accepted the opt-in. Invite more than 12, because some will not click.
• “Opted in continuously.” If a tester leaves the programme partway through, the clock for your qualifying count is affected. Do not let people opt out mid-test to free up a device.
• “At least 14 days.” The window runs in calendar days from opt-in, so the fourteen days cannot be compressed by testing harder.

Note what this rule does not say. It applies to accounts registered as individuals. If you are a real incorporated business, an organization account is both the correct publisher and the route that avoids this particular waiting period, which is another reason to get the D-U-N-S number moving early rather than opening a personal account to save time. Confirm the current terms on Google’s closed testing requirements page before you plan around it, because this is one of the rules Google has already changed once.

There is an upside worth taking. Fourteen days with a dozen real users on real devices is the cheapest bug-finding exercise you will ever run. Treat it as a structured beta with a feedback form and a crash reporter, not as a box to tick.

What actually gets apps rejected?

Not what most founders fear. The usual assumption is that review is a judgement call about whether your idea is good enough. In practice the overwhelming majority of first rejections are mechanical: something was incomplete, unreachable, or undocumented. Apple’s App Review help page states that review covers every submission, including app updates, bundles, in-app purchases, in-app events and App Store metadata, to confirm submissions are “safe, secure, and reliable.”

Guideline 2.1: App Completeness

This is the one that catches small teams. Apple’s App Store Review Guidelines require that submissions “should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission.” Apple then says it plainly: “We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.”

Guideline 2.1 also requires a working demo account when your app has a login, with the back end turned on, and it requires that in-app purchases be “complete, up-to-date, visible to the reviewer and functional.” If a reviewer cannot find a purchase you configured, Apple expects you to explain why in the review notes.

Guideline 4.2: Minimum Functionality

This is the one that kills the “just wrap our website” plan. Apple writes: “Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or ‘app-like,’ it doesn’t belong on the App Store.” Guideline 4.2.2 adds that “other than catalogs, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links,” and 4.2.3(i) requires that “your app should work on its own without requiring installation of another app to function.”

If your planned app is a wrapper around pages you already have, this guideline is a hard stop, and it is the single strongest argument for fixing the mobile website instead. That trade-off is the whole subject of our app versus mobile website comparison, and 4.2 is why the decision has a technical answer rather than a preference.

Guideline 5.1.1: privacy policy and data handling

Apple requires that “all apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner.” The policy must identify what data the app collects, how it collects it and every use of that data; confirm that third parties receiving user data provide equal protection; and explain data retention and deletion, including how a user revokes consent or requests deletion.

For a Canadian business this is not only an Apple requirement. The same disclosure discipline is what PIPEDA’s identifying-purposes and consent principles expect of any commercial collection of personal information, so write one policy that satisfies both rather than a store-shaped one. If your app touches customer records, the security side of that obligation is worth reading alongside what a Canadian small business actually needs for cyber security.

What blocks a Google Play release

Google’s publishing guidance is less about taste and more about declarations. Two things reliably stall a release. First, errors in the Play Console: Google states “you can’t publish your app until errors are resolved,” while warnings do not block you. Second, sensitive permissions. If your app requests high-risk permissions such as SMS or Call Log, Google says “you might need to complete the Permissions Declaration Form and receive approval from Google Play.” That approval is a separate queue on top of review.

The practical lesson: audit your manifest for permissions you do not actually use before you submit. An unused permission inherited from a library can add a declaration round trip for a feature you never shipped.

Pre-submission checklist

• Every URL in the listing and inside the app resolves, including the privacy policy and support URL
• No placeholder copy, no lorem text, no empty states that look broken
• A working demo account with the back end live for the whole review window
• Review notes explaining anything non-obvious, including how to reach gated features
• In-app purchases configured, visible and testable
• Privacy policy linked in store metadata and reachable inside the app
• Data collection disclosures filled in and matching what the app actually does
• Manifest permissions reduced to what the app genuinely uses
• Permissions Declaration Form completed if any sensitive permission remains
• Tested on physical devices, not only the simulator
• Age rating questionnaire answered accurately
• Contact email and phone on the developer account live and monitored

How long does app review actually take?

Neither Apple nor Google publishes a committed review turnaround, and this article is not going to invent one. Apple’s guidelines say following the submission checklist helps an app “go through the review process quickly” without stating a duration. Google’s publishing overview names factors that extend a release, including unresolved console errors and permissions declarations, again without a stated window.

So plan against the things that are documented instead of against a number someone repeated on a forum.

1. Assume at least one rejection. Build a round trip into the plan. A rejection is a message in the review thread, a fix, and a resubmission, and the queue starts again.
2. Do not book launch marketing against a review date. Book it against a confirmed live listing. This is the mistake that costs real money.
3. Submit well before any hard date. If a conference, a seasonal window or a client launch depends on it, submit weeks early and hold the release manually.
4. Use phased or manual release. Both stores let you approve the build and then choose when it goes live, which separates review risk from launch timing entirely.
5. Keep the review channel staffed. A reviewer question that sits unanswered for three days is three days added for free.

Apple does document escalation paths that are worth knowing before you need them: requesting an expedited review, accepting a bug-fix submission offer, and appealing to the App Review Board. The entry points are listed on Apple’s App Review help index. Expedited review is a courtesy for genuine urgency, not a lever to pull on every build.

The submission sequence, start to finish

This is the order that keeps the waiting periods running in parallel instead of in series. Run it alongside development, not after it.

1. Week one: start the D-U-N-S application. Check whether your organization already has a number first. It is free and Google says it can take up to 30 days.
2. Week one: decide the publisher entity. Individual or organization, on both stores, and get it into the development contract alongside code and keystore ownership.
3. Week one: open the Apple Developer Program enrollment. Pay the annual membership and complete identity verification so App Store Connect is ready when the build is.
4. Week two: register the Play Console account. Pay the one-time fee, complete identity verification, and verify the contact and developer email and phone by one-time password.
5. Week two: write the privacy policy and publish it at a permanent URL. Both stores need to reach it, and Apple needs it linked inside the app too.
6. Weeks two to four: prepare listing assets. Screenshots per required device size, icon, description, keywords, support URL, age rating answers, and the data collection disclosures.
7. Weeks three to six: run the closed test if your Play account requires it. Invite more than 12 people, confirm 12 opted in, and leave them in for the full 14 days.
8. Before submitting: run the pre-submission checklist above. Demo account live, URLs resolving, placeholder copy gone, permissions trimmed.
9. Submit with review notes. Explain anything a stranger could not discover in two minutes, and include credentials for gated areas.
10. Hold the release. Approve the build, then release manually on your own date.

Four to eight weeks from finished build to live listing is a realistic planning assumption for a first app from a new publisher account. A second release from an established account with the paperwork already in place is dramatically faster, which is the real argument for setting the accounts up properly once.

Common mistakes

• Leaving the developer accounts to the end. The accounts carry the identity verification and the 30-day D-U-N-S ceiling. They belong at the start of the project.
• Letting the agency publish under its own account. You end up renting your own listing, reviews and install base.
• Opening a personal Play account to skip paperwork. It trades a 30-day application you can run in the background for a 14-day testing gate you cannot start until the build is testable.
• A privacy policy that lives only in the store listing. Apple wants it reachable inside the app as well.
• Turning off the staging back end during review. A reviewer hitting a dead API gets a rejection under 2.1.
• Shipping a web wrapper. Guideline 4.2 exists specifically for this and it is enforced.
• Mismatched legal names. A Payments profile that does not match the Dun & Bradstreet record puts the whole account at risk of restriction, which Google says removes all your apps from Play.
• Permissions nobody uses. An inherited SMS permission can trigger a declaration review for a feature you never built.
• Booking a launch campaign against an expected review date. Neither company promises one.
• No monitored contact address. Google requires the contact details to stay operational for the life of the account, and reviewer questions arrive there.

What does the whole thing cost?

The store fees are the smallest number in the project. Apple lists $99 annually and Google lists US$25 once, both quoted in US dollars on their own pages, so the CAD amount on your statement depends on the exchange rate and your card issuer’s conversion. Budget for the recurring Apple membership for as long as the app is listed. A D-U-N-S number is free from Dun & Bradstreet.

What actually costs money is everything around the submission: the listing assets, the privacy policy, the closed test, the device testing, and the engineering time for one or two rejection round trips. For a planning figure on the build itself, published Canadian agency rates for custom application work are broken down in our custom web app cost guide. Treat submission as its own line item of work rather than something folded into the last sprint for free.

Should you publish to both stores at launch?

Frequently asked questions

How much does it cost to publish an app on the App Store and Google Play?

Apple’s program page lists a $99 annual membership and Google’s developer help lists a US$25 one-time registration fee. Both are quoted in US dollars by the vendors, so the CAD charge depends on the exchange rate at the time of payment. A D-U-N-S number, which organizations need, is free from Dun & Bradstreet.

Do I need a D-U-N-S number to publish an app?

You need one to publish as an organization. Google states you “will not be able to create a developer account for an organization without one,” and Apple requires one for organization enrollment. Individual accounts do not need a D-U-N-S number, but they publish under a personal legal name. Google says the application can take up to 30 days, so start early.

Why can my new Google Play account not publish to production?

If the account is registered as an individual and was opened after mid-November 2023, Google requires a closed test with a minimum of 12 testers opted in continuously for at least 14 days before you can apply for production access. Organization accounts are not subject to that particular individual-account requirement.

How long does App Store review take?

Apple does not publish a committed turnaround, and neither does Google. Both document factors that extend review, such as incomplete submissions, offline back ends and sensitive permission declarations. Plan for at least one rejection round trip and release manually on your own date rather than booking marketing against a predicted review time.

Can I publish an app that is just my website in a wrapper?

Apple’s guideline 4.2 says an app “should include features, content, and UI that elevate it beyond a repackaged website,” and 4.2.2 excludes apps that are primarily web clippings or collections of links. A wrapper is the most predictable rejection on the list. Improve the mobile site instead unless the app adds genuine device-level capability.

Do I need a privacy policy for my app?

Yes. Apple requires a privacy policy link in the App Store Connect metadata field and inside the app in an easily accessible manner, and the policy must state what data is collected, how it is used, how it is retained or deleted, and how a user revokes consent. For a Canadian business, PIPEDA’s identifying-purposes and consent principles point in the same direction, so write one policy that serves both.

Who should own the developer accounts, my company or my developer?

Your company, in every case. The accounts hold the listing, the reviews, the install base and the signing identity. Agreeing that in the contract before work starts is far easier than migrating a published app later.

What is the most common reason apps get rejected?

Incompleteness rather than policy. Apple’s guideline 2.1 rejects placeholder content, non-functional URLs, missing demo credentials, offline back ends and builds that crash, and Apple states it will reject binaries that “crash or exhibit obvious technical problems.” Fix those before you worry about anything more exotic.

Conclusion

App store submission is paperwork with a deadline attached, and the deadlines are not yours. The D-U-N-S application has a 30-day ceiling. A new personal Play account has a 14-day testing floor. Review has no published ceiling at all. The only variable you control is whether those clocks run in parallel from week one or in series after the build is done.

Do the three things that remove most of the risk: open the accounts under your own company at the start of the project, publish the privacy policy before the build is finished, and submit early with a manual release so review timing and launch timing are separate decisions.

Want the build and the submission handled as one piece of work?

Wise Media builds apps and platforms for Canadian founders and ships them to the stores under your company’s own accounts, with the paperwork sequenced so launch dates hold. If you have an app in progress or an idea that needs scoping, tell us what you are building on the Wise Media intake form and we will tell you what the real timeline looks like.