How to publish an app on the App Store and Google Play
How to publish an app to the App Store and Google Play: developer accounts, store assets, privacy policy, review, common rejections and a real timeline.
Publishing an app to the App Store and Google Play comes down to four things: a developer account on each platform, a store-ready build, a complete store listing (screenshots, description, privacy policy) and passing review. The code is often done before the paperwork is. Plan the store side early and launch day stops being a surprise.
Step 1: Developer accounts (open them first)
You need two separate accounts: the Apple Developer Program for iOS and a Google Play Console account for Android.
| Apple Developer Program | Google Play Console | |
|---|---|---|
| Fee | Annual membership | One-time registration fee |
| Account types | Individual or organization | Personal or organization |
| For organizations | Legal entity + D-U-N-S number | Organization details + D-U-N-S number |
| Identity checks | Yes | Yes |
| Where | developer.apple.com/programs | play.google.com/console |
At the time of writing, Apple charges an annual fee and Google a one-time fee — check the current amounts on the official pages, as they can change and may vary by region.
Two things business owners often miss:
- Register the accounts in your company's name, not the developer's. The account owner controls the app, its reviews and its revenue. Your developer can be invited as a team member with the right role.
- Start early. A D-U-N-S number (a free business identifier from Dun & Bradstreet that Apple and Google use to verify organizations) and identity verification can take from a few days to a few weeks. For companies registered in Moldova or Romania it works the same way — just give it time.
With an organization account, the store shows your company name as the seller. With an individual account, it shows a person's name — usually not what a business wants.
Step 2: A store-ready build
Your developer prepares release builds signed for each store. With React Native and Expo this is handled by EAS Build and EAS Submit (more on that in React Native and Expo explained). Things to confirm:
- Unique app identifier (bundle ID / package name) — it can't be changed later.
- App icon, splash screen, app name.
- Version number and build number.
- Permissions requested only when needed, with clear explanations (camera, location, notifications).
Step 3: Store listing assets
Both stores need a listing. Prepare these in every language you'll support (for Moldova that's usually RO, RU and often EN):
- App name and short description (Google Play) / subtitle (App Store)
- Full description — what the app does, for whom, key features
- Screenshots for the required device sizes (phone, and tablet if you support tablets)
- App icon in store resolution
- Feature graphic (Google Play)
- Category, contact email and support URL
- Age rating questionnaire on both platforms
Screenshots are marketing, not just documentation. Show the value in the first two, add short captions, keep them consistent with your brand.
Step 4: Privacy policy and data disclosures
This is where many first submissions get stuck.
- Privacy policy URL. Both stores require a publicly accessible privacy policy. It must match what the app actually does with data — ideally hosted on your own website.
- Apple App Privacy details and Google Play Data safety form. You declare which data you collect (email, location, analytics, crash logs…), why, and whether it's linked to the user. Include what third-party SDKs collect too (analytics, ads, payments).
- Account deletion. If users can create an account in the app, both platforms expect a way to request account deletion.
- GDPR. For EU users (including Romania), the usual GDPR rules apply on top of store rules.
Be accurate. A mismatch between your disclosures and the app's real behavior is a common reason for rejection or later warnings.
Step 5: Testing before review
- iOS: TestFlight lets you share beta builds with internal and external testers.
- Android: Google Play has internal, closed and open testing tracks. Personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers who stay opted in for 14 days in a row before they can apply for production access — check the current requirement in Play Console Help, as Google has changed these numbers before. Organization accounts don't have this requirement, which is another reason to register as a company.
Use testing to catch crashes on older phones, slow networks and broken edge cases. Reviewers will find them otherwise.
Step 6: The review process
Both stores review every new app and every update (except OTA updates of JavaScript, which follow their own rules).
- Apple App Review checks the app against the App Store Review Guidelines. Reviews are often done within a day or two, but a rejection adds another round.
- Google Play review is partly automated. New apps and new accounts may take several days, sometimes longer.
Common reasons for rejection
- Crashes or broken features during review
- Missing demo login for reviewers when the app requires an account
- Placeholder content, "coming soon" screens, broken links
- Privacy disclosures that don't match the app
- The app is basically a wrapped website with little app-like functionality (Apple's "minimum functionality" rule)
- Digital goods sold without following the store's in-app purchase rules — these differ by region and have changed in the EU, so check the current guidelines
A rejection isn't a disaster. You get a reason, fix it and resubmit. Reply politely in App Review's Resolution Center (or via Play Console) — it helps.
A realistic timeline
| Stage | Typical duration |
|---|---|
| Developer accounts + verification | A few days to a few weeks |
| Store listing, screenshots, texts | A few days |
| Privacy policy and data forms | 1–3 days |
| Beta testing | 1–2 weeks (at least 14 days of closed testing for new personal Google accounts) |
| Review | Often 1–2 days on iOS, a few days on Google Play, plus any resubmissions |
The pro move: open the accounts and draft the privacy policy while the app is still being built. Then the last week is about polish, not paperwork. If you're planning a lean first release, see how to launch an MVP.
Pre-submission checklist
- Apple and Google accounts in the company's name, developer invited as team member
- App name, bundle ID / package name final
- Icon, screenshots, descriptions in all launch languages
- Privacy policy published on your site
- App Privacy / Data safety forms filled in honestly
- Account deletion available (if the app has accounts)
- Demo account and notes for reviewers
- Tested on real, older devices
- Support email and URL working
FAQ
How long does it take to publish an app?
If accounts are ready and the app is stable, the store part usually takes from a few days to two weeks. Account verification and a first-time rejection are the usual things that stretch it.
Do I need a company to publish an app?
No — individuals can publish. But an organization account shows your company as the seller, avoids some extra testing requirements on Google Play and keeps ownership clearly with the business.
Can I publish only on Android or only on iOS?
Yes. Many teams launch on one platform first. With React Native and Expo, adding the second one later is mostly a store and testing task, not a rewrite.
Can the developer publish the app under their own account?
Technically yes, but it's risky for you: transferring an app later is extra work and sometimes messy. Own the accounts yourself from the start.
Want it handled end to end?
I build apps with React Native and Expo and handle the builds, store listings and the review process as part of app development — with the developer accounts registered in your name. If you're comparing options, check PWA vs native app first. Ready to scope it? Open the project builder and pick "mobile app" to get an estimate.
