App Store Submission: What Apple and Google Check, and How to Avoid a Rejection

To publish a phone app, you need a developer account with Apple and with Google, ideally in your business's name, a complete store listing, accurate privacy disclosures, and a finished build that reviewers can fully test. Both stores review every new app and every update against their own published rules, and most rejections come from preventable gaps: a missing demo login, a broken link, placeholder content, or privacy answers that do not match what the app actually does.

Store policies change often, and this is a general overview rather than a statement of either store's current rules. Before you submit, read Apple's App Store Review Guidelines and Google's Developer Program Policies on their own developer websites. They are the final word.

Most of what the stores ask for can be prepared weeks before launch, which turns launch week into a formality.

Step one: the developer accounts

Each store has its own developer programme, and each has a fee: Apple's membership renews every year, while Google charges a one-time registration fee. Check the current amounts on their sites.

Enroll as an organization, in the business's legal name, not as an individual developer. The account name is what appears as the seller on your listing, and the account holds the app. If a freelancer publishes your app under their personal account, moving it later is a chore. Verification can take days or longer, especially if your business details do not match public records exactly, so start this first. A D-U-N-S number, if you do not already have one, is free to request but takes time to issue.

Google has also required some newer personal developer accounts to run a closed test with a minimum number of testers for a set period before an app can go to production. The exact numbers have changed before, so check the current requirement for your account type early.

Step two: the store listing

The listing is what customers see, and reviewers check that it matches the app. Prepare these well before the build is finished:

• Name and short description. Each store limits the length. Keep the name to your brand and what the app does, not a string of keywords.
• Full description. Plain, accurate, and only describing features that exist in this version.
• Screenshots for the device sizes each store requires, showing the real app. Mock-ups of features that are not built yet are a common reason for rejection.
• App icon at the required sizes.
• Category and age rating. Both stores use a questionnaire about content to set the rating. Answer it carefully; a wrong answer can bring a later rejection or removal.
• Support contact and website, which must work.
• Privacy policy link, required by both stores, describing what the app collects and why. Our own privacy policy shows the kind of page a reviewer expects to find, though yours must describe your app.

Step three: privacy disclosures

Both stores ask you to declare what data the app collects, whether it is linked to the user, and whether it is used for tracking. Apple shows this on the listing as App Privacy details. Google calls its version the Data safety section.

• Count everything, including third-party code. Analytics, crash reporting, advertising and sign-in kits all collect data. Your answers have to cover what they collect, not just what your own code does. Ask your developer for a list.
• Explain each permission. If the app asks for the camera, location, contacts or photos, the prompt needs a clear reason in plain language, and the app should ask at the moment the feature is used, not all at once on first launch.
• Tracking across other companies' apps on iPhone needs the user's permission through Apple's tracking prompt.
• Account deletion. Apple requires apps that let people create an account to let them start deleting it from inside the app. Google Play has a similar rule and also asks for a way to request deletion from outside the app.
• Sign-in options. If you offer sign-in through a third-party social account, Apple may require an additional sign-in option that meets its privacy criteria. Check the current guideline before you design the sign-in screen.

Keep the disclosures up to date. Adding an analytics tool in a later update means changing the answers too. This is general information, not legal advice; privacy laws apply on top of store rules.

Step four: let reviewers see everything

A reviewer who cannot get past the sign-in screen will reject the app. Give them what they need in the review notes:

• A working demo account with realistic sample data, and the password. Make sure it does not expire or get locked after a few attempts.
• Instructions for anything hidden, such as features that only appear for certain user types, at certain locations, or with a connected device.
• A live back end. The server, test payment setup and any connected systems must be running during review, not switched off for the weekend.
• An explanation of anything unusual, such as why the app needs background location, or that it is only for existing customers of your business.

Payments inside the app

As a general rule, digital goods and features used inside the app, such as subscriptions to premium content, must use the store's own in-app purchase system. Payments for physical goods and real-world services, such as a haircut, a repair visit or a delivered order, normally go through your own payment provider instead. The rules on linking out to other payment options have changed in some countries and after court cases, and they continue to shift. If your app sells anything digital, confirm the current rule for each market before you design the payment flow.

Common reasons apps are rejected

• Crashes or obvious bugs on the reviewer's device.
• No demo account, or one that does not work.
• Placeholder text, test data or "coming soon" sections.
• Broken links, including the support and privacy policy pages.
• Screenshots or descriptions that show features the app does not have.
• Privacy answers that do not match what the app and its third-party code collect.
• Permission requests with no clear explanation.
• An app that is little more than a website in a wrapper. Apple in particular expects an app to offer something beyond a repackaged site. If a website would do the job, a web app may be the better choice anyway; see native vs cross-platform vs web apps.
• Missing account deletion, where the app has accounts.

A rejection is not a disaster. Each store explains the reason, you fix it or reply, and you resubmit. It does cost time.

Testing before you submit

TestFlight on Apple and the testing tracks in Google Play Console let staff and a small group of real users install the app as customers will. Test on older devices, on a slow connection and with permissions refused, because reviewers try all of those.

Timing and release

Review times vary. Many apps are reviewed within a day or two, but new apps, new accounts, apps in sensitive categories and busy periods can take longer, and each rejection adds another round. Updates are reviewed too, usually faster. Plan launch dates with a buffer of at least a week and do not announce a date you cannot move.

• Release on your schedule. Both stores let you hold an approved app and release it when you choose, rather than the moment it passes review.
• Roll out gradually. Apple offers a phased release for updates, and Google offers staged rollouts, so a problem reaches a small share of users before everyone.

Apps that should not be in the public stores

An app built only for your staff does not need a public listing. Apple supports private distribution of custom apps to organizations through Apple Business Manager, and Google supports private apps through managed Google Play. Alternatively, an internal tool can be a web app with no store involved at all. Ask early, because the distribution route affects how the app is built and signed.

A worked example

Hypothetical: the business and timings are invented to show the planning. Real verification and review times vary.

A physiotherapy group plans to launch a booking app for patients on the first of the month. Working backwards:

1. Eight weeks out: request a D-U-N-S number and enroll both developer accounts in the group's legal name.
2. Six weeks out: write the store descriptions, draft the privacy policy section for the app, and list every third-party kit in the app with what it collects.
3. Four weeks out: internal testing on staff phones through TestFlight and a Google testing track, including older devices.
4. Three weeks out: a closed test with a group of patients who volunteered. Take real screenshots from this build.
5. Two weeks out: submit to both stores with a demo patient account and notes explaining that bookings are for existing patients.
6. Launch day: release the approved versions manually, with the reception team briefed.

The two-week buffer allows for one rejection on each store and a fix. If both pass first time, the app simply waits, approved, until launch day.

A submission checklist

• Developer accounts in the business's name, with at least two people able to sign in.
• Listing text, screenshots from the real build, icon and age rating answers.
• Working privacy policy and support pages.
• Privacy and data safety answers covering third-party code.
• Permission prompts with clear reasons.
• In-app account deletion, if the app has accounts.
• Demo account and review notes.
• Back end live and monitored during review.
• A release plan with a buffer.

Once the app is live, both stores keep raising their requirements each year, which is part of the upkeep covered in our guide to app maintenance and updates.

How FiberX handles it

On our App Development projects, launch is the fourth of five steps: testing on real devices, app store submission where it applies, and a planned switch-over from the old way of working. Ownership, licensing and hosting are set out in the agreement before work starts, which covers whose name the developer accounts are in. The details of your app, including platforms, store listings and timelines, are confirmed in your consultation, and you get a written estimate before you commit. If your app handles sensitive data, our cybersecurity page covers the network side. The consultation is free, Phil Morales is your point of contact from the first call through launch and support, and we usually reply the same day. Book a consultation, call 478-758-8091 or text (347) 870-0965.