If you offer an app for iPhone and Android, you publish it in the Apple App Store and on Google Play. Both stores review every app before it appears, and both ask for a range of details about your company and about the app itself. None of this is rocket science, but it needs preparation and a few decisions only you can make.

This article describes what is involved. The stores’ rules change regularly. What counts is always the current guidelines from Apple and Google.

The accounts: in your company’s name

You need a developer account for each store. The most important rule: the account is in your company’s name, not the developer’s and not a member of staff’s private account. The app in the store belongs to the account it is published in. If you change developers later, the app has to be transferred - possible, but laborious. More on ownership and access in who owns your software?

For a company account, both stores ask for proof of your business:

  • A D-U-N-S number. This is an internationally used identification number for companies. Many businesses already have one without knowing it. If not, one can be applied for. Allow some time for it.
  • Your legally correct company details, exactly as registered.
  • A person authorised to represent the company, or someone the company has authorised to accept the stores’ terms.

You can then give other people access to the account, your developer for instance. That way they work in your account and you stay in control.

Company details: trader status

In the European Union, both stores ask about your trader status. The background is the EU Digital Services Act. Anyone offering apps commercially identifies as a trader, and contact details such as address, phone number and email address are then shown on the app’s page in the store. Decide early which address and phone number should be public there.

Details about the app

Before an app can be submitted, the store needs:

  • Name, subtitle and description, in every language the app is to appear in
  • Screenshots for the different device sizes
  • An app icon in the required formats
  • A privacy policy, available at a web address
  • Details of data use: what data the app collects, for what purpose and whether it is shared with third parties. Apple and Google show these details on the app’s page. They must match what the app actually does, including any embedded services for analytics, advertising or crash reports.
  • An age rating, based on a questionnaire about the content
  • A way for users to get in touch, such as a support address

The texts and images are not just a requirement. They help decide whether someone installs the app. Treat them like an advert, not like a form.

The review

Every app and every new version is reviewed by Apple and Google before it appears. They check whether the app works, whether the details are accurate and whether it meets the guidelines. Common reasons for rejection:

  • The app crashes or is unfinished. Placeholders, dead buttons, empty screens.
  • The reviewers cannot get in. If the app needs a sign-in, provide a test account that works and contains data.
  • The account cannot be deleted. If users can create an account in the app, they generally have to be able to delete it in the app too.
  • Digital content is sold outside the store. Digital content and subscriptions generally go through Apple’s and Google’s payment systems. Different rules apply to goods and services used outside the app.
  • The data-use details do not match the app.
  • The app offers too little. An app that only displays a website is often rejected.

A rejection is no disaster. It comes with a reason, the problem is fixed and the app is resubmitted. Even so, do not plan the launch to the exact day; leave some slack.

Test versions before launch

Both stores offer ways to distribute a test version to a limited group before the app is public. Use them. Real users on real devices find things nobody notices in the office. How an acceptance test works in practice is described in acceptance and test environment.

After launch: upkeep that stays

Publishing does not finish the job. Some things come round regularly:

  • New operating systems. Apple and Google release new versions every year. The app has to be tested on them and often adjusted.
  • New store requirements. Both require apps to be built with current tools and targeted at newer system versions. If that is not kept up, you can no longer publish updates, and on Google Play the app eventually stops showing up for users of new devices.
  • Guidelines and agreements. The stores change their rules and require new terms to be accepted in the account. If nobody does that, releases can stall.
  • Reviews and questions. Users write reviews, and a reply from the publisher gets read.
  • Updates. Fixing bugs, adding features, each time with a fresh review.

Decide who looks after this and who reads the emails from the stores. They go to the account’s address, and some of them come with deadlines. What else comes up after software goes live is described in software after launch.

Apps for your staff only

Not every app belongs in the public store. An app used only by your staff can also be distributed internally, through your company’s device management or the channels Apple and Google provide for that purpose. Apps of this kind for your own operations, such as field service or the warehouse, are covered in capturing orders on a phone.

Checklist before you submit

  • Are both developer accounts in your company’s name?
  • Do you have the D-U-N-S number?
  • Have you decided which contact details are public in the store?
  • Is the privacy policy online, and does it fit the app?
  • Do the data-use details match what the app does?
  • Is there a working test account for the reviewers?
  • Can users delete their account in the app?
  • Who reads the emails from the stores, after launch as well?

The whole journey from idea to store is described in having an app developed.