App Pre-Release Checklist for Small Teams

This checklist is written for small teams and belongs to our studio notes, which begin with apps that work without an account. It describes the steps, what each one is for and what you can check from the outside, and it points to our own product pages where the results are visible. For how the two big stores differ once a build is ready, see shipping an app to two stores.

The checklist at a glance

1. One job per app, written down first

Before drawing a screen, write one sentence about what the app is for and who it is for. Then write what it does not do. The second list is the more useful one: leaving things out is a design choice, and every item on it is something that cannot go wrong later.

You can see this on our product pages, which carry a short maker’s note. Cuelift was built around one idea: the words you read should sit as close to the camera lens as possible. It has no account, which also means no syncing between devices, and the note says so. Its free takes stop at three minutes, and the note names that trade-off in plain words. Gloomrush is meant to be a game you can open and simply play, and its note states what the game receives and what it does not.

2. Build in small, testable pieces

A small piece is easier to test than a whole app. Decide what “done” means for each piece before you start, check it on its own, and only then move on. If a later test fails, the cause is likely in the most recent piece.

Keep the standards you care about on the same list as the features. Accessibility, speed and privacy are cheaper to check as each piece arrives than to repair after the app is assembled. For accessibility, our mobile app accessibility checklist gives a short list and a ten-minute test.

3. Real devices, then a small group

An app that works in one place can fail in another. Run the finished build on real phones, and include an older phone if you can: look at launch, text size, rotation, interruptions such as a call, and what happens with no connection.

Then use what the stores give any team to put the build in front of a small group before the public sees it.

• Apple TestFlight. It lets testers give feedback on apps across Apple platforms before you publish. Apple lets you name up to 100 members of your development team as internal testers. External testers need a beta description, and your first build goes through App Review for TestFlight.
• Google Play testing tracks. Internal testing suits quick checks with a small group of up to 100 testers. Closed testing reaches a limited, targeted group. Open testing makes a test version visible on Google Play to a large group.

Both are options open to any team, and neither replaces your own tests. They give you a place to find what you missed with people who will tell you.

4. Text that matches the version

An app is more than its code. A release also needs the words that describe it, and those words have to be true for the version in your hand. There are three places where they must agree: the declarations in the store, the privacy notice and the app itself.

Both stores place the responsibility on the developer. Apple requires privacy details to submit new apps and app updates, and says you are responsible for keeping them accurate and up to date. Google requires the Data safety section for apps on closed, open or production tracks, and apps that are only on internal testing are exempt. Google also says that it reviews submissions but that its process is not designed to verify the accuracy and completeness of your declarations. That makes your own check the real one. For the reader’s side of these labels, see our guide to reading app privacy labels.

Write the notice for each product and for each version where the behaviour changes. Cuelift’s privacy notice says that versions before 1.0.7 collect no analytics or crash reports, that from 1.0.7 the app sends them, and that from 1.0.8 it asks for consent in some regions, with a separate switch for each in Settings. A reader on any version can find the sentence that applies to them.

Before release, ask five questions of the build:

1. Does the notice describe what this version does, including anything new?
2. Do the store declarations match the notice?
3. Does the app ask permission only for what it uses?
4. Does the support page answer the first questions people will have?
5. Is there a contact address that gets read?

Whether a declaration meets a particular law is a question for a qualified adviser; this list covers only the practical steps.

5. Store listing, screenshots and release note

Publishing is part of the job. A listing needs a plain description, screenshots, and the facts a person checks before installing: the age rating, the minimum system version and the languages. For example, WisyLink’s page lists iOS 15.1 or later and Android 7.0 or later, and Gloomrush’s lists English and Turkish. Give each screenshot a written description, which helps people who use a screen reader and anyone whose images do not load.

A release note is where a small update explains itself. Two examples from our product pages: the WisyLink 1.4.7 note lists clearer wording through the app, domain setup that shows the correct records and explains verification problems in your language, and attachment-only messages that now send reliably. The Gloomrush 1.0.8 note describes one quick question, “Are you 13 or older?”, replacing the birth-year question, with the answer kept on your device. Each is a change a reader can take in with one sentence.

6. After release: feedback, support and small updates

A release is where learning starts. Read feedback and reviews, answer the messages people send, and test what you shipped. Small, regular updates are easier to check than rare large ones, and a fix that arrives with a clear note builds more trust than a silent one.

Give each product a support page that collects the questions people really ask and the replies, such as how to add a widget, what to do when a purchase has not unlocked, or what to do when the camera or microphone does not work. Add an address for the rest. Our contact page is the route for the studio as a whole.

What a checklist should leave out

A checklist can promise too much. Four things to leave out of yours:

• Promises about store timing. Review times are the store’s to state, and they change.
• Ratings and counts. Do not quote ratings, downloads or user numbers unless you can source them.
• Features the app does not need. Step 1 applies to every step after it.
• Claims you cannot check. If a line on the list cannot be verified from outside, it is a promise and not a checklist item.

If you want to see what a finished release looks like from the outside, open any product in the Store and read its page from the top: the job, how it works, the privacy summary and the support page.

Questions

What should be on an app release checklist?

One written job, small pieces tested one by one, real devices, privacy and support text that match this version, a store listing with a release note, and a routine for feedback and small updates afterwards.

How do you test an app before release?

Test each piece as you build it, then the whole app on real phones. Before the public sees it, put the build in front of a small group using TestFlight on Apple platforms or an internal, closed or open testing track on Google Play.

Do privacy declarations have to be ready before release?

Apple requires privacy details to submit new apps and updates. Google requires the Data safety form for apps on closed, open or production tracks, but not for apps only on internal testing. Both put accuracy on the developer.

Why do apps ship small updates so often?

Small updates are easier to test and easier to explain. A short release note lets people judge an update in a sentence, and a small change leaves fewer places to look when something goes wrong.

What does an app’s store page tell me before I install?

A good page gives a description, screenshots with descriptions, a privacy summary and policy link, an age rating, the minimum system version, the languages and a contact route. Our product pages carry all of these.