Publishing an app on the App Store and Google Play: accounts, review, requirements and recurring rejections

Publishing an app in the stores is not a final step: it is a project within the project, with requirements that change every year and reviews that can push a launch back by weeks. Most delays I see do not come from the code, but from accounts set up wrongly, incomplete privacy documentation and guidelines read too late.

Accounts: the first decision

The developer account should be opened in the app owner's name, as an organisation, not in the name of the developer or agency. The developer is added to the team with the roles needed. If the app sits in someone else's account, transferring it later is possible but cumbersome, and meanwhile the client does not control an asset that is theirs.

• Apple Developer Program: yearly fee; organisations need a D-U-N-S number, which can take days to be issued.
• Google Play Console: one-off fee; identity verification and, for newer personal accounts, a mandatory closed test with a minimum number of testers for a set period before production access.

Both steps should start at the beginning of development, not the end.

Privacy documentation

This is the part that most often blocks a release.

• App Store: privacy "labels" declare what data the app collects and why, including third-party libraries. For some years now privacy manifests have also been required for the app and for SDKs that use APIs considered sensitive.
• Google Play: the Data safety section with the same information, which Google checks against the app's real behaviour.
• Privacy policy published at a reachable URL.
• Account deletion: if the app allows sign-up, it must allow deleting the account from within the app, and Google also requires a web route.

Declarations must match what the app and its SDKs really do, analytics and crash reporting included.

The guidelines behind most rejections

Based on the recurring reasons:

• Minimum functionality: a website packaged in a WebView with no features of its own is rejected.
• Completeness: broken links, placeholder screens, "coming soon" features, test credentials not provided to the reviewer.
• Login: if third-party sign-in is offered, Apple also requires a privacy-focused sign-in option.
• Payments: digital content and features sold inside the app go through the store's purchase system; physical goods and services do not. The boundary needs careful assessment.
• Permissions: every access request (location, camera, contacts) must carry a clear explanation and match a real use.
• Metadata: screenshots that do not show the real app, descriptions referring to other platforms.

The technical path

1. Signing and identifiers: final bundle ID and application ID, signing certificates and keys stored securely. On Google Play, store-managed signing is used.
2. Release build with production configuration, kept separate from development.
3. Test distribution: TestFlight on iOS, internal and closed testing tracks on Google Play, with real testers.
4. Store listing: name, descriptions, keywords, screenshots at the required sizes, icon, content rating.
5. Submission for review with notes for the reviewer and a working test account.
6. Staged rollout where possible, to limit the impact of a bug reaching production.

After publishing

Every year Google raises the minimum API level required to update apps, and Apple requires building with recent tool versions. An app that is not updated eventually can no longer receive updates, and is sometimes hidden from new users. Store maintenance is a recurring cost to include in the very first quote.

A pre-submission list

• Account in the owner's name, with the developer as a team member.
• Privacy declared and consistent with SDKs and real behaviour.
• Account deletion available, if there is sign-up.
• Test account and notes for the reviewer.
• No incomplete screens or broken links.
• Closed test completed, where required.

Realistic timing

An honest publication plan, once development is complete, includes:

• accounts: straight away, because organisation verification and the D-U-N-S number can take days or weeks;
• closed testing on Google Play, where required, with the minimum period and number of testers: start it as soon as there is a stable build;
• privacy documentation and store listing: a few days, especially for screenshots at the required sizes and the inventory of data collected by SDKs;
• review: usually quick, but with margin for at least one rejection and resubmission;
• staged rollout: a few days of observation on a share of users before 100%.

Tying a launch to a fixed date without these margins is the most frequent cause of postponed announcements. It is better to publish in a non-visible mode and switch the app on when needed.

My take

Before tackling publication I always ask whether the store is really needed. For many projects a web app or PWA, updated with a deploy and with no review, covers everything: I explain this in Native app, web app or PWA. When the store is needed, publication should be treated as a project phase with its own timeline, not a final click.

And I always insist on one point: accounts and signing keys in the client's name. It is the same rule I apply to domains, repositories and hosting: whoever pays for the project should own it, even if one day they choose another developer.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely. I handle store publication from account setup to review, with privacy documentation consistent with the code.

If you need to publish an app, get in touch: in a call of about 20 minutes we line up requirements and timing. The service is in Mobile apps.