Key takeaways
- To publish an app you need an Apple Developer Program membership at $99 per year and a Google Play Console account with a one-time $25 fee, ideally both registered to your company.
- You need a public privacy policy, plus Apple’s App Privacy details and Google Play’s Data safety form, and both must match what the app actually does.
- The most common rejection reasons are crashes, incomplete information, no demo account for reviewers, misleading metadata and breaking in-app purchase rules.
- Test through TestFlight and Google Play’s testing tracks on real devices, in both Arabic and English, before submitting for review.
- Use phased release on iOS and a staged rollout on Google Play, and monitor crashes and reviews closely during the first days.
To publish an app on the App Store and Google Play, you need a developer account on each store, a stable build that meets the store’s review guidelines, a privacy policy with completed privacy and data-safety declarations, and a complete store listing with screenshots and descriptions. Before submitting, test through TestFlight and Google Play’s testing tracks, give reviewers a demo account if your app requires login, and plan a phased rollout so you catch problems before they reach every user.
What do you need before you start?
Developer accounts
- Apple Developer Program: $99 per year. Organisations generally need a D-U-N-S number (a free business identifier from Dun & Bradstreet) and the legal authority to bind the company. Verification can take days or longer, so start early.
- Google Play Console: a one-time $25 registration fee. Google verifies developer identity, and organisation accounts need business details. Newer personal accounts may have to run a closed test with a minimum number of testers before getting production access, so check the current requirements.
Register both accounts in your company’s name, not under a freelancer’s or an agency’s personal account. You should own your app listing, reviews and download history.
Legal and privacy essentials
- A privacy policy hosted at a public URL, in Arabic and English if you serve both audiences.
- Apple’s App Privacy details and Google Play’s Data safety form, which describe what data you collect, why, and whether it is shared. They must match what the app and any third-party SDKs for analytics, ads or crash reporting actually do.
- An in-app account deletion option if users can create accounts. Both stores now expect this.
- Terms of use and any sector-specific permissions or licences relevant to your business.
How should you prepare your store listing?
Your listing is your shop window. App Store Optimisation (ASO), improving how your app ranks and converts in store search, starts here.
- App name and subtitle or short description: tight character limits apply, so put your most important keyword early.
- Description: lead with the value for the user, then list the main features.
- Screenshots: show real screens with short, benefit-focused captions, in the required sizes for phones and for tablets if supported.
- Localisation: create separate Arabic and English listings with native copy and RTL screenshots. Arabic users search in Arabic, and a word-for-word translated listing performs poorly.
- Category, age rating and contact details: fill them in accurately; the questionnaires affect where and to whom your app is shown.
- App preview video (optional): a short clip can help explain complex apps.
The pre-launch checklist at a glance
| Item | App Store | Google Play |
|---|---|---|
| Account fee | $99 per year | $25 one-time |
| Privacy declaration | App Privacy details | Data safety form |
| Beta testing | TestFlight | Internal, closed and open tracks |
| Gradual release | Phased release | Staged rollout by percentage |
| Review | Review of every build | Automated and manual review |
Why do apps get rejected, and how do you avoid it?
Most rejections are preventable. The common reasons:
- Crashes and obvious bugs. Reviewers test on real devices, and a crash on launch means rejection.
- Incomplete information. Broken links, placeholder text, "coming soon" sections or missing support contacts.
- No demo account. If your app requires login, give reviewers working credentials, including a test phone number or a way past the OTP step, plus notes explaining how to reach key features.
- Misleading metadata. Screenshots or descriptions promising features the app doesn’t have, or keywords stuffed with competitor names.
- In-app purchase rules. Digital goods and subscriptions consumed inside the app generally must use the store’s in-app purchase system, while physical goods and real-world services can use payment gateways, cards, Apple Pay or local methods like Mada.
- Permissions without explanation. Asking for location, camera or contacts without a clear purpose message, or requesting more than you need.
- Minimum functionality. An app that is just a wrapped website with no real app value can be rejected, especially on iOS.
Read both stores’ current review guidelines before your final sprint, not after the rejection email.
How should you test before going live?
- TestFlight (iOS): distribute builds to your internal team and to external testers. External builds go through a short beta review.
- Google Play testing tracks: start with internal testing for your team, then a closed test for selected users, and optionally an open test.
- Real devices: older phones, small screens, different OS versions, slow networks, and both Arabic and English with RTL.
- Unhappy paths: failed payments, expired sessions, no internet and denied permissions.
- Analytics and crash reporting: confirm they work before launch so you are not flying blind.
What does a safe launch look like?
- Submit several days before any marketing date, because review times vary.
- Use phased release on iOS and a staged rollout on Google Play, starting with a small share of users.
- Watch crash-free rates, reviews and support messages closely in the first days.
- Pause the rollout if something breaks, fix it, then resume.
- Make sure your backend and admin panel are ready for real traffic, and that support channels such as WhatsApp and email are staffed.
What happens after launch?
Publishing is the start, not the finish. Plan for:
- Monitoring: crashes, performance, API errors and store ratings.
- Responding to reviews in the reviewer’s language, which builds trust with future users.
- Regular updates: new OS versions, new device sizes and store policy changes all require ongoing maintenance.
- ASO iteration: test new screenshots and descriptions based on conversion data.
If you are earlier in the journey, our practical guide to building a mobile app in 2026 covers the path from idea to MVP.
Treat the store reviewer as your first real user. If they can’t log in, understand the app or complete the main task in a few minutes, neither can your customers.
The bottom line
A smooth launch on the App Store and Google Play comes down to preparation: company-owned developer accounts, accurate privacy declarations, a strong bilingual listing, thorough testing, clear reviewer notes and a gradual rollout with active monitoring. Our development process builds these steps into every project, so launch day is predictable rather than stressful.
Getting ready to publish, or stuck on a rejection? Contact the TaahadSoft team for a free pre-launch review, and we will help you get your app live on both stores.
Frequently asked questions
How much does it cost to publish an app on the App Store and Google Play?
The App Store requires an Apple Developer Program membership at $99 per year, while Google Play charges a one-time $25 registration fee. The stores may also take a commission on certain in-app digital purchases. Developing the app and preparing the store listing are separate costs.
Do I need a D-U-N-S number to publish an app under my company name?
Apple generally requires a D-U-N-S number for organisation accounts; it is a free business identifier issued by Dun & Bradstreet. Getting it and completing verification can take days or longer, so start early. Google Play also asks for business details to verify organisation accounts, and requirements change from time to time, so check them before registering.
How long does app store review take?
Review times vary by store, app type and timing, and a first submission or a request for changes can take longer. Submit several days before any marketing date. Clear reviewer notes and a working demo account reduce the chance of rejection and resubmission.
Why was my app rejected by the App Store?
The most common reasons are crashes or obvious bugs, incomplete information or broken links, no demo account for reviewers, misleading screenshots or descriptions, and breaking in-app purchase rules for digital goods. Read the rejection message carefully, fix the cited issue and add clear notes for the reviewer when you resubmit.
Can I accept Mada or Apple Pay inside my app?
Yes, for physical goods and real-world services such as orders, deliveries and bookings, which can use payment gateways, cards, Apple Pay or local methods like Mada. Digital goods and subscriptions consumed inside the app generally must use the store’s own in-app purchase system. Check the current guidelines, because rules can vary by country and product type.
