To publish an app on the App Store and Google Play, you open developer accounts, prepare the store listing and privacy declarations, upload a signed build, test it through the stores' testing tracks and submit it for review. The two stores follow the same logic, but their tools, terms and rules differ.
Publishing is often left for the last week of a project, and it is the step most likely to push the schedule. That is why, in mobile app development, store preparation should run in parallel with the code. The resident app we built with React Native for Kemerköy Sitesi is live on both stores. Store fees and rules change from time to time, so check Apple's and Google's current documentation before you plan.
The process comes down to six steps:
- Open the developer accounts.
- Prepare the store listing.
- Complete the privacy and data safety declarations.
- Upload a signed build and test it.
- Submit it for review.
- Open the release in a controlled way.
How do you open a developer account, and whose name should it be in?
For the App Store you enroll in the Apple Developer Program; for Google Play you register for Google Play Console. Apple charges an annual membership fee, and Google a one-time registration fee. Both distinguish between individual and organization accounts.
- Organization account: your company's name appears as the developer in the store. Both stores ask for a D-U-N-S Number to enroll an organization and verify its details.
- Identity verification: Google verifies identity and contact details for all developer accounts, and Apple confirms that the person enrolling an organization has the authority to represent it.
- New personal Google accounts: before going to production, they must run a closed test with a minimum number of testers for a minimum period. This requirement does not apply to organization accounts.
- Trader declaration: if you distribute in the European Union, you will also be asked to declare your trader status under the Digital Services Act.
One important point: open the accounts in your company's name, not the development agency's, and give the agency access as team members. You should own the app, its store record and its user reviews. We cover account fees and other budget items in what drives the cost of mobile app development.
What goes into the store listing?
The store listing is everything users see before they download your app. In both stores, you need these materials ready:
- Name and short description: the app name and subtitle on Apple, the app name and short description on Google Play, each with a character limit.
- Full description: plain, honest copy that says what the app does in the first sentence.
- Keywords: Apple has a dedicated keyword field; on Google Play, search draws on the title and description text.
- Visuals: the app icon, screenshots for the supported device sizes and an optional preview video. Google Play also requires a feature graphic.
- Category and age rating: Apple sets the rating through its own questionnaire, Google Play through the IARC questionnaire.
- Support and privacy links: a support URL and a publicly accessible privacy policy page.
If your app works in more than one language, prepare a separate listing for each one. Users expect to see screenshots in their own language, too.
How do you fill in privacy details and the data safety form?
Both stores require you to show on the listing what data your app collects and why. Apple collects this through the App Privacy section in App Store Connect, and Google Play through the Data safety form in Play Console.
To get these declarations right:
- Build a data inventory: list the data collected by the app itself and by every third-party SDK it uses, such as analytics, advertising, crash reporting and maps.
- Map the purposes: for each data type, record what it is used for, whether it is linked to the user and whether it is shared.
- Check tracking consent: on iOS, if you track users across other companies' apps and websites, you must ask for permission through App Tracking Transparency.
- Keep privacy manifests current: Apple requires a privacy manifest for certain SDKs and sensitive APIs, so make sure the SDK versions you use support it.
- Offer account deletion: if users can create an account in the app, both stores require a way for them to start account deletion. Google Play also expects a deletion link that can be reached from outside the app.
- Align the texts: store declarations, your privacy policy and your KVKK or GDPR notices must not contradict one another.
A gap between what you declare and what the app actually does is a reason for rejection, and it can also lead to removal after launch. Add every newly introduced SDK to the inventory with each update.
How do you upload and test a build?
Every build you upload must be a signed package. On iOS, the build is sent to App Store Connect from Xcode or a CI pipeline. On Android, new apps are uploaded as an Android App Bundle (AAB) and signed by Google through Play App Signing; you keep the upload key, and you need to store it safely.
These are the official ways to test with real users before launch:
- TestFlight internal testing: members of your App Store Connect team try the build as soon as it finishes processing, with no review.
- TestFlight external testing: testers outside the team are added by email invitation or a public link; the first build of a version made available to external testers goes through Beta App Review.
- Google Play internal testing: the fastest track for a small team.
- Google Play closed testing: distributed to testers invited through email lists or Google Groups; this is where new personal accounts meet their pre-production requirement.
- Google Play open testing: a broad test that anyone can join from the store listing.
Google Play also offers a pre-launch report that automatically runs builds from testing tracks on real devices. Increase the build number with every upload; neither store accepts a build number that has already been used.
What should you watch for during review?
Apple reviews every version against its App Review Guidelines, and Google against its Developer Program Policies. Review times vary, and first releases and new accounts usually take longer than updates. Common reasons for rejection:
- Inaccessible content: no working demo account for the review team in an app that requires sign-in.
- Crashes and unfinished features: empty screens, "coming soon" sections or broken links.
- Misleading metadata: descriptions and screenshots that show features the app does not have.
- Minimum functionality: apps that simply wrap a website in a frame are often rejected by Apple.
- Privacy mismatches: undeclared data collection, permission requests without a clear reason or missing account deletion.
- Payment rules: selling digital content and subscriptions brings the stores' payment system rules into play, and these rules can vary by region. Physical goods and services follow different rules.
When an app is rejected, the reason arrives through App Store Connect or Play Console. You can fix the issue and resubmit, or appeal a decision you believe is wrong. Writing clear test steps in the review notes prevents unnecessary rounds.
How do you manage the release after approval?
Approval does not mean the app has to go live for everyone at once. Both stores offer tools for a controlled release:
- Release timing: on Apple, you can release automatically after approval, on a set date or manually; on Google Play, managed publishing lets you decide when approved changes go live.
- Gradual rollout: Apple's phased release spreads automatic updates over several days, and Google Play's staged rollout starts with a percentage of users.
- Country selection: you can publish only in the countries you choose and expand later.
- Monitoring: watch the crash rate, reviews and ratings closely in the first days, and pause the rollout if you see a problem.
Launch is only the beginning; for release planning, operating system updates and monitoring, read after launch: mobile app maintenance, releases and monitoring.
Store preparation is not a launch-week task; it belongs in the project's first week.
Frequently asked questions
How long does app review take?
There is no fixed time. Most updates are processed quickly, while first releases, new accounts and sensitive categories can take longer. Leave room in your schedule for review and a possible rejection round.
Should the agency or our company open the developer account?
Your company should. With the account in your name, the app, its store record and its user reviews stay with you, and the agency gets team access with only the permissions it needs.
Is a privacy policy page mandatory?
Yes. Both stores require a link to a publicly accessible privacy policy. That page should be consistent with your store declarations and your KVKK or GDPR notices.
Does every update go through review again?
Yes, every new version uploaded to the stores is reviewed. Updates usually clear faster than a first release, but new permissions, new data collection or payment changes can draw a closer look.
Where to start?
Finish three tasks as development begins: open the developer accounts in your company's name, publish your privacy policy page and list the data your app collects. These three steps remove most of the surprises in launch week.
If you would like to prepare your app for both stores together, get in touch.