The App Store and Google Play release process: from opening an account to your first update

The App Store and Google Play release process is the part most people forget to put in the project plan. When the app opens without errors on a test device it feels finished, but before it reaches the store there is account verification, the store listing, privacy declarations and review. I've run this process end to end many times: at Lasolist, where I work remotely from Adana, and on my own apps (Kumanda: TV Remote, Projectify, FiloTakip, and Clean Mac for Developers on macOS). This guide is the checklist that came out of that work.

Apple and Google update their rules regularly. What follows describes the general picture as of 2026; checking both platforms' current developer pages before you apply is always the right move.

The question I get most is whose name the app should be published under. With an individual account, the store shows the person's name as the seller. If the app belongs to a company, I recommend an organization account: it looks right for the brand, and it makes handing the app over easier later. This matters for foreign companies with a Turkish entity too: decide early which legal entity owns the app.

An organization account needs the company's D-U-N-S number, a nine-digit company identifier issued by Dun & Bradstreet. If your company doesn't have one you can apply for free, but getting the number and having it show up on Apple's side can take anywhere from a few days to a few weeks. Applying for D-U-N-S when development starts is the easiest way to avoid waiting on launch day.

The store listing is where users decide whether to download your app. The review team also checks whether what's on that page matches the app. Here's what you need to prepare:

• App name: both stores limit it to 30 characters. Apple also asks for a 30-character subtitle and a 100-character keyword field.
• Description: Google Play has an 80-character short description and a 4,000-character full description. On Apple, the description and the promotional text are separate fields.
• Screenshots: Apple requires screenshots for the largest supported iPhone screen size, plus iPad screenshots if you support iPad. Google Play needs at least two screenshots and a 1024x500 pixel feature graphic.
• App icon: 512x512 pixels for Google Play, 1024x1024 pixels for Apple.
• Category, the age rating questionnaire, a support email and a support URL.
• A link to your privacy policy (covered in the next section).

Don't show a feature in your screenshots that the app doesn't have. Adding a device frame and short captions is fine, but the image has to come from a real screen. Metadata that doesn't match the app is near the top of the rejection reasons.

Both stores require a reachable privacy policy URL for every app. That page should describe the data the app collects in practice. I publish the privacy policies for my own apps on this site; FiloTakip's policy, for example, lists which data is processed and why, from account details to vehicle, driver, invoice and expense records. If you have users in Türkiye, the policy should also reflect KVKK, the Turkish personal data protection law.

Separately from the policy page, you fill in a data declaration form in each store. Apple calls it the App Privacy section, and it shows up on the store page as a privacy label. Google Play has the Data safety form. In these forms you declare:

• Which types of data you collect: contact details, location, usage data, device identifiers and so on.
• Whether that data is linked to the user's identity.
• Whether the data is used for tracking or advertising.
• Whether the data is shared with third parties, and whether it's encrypted in transit.
• Whether users can request that their data be deleted.

Apple reviews usually finish within a day or two, sometimes within a few hours. On Google Play, review can take anywhere from a few hours to a few days, and it can take longer for new accounts and first submissions. Neither platform guarantees a fixed time, so I suggest setting your launch date a few days after review should be done, not on the day itself.

Getting rejected is normal and usually easy to fix. These are the sections of Apple's App Review Guidelines I run into most:

For any app that needs a login, giving the review team a demo account is the step that saves the most time. In an app like FiloTakip, where nothing is visible before you sign in, that account also needs sample data in it; otherwise the reviewers see empty screens and mark the app as incomplete.

1. 01

   Choose the account type and open the accounts

   If you're opening an organization account, get the D-U-N-S number first. Verifying the Apple and Google accounts can take a few days.

2. 02

   Set up the app identifier and signing

   On iOS, the bundle identifier and certificates; on Android, the package name and signing key. The package name can't be changed later, so choose it carefully.

3. 03

   Distribute a test build

   Open the app to a few real users through TestFlight on iOS and an internal or closed testing track on Android.

4. 04

   Fill in the store listing and privacy declarations

   Text, screenshots, icon, age rating, privacy policy URL, and the App Privacy and Data safety forms.

5. 05

   Add review notes and a demo account

   Login details, any special hardware or location requirements, and a short explanation of flows that are hard to test.

6. 06

   Submit for review and choose how to release

   After approval, release right away, on a set date, or manually. With phased release on Apple and staged rollout on Google Play, you can open an update to part of your users first.

After the first release, every update also goes through review, but it's usually faster than the first one. Both platforms use two numbers: the version number users see (for example 1.2.0) and a build number that must go up with every upload. On iOS these are version and build; on Android, versionName and versionCode. You can't upload twice with the same build number.

I use a simple rule for version numbers: the last digit goes up for bug fixes, the middle digit for new features, the first digit for big changes. It makes it clear which version a support request is about, and it makes the store's "What's New" text easier to write.

There are yearly requirements too. Google Play raises the target Android API level every year and can limit how visible apps on an old level are to new users. Apple also requires uploads after a certain date to be built with a current Xcode and SDK. An app that hasn't been updated for a long time greets you with a backlog of work the day you want to upload again. That's why the maintenance budget needs planning from the start.

If you're building a mobile app in Adana or anywhere else and want to hand off the release part, I can run these steps for you, from account setup to the first update. In a free discovery call we look at where your app stands and what's left before launch.