Publishing on the App Store and Google Play: the complete 2026 checklist

Building the app is the part everyone plans for. Publishing it is the part that surprises people, because it is mostly administrative work with strict rules and asynchronous feedback loops. A rejection you could have prevented in ten minutes can cost you a week of calendar time. This guide walks through both stores in the order you actually need it: accounts, assets, declarations, submission, review, and what to do the day after launch.

Before anything else: the two accounts

Both stores require a paid developer account, and both take time to activate. Start this step before your app is finished, not after. You'll need an Apple Developer Program membership and a Google Play Console account.

One decision worth making early: register under your company, not your personal name. Moving an app between accounts later is possible but tedious, and a personal account name shown publicly on your store listing looks amateurish to business customers.

The assets you will be asked for

Both stores ask for roughly the same materials, with different sizes and different tolerance for sloppiness. Prepare all of it in one sitting rather than discovering each requirement mid-submission.

• App icon. A high-resolution square with no transparency and no rounded corners of your own, the stores apply the mask. Avoid small text; at real size it becomes a smudge.
• Screenshots. Several device sizes each, including at least one large phone. These are the single biggest driver of install rate, so annotate them with a short benefit line rather than shipping raw captures.
• Title and subtitle. Short, and indexed by store search. Put the real keyword people type in the title, not a clever brand phrase.
• Description. The first two lines are the ones that get read. Lead with what the app does for the user, not with your company story.
• Feature graphic (Google Play). A wide banner shown in several placements. Keep essential text away from the edges, which get cropped.
• Age rating questionnaire. Answer honestly. An inconsistency between your answers and your actual content is a reliable way to get pulled after launch.

Privacy: the part that gets apps rejected

Both stores now require an explicit, structured account of what data you collect and why. Apple calls it privacy nutrition labels, Google calls it the Data safety section. They are separate forms with separate wording, and both must match what your app really does.

• A reachable privacy policy URL. Required by both, must be live before submission, and must actually describe your app rather than a generic template.
• An accurate data inventory. List every category you collect, including data gathered by analytics or crash reporting SDKs. Third-party libraries collect on your behalf, and it counts as yours.
• Account deletion. If users can create an account in your app, you must offer a way to delete it, reachable from within the app. This is one of the most common late-stage rejections.
• Tracking permission on iOS. If you track users across other companies' apps or sites, you must request permission through the system prompt. Doing it without the prompt gets the app removed.

Testing tracks: never submit straight to production

Both stores give you a staging path, and both are free. Use them, because a bug found by ten testers is cheap and the same bug found by a store reviewer costs you a review cycle.

• TestFlight (Apple). Distribute a build to internal testers almost immediately, or to external testers after a lighter review. Builds expire after 90 days.
• Internal, closed and open testing (Google). Internal testing is nearly instant. Closed testing on a small group is worth running for at least a week before production, and new personal developer accounts may be required to run one.

Whichever track you use, test on at least one small older Android device and one recent iPhone. Those two cover most of the layout and performance surprises.

The submission itself, step by step

• 1. Create the app record. Reserve the name and the bundle or package identifier. That identifier is permanent, you cannot change it after publishing, only ship a new app.
• 2. Upload a signed build. Apple requires a signed archive uploaded from macOS. Google requires an Android App Bundle and a signing key you must never lose; enrol in Play App Signing so Google keeps a copy.
• 3. Fill in the store listing. Title, description, screenshots, category, contact details and support URL.
• 4. Complete the declarations. Privacy, data safety, age rating, ads, export compliance, and the permissions questionnaire if you use sensitive ones.
• 5. Give reviewers a working account. If your app has a login, provide test credentials and, if needed, a short note explaining how to reach the main feature. Skipping this is the single most common cause of a pointless rejection.
• 6. Submit and set the release strategy. Choose manual release if you want to coordinate a launch date, and use a staged rollout on Google Play so a bad build reaches 5% of users rather than all of them.

The rejection reasons you will actually hit

Rejections are normal, including for experienced teams. Almost all of them fall into a handful of buckets.

• Reviewer could not log in. Missing or expired demo credentials, or a login that requires a code sent to your phone.
• Broken links or crashes. A dead support URL or a crash on the reviewer's device version. Test every link in your listing before submitting.
• "Not enough functionality". Apple rejects apps that are essentially a wrapped website with no native value. If you ship a WebView app, add genuine device features and offline behaviour.
• Payments outside the store. Selling digital content that is consumed in the app usually requires in-app purchase. Physical goods and real-world services do not.
• Privacy mismatch. Your declaration says you collect nothing, but an analytics SDK collects a device identifier.
• Metadata problems. Screenshots that do not match the current app, competitor names in the description, or a placeholder still sitting in the text.

When you are rejected, read the exact guideline number cited, fix only that, and reply in the resolution centre with a short factual explanation. Arguing rarely helps; a precise reply almost always does.

After launch: the first thirty days

Being live is the start of the work, not the end. The first month determines how the stores rank you and whether early users stay.

• Watch the crash rate by device. Both consoles report it. Anything above roughly 1% of sessions will suppress your ranking and your reviews.
• Answer every review, fast. Public replies visibly change how a listing reads, and a fixed complaint often becomes an upgraded rating.
• Iterate on the listing, not just the app. Changing the first screenshot or the subtitle can move install rate more than a new feature.
• Ship a small update every few weeks. Freshness is a ranking signal, and a steady cadence keeps review turnaround predictable.
• Bring your own traffic. Store search will not discover you on its own. Your website, your email list and your existing customers are the launch channel.

Where Cadrant fits?

Cadrant helps with the part that comes before submission: getting a real, working app in front of users fast enough that you know what deserves to be published. You describe your screens, your data and your user roles in plain language, iterate on a live app in hours rather than months, and keep ownership of the database in your own Supabase project. When the product has proven itself with real users, you go into the store process with a stable scope instead of guessing.

That order matters. Most first-time publishers submit a scope nobody tested, then spend the review cycles fixing product problems rather than store problems.

The short version

Publishing is a paperwork project with a code dependency. Open both developer accounts early, prepare icon, screenshots, description, privacy policy and data declarations in one pass, run a real testing track before production, and give reviewers a working account with clear instructions. Do that and the review itself is usually the easy part.