Before you start: developer accounts
An app is published from a developer account – and that account should belong to you or your company, not to the contractor. The contractor gets access to it as a team member. That way the app, its ratings and its users always stay with you.
| Apple App Store | Google Play | |
|---|---|---|
| Programme | Apple Developer Program | Google Play Console |
| Fee | annual (USD 99 or equivalent) | one-off (USD 25) |
| Company account | requires a D-U-N-S number | requires a D-U-N-S number |
| Pre-release testing | TestFlight | internal, closed and open testing tracks |
Fees and requirements are given as of the time of writing – both stores update them from time to time.
Step 1: D-U-N-S number and company verification
If you publish as a company, Apple and Google will ask for a D-U-N-S number – an international business identifier. Getting one is free, but it can take anywhere from a few days to a few weeks, so it's worth starting with this step while the app is still being built.
The company details in the application must match those in the official registers – discrepancies in the name or address are the most common cause of delays.
Step 2: store materials
- the app's name and subtitle and a description – naturally using the words users search for (the stores' "SEO", known as ASO),
- an icon in the required sizes,
- screenshots for phones (and tablets, if the app supports them),
- category and age rating – based on a questionnaire in the store's console,
- a privacy policy URL – required in both stores,
- support contact details.
Step 3: privacy and data
Both stores require you to describe what data the app collects and why: Apple in the App Privacy section, Google in the Data safety section. The declaration has to match what the app actually does – including third-party libraries such as analytics or ads.
If users can create an account in the app, they must also be able to delete it – that's a requirement in both stores.
Step 4: testing before release
On iOS, test builds are shared through TestFlight – testers install the app before it reaches the App Store.
In Google Play, testing tracks serve this purpose. Note: new personal accounts in Google Play must run a closed test with at least 12 testers for 14 days before publishing. Company accounts don't have this requirement – another argument for publishing as a company.
Step 5: submitting for review
We build the app in its production version, sign it and submit it to the stores. Apple's and Google's teams then check it against their guidelines.
In the App Store most submissions are reviewed within a day, although the first release can take longer. In Google Play the first review of a new app can also take a few days. It's worth planning some slack before the launch date.
The most common reasons for rejection
- Bugs and crashes – the app freezes or doesn't work during the reviewer's test.
- No sign-in details – if the app requires an account, the reviewer has to be given a test account.
- Incomplete or inconsistent privacy information.
- Too little functionality – Apple rejects apps that are just a "wrapped" website.
- Payments that bypass the store's system – digital content and subscriptions in the app are subject to special rules.
- Metadata – screenshots that don't match the app, references to another platform, false promises in the description.
A rejection isn't the end of the world. You're told which guideline was breached – after fixing it, you submit the app again.
After release
Release is the beginning, not the end. Apple and Google release new system versions every year and raise the minimum requirements for apps that receive updates, so the app has to be updated regularly. On top of that come error monitoring, replying to reviews and development based on user behaviour.
We take apps through this whole process – from design to release and ongoing maintenance. More on the mobile apps page. We cover what the whole journey costs in the article how much does a mobile app cost.
Related services: mobile apps.