An app that works on the developer’s phone is not yet an app your customers can install. Between the two sit two stores, each with its own accounts, signing rules, review guidelines and paperwork. None of it is difficult once you have been through it, and all of it can cost days or weeks if it is met for the first time a week before launch.
This article goes through that last stretch: the accounts, the signing, what reviewers actually reject, the privacy declarations, how to test with real users before release, and how to release to everyone without betting the whole user base on one build.
Accounts in the right name
Both stores publish apps under a developer account, and whoever owns that account owns the app’s listing, its reviews, its download history and its ability to receive updates. So the first rule is simple: the accounts should be in your company’s name, from day one, not in your developer’s.
- Apple Developer Program: a company enrolment needs a D-U-N-S number, a free identifier issued for companies, and it can take some days to obtain. Start early. Your developer is then invited to your account with the role they need.
- Google Play Console: a company account needs the company’s details and verification. Personal accounts created recently must run a closed test with a group of testers for a period before they can publish to production, which is one more reason to use a company account from the start.
Moving an app between accounts later is possible, but it is a process of its own, and some things do not move with it. It is far easier to start in the right place.
Signing keys
Every app is signed, so the device can check that an update really comes from the same publisher.
- On iOS, signing uses certificates and provisioning profiles tied to the Apple developer account. They expire and have to be renewed, and a build pipeline needs access to them. Keeping them in the company’s account means they are not lost when a developer leaves.
- On Android, an app is signed with a key, and with Play App Signing, Google holds the key that signs what users download while you keep an upload key. That arrangement is worth using: if the upload key is lost, it can be reset; if the only signing key is lost without it, the app can never be updated again under the same listing.
Whoever builds the app should be able to tell you where each key lives, who can use it, and how it is backed up. If nobody can, find out before launch rather than after.
What App Store review rejects
Apple reviews every build that goes to the App Store, usually within a day or two. The reasons apps are rejected are well documented in its guidelines, and a few come up again and again:
- The app crashes or has obvious bugs during review. Reviewers use real devices, often not the newest ones.
- The reviewer cannot get in. If the app needs an account, provide a working demo login in the review notes, with data in it.
- Incomplete information: placeholder text, broken links, a missing privacy policy, screenshots that do not match the app.
- Permission requests without a clear reason. Every request for Bluetooth, location, camera or photos needs a purpose string that explains, in plain words, why the app needs it, and the app must work sensibly when the user says no.
- A thin wrapper around a website, with little that is useful as an app.
- Selling digital content or features without using Apple’s in-app purchase, where the rules require it.
Most of these are avoided by a pre-submission checklist and a review note written for a stranger: what the app is for, how to log in, and how to see its main feature, especially one that needs special hardware.
What Google Play asks for
Google Play’s review is mostly automated with human checks, and its requirements are more about declarations:
- The Data safety form: what data the app collects, why, and whether it is shared. It must match what the app actually does, including what its third-party libraries collect.
- Sensitive permissions such as background location need a declaration, a justification, and sometimes a short video showing the feature that needs them.
- The target API level: Google raises the minimum Android version an app must target on a regular schedule, and apps that fall behind cannot be updated until they catch up.
- Content rating and the target audience questionnaire, which decide who can see the app.
Privacy declarations
Both stores now ask for a description of the app’s data practices, shown to users on the listing. This is not a formality. It has to match what the app does, including analytics, crash reporting and advertising libraries, which often collect more than their users realise.
The practical approach is to make a list, once, of every piece of data the app handles: what it is, where it goes, and why. The store forms, the privacy policy and any consent screens are then filled in from the same list, so they cannot disagree with each other.
Testing with real users first
Before a release reaches everyone, it should reach a few people who expect it to be imperfect:
- TestFlight on iOS lets you invite internal testers, and external testers after a light review.
- Google Play has internal, closed and open testing tracks, each with its own audience.
The testers who help most are the ones who use the app for real work, on their own phones, not the people who built it. A week with five real users finds problems no amount of internal testing does.
Releasing gradually
Releasing an update to everyone at once is a bet that nothing in it is wrong. Both stores let you hedge that bet:
- Apple’s phased release spreads an update to users with automatic updates over seven days, and it can be paused.
- Google Play’s staged rollout lets you release to a percentage of users, 5%, 20%, 50%, and increase it as the crash reports stay quiet, or halt it.
Combined with crash reporting, this turns a bad release from a crisis into a paused rollout and a fix.
Over-the-air updates
Frameworks such as React Native can deliver some updates over the air: new JavaScript and images, downloaded by the app without going through the store. It is a real advantage for fixing a bug quickly. It is also bounded by the store rules: an over-the-air update may fix and improve the app, but it may not change what the app fundamentally is, and anything that touches native code still needs a store release. Used for what it is meant for, it makes the weekly fix routine rather than a week-long wait.
The store listing
The store listing is the app’s shop window, and the stores are strict about it:
- Screenshots must show the real app, at the sizes each store requires for each device family. Mock-ups of features that do not exist are a common reason for rejection.
- The description should say what the app does in the first lines; most people read no further.
- The name and subtitle are searched. Words that describe what the app does help people find it more than clever names do.
- A support address and a privacy policy address are required, and both must work.
Prepare these early. They take longer than expected, and they are needed before the first review, not after.
Push notifications
Push notifications need setting up in three places: the app, the stores’ notification services, and your server.
- iOS uses Apple’s push service, with a key created in the Apple developer account.
- Android uses Firebase Cloud Messaging, with a project and credentials from Google.
- Your server stores each device’s push token and sends messages through those services.
Two details save trouble later. The keys belong in the company’s accounts, like the signing keys. And the app must ask for permission to send notifications at a moment when the user understands why, not on the first screen, because a refusal is hard to undo.
Links that open the app
A link in an e-mail that opens the app on the right screen, rather than the website, needs configuration on both sides: in the app, and on your website, which has to publish a small file proving the app belongs to the same owner. On iOS these are universal links; on Android, app links. Without that file, links open in the browser, however correctly the app is built.
Versions, builds and automation
Each store build has a version, the number users see, and a build number, which must increase with every upload. A clear rule avoids confusion: the version changes when something users notice changes, the build number changes on every upload, and both are set by the build pipeline rather than by hand.
Automating builds is worth doing early. A pipeline that builds, signs and uploads the app to the test tracks, on every release, removes the one-person-with-the-right-laptop problem entirely. Tools such as Expo’s build service or fastlane do this, with the signing credentials stored where the whole team can use them.
Rules that catch people out
A few requirements catch apps by surprise:
- If users can create an account in the app, Apple requires that they can also delete it from within the app, not only by writing to support.
- Both stores ask about encryption use when you submit. Most apps only use standard encryption such as HTTPS, which is exempt, but the question must be answered, and it can be answered once in the app’s configuration.
- Sign-in with a third-party account on iOS may require offering Sign in with Apple as well.
- Apps for children fall under stricter rules about data and advertising.
When the app is rejected
Rejections happen, even to careful teams, and most are resolved in one round. What helps:
- Read the rejection carefully. It quotes the guideline and often includes a screenshot of what the reviewer saw.
- If it is a real problem, fix it and submit again, saying briefly what changed.
- If it is a misunderstanding, reply in the review system and explain, politely and concretely. Reviewers see many apps; a clear explanation of what the app does and how to reach the feature in question often settles it.
- Keep a record of every rejection and its fix. The same questions tend to come back at the next major release.
How long it really takes
For a first release, a realistic plan leaves room for things outside anyone’s control:
- Company developer accounts: allow a week or two, especially if a D-U-N-S number has to be requested first.
- Store listing, screenshots and privacy declarations: a few days of work, usually underestimated.
- Test track with real users: at least a week, longer for a new personal Google Play account that must complete its closed test first.
- Review: usually quick, but plan for at least one rejection round.
- Phased release: a week before everyone has the new version.
A launch date that ignores these is a launch date that moves.
After the app is live
Publishing is the start, not the end. After release:
- Watch crash reports and store reviews daily for the first weeks. Early problems are cheapest to fix while few people have met them.
- Reply to reviews, especially the critical ones. It is read by future users as much as by the reviewer.
- Keep up with the platforms. Each year brings a new iOS and Android version, new store requirements and new minimum target versions, and an app that is not updated eventually cannot be updated at all without catching up first.
Before the first submission
[ ] Developer accounts in the company’s name
[ ] Signing keys stored and backed up in the company’s accounts
[ ] Privacy policy published, data list written
[ ] Store listing: name, description, screenshots from the real app
[ ] Permission purpose strings in plain language
[ ] Demo account with data, and review notes for a stranger
[ ] Tested on an older phone, not only the newest
[ ] Crash reporting on
[ ] A test track with real users for at least a week
[ ] Phased or staged rollout planned for the first releaseGetting an app ready for the stores?
Tell me where it is now and what is left.