This page is a general orientation, not a rulebook. Apple and Google set and update their own policies. Always check the current App Store Review Guidelines and the Google Play Console Help pages before you plan a launch.
Developer accounts in your name
To publish, you need an Apple Developer Program membership (renewed yearly) and a Google Play developer account (a one-time registration). Both involve identity checks, and organisation accounts on Apple's side need a D-U-N-S number for your business. Open these accounts in your company's name and invite the developer as a team member. If the developer publishes under their own account, moving the app to you later is possible but involves an extra transfer process.
Google Play testing requirements
Google Play has testing tracks (internal, closed and open). Newer personal developer accounts must run a closed test with a minimum number of testers for a set period before they can publish to production. Organisation accounts have different requirements. Check the current rules in Play Console when you set up the account, because they affect your timeline.
Privacy disclosures
Both stores ask you to describe what data your app collects and why: Apple's App Privacy details on the product page, and Google Play's Data safety section. You also need a privacy policy at a public URL. These answers must match what the app and every SDK inside it actually does, including analytics, crash reporting and advertising libraries. Your developer should give you a list of SDKs and what each collects.
Common reasons apps get sent back
- Reviewer can't log in. If your app needs an account, provide a working demo login and any instructions in the review notes.
- Crashes or broken features during review, often on a device or OS version that wasn't tested.
- Too little functionality. Apple's guidelines discourage apps that are mainly a wrapped website with little app-specific value.
- Missing account deletion. If users can create an account in the app, both stores expect a way to request deletion of that account.
- Payments for digital goods. Selling digital content or subscriptions inside an app is generally subject to each store's billing rules. These rules have been changing in some regions, so confirm the current position for your markets. Physical goods and real-world services are usually treated differently.
- Login options. If you offer third-party or social login, check Apple's guidelines on offering an equivalent privacy-focused login option.
- Metadata problems. Screenshots that don't reflect the app, placeholder text, or descriptions that promise features the app doesn't have.
Timing and updates
Review times vary and aren't something anyone can promise. Leave buffer before any launch date you announce publicly, and expect each update to go through review as well. Use TestFlight on iOS and testing tracks on Google Play to get real users on the app before the public release.
Private distribution for staff apps
Apps used only by your staff don't always need a public listing. Options include Apple Business Manager custom apps, managed Google Play through a device management tool, and in some cases Apple's enterprise program, which has its own eligibility rules. The right option depends on how your company manages its devices.
Planning a launch date? Include it in your brief so the schedule leaves room for testing and review.
Send a project brief