TL;DR: To publish an app on the App Store and Google Play, you need two developer accounts (Apple: $99/year, Google: $25 one-time), a build that passes each store's review, a localized store listing, and — if you sell digital content — compliance with mandatory in-app purchase rules. A first-time launch typically takes one to three weeks end to end, most of it preparation rather than review. After launch, both stores require ongoing updates just to stay listed, so budget for maintenance from day one.
If you're a business owner hiring a developer, the store submission phase is usually the part nobody explains to you — until your launch date slips because of a rejected build or a missing tax form. I've taken apps through this process on both platforms, including Tafrud, an e-learning app I built end-to-end for the Saudi market that's live on the App Store and Google Play today. Here's the complete process, in the order it actually happens.
Step 1: Developer Accounts — Fees and Requirements
Before anything can be submitted, someone has to own the developer accounts. My strong recommendation: the accounts should belong to you (the business), not your developer. If your agency publishes your app under their account, you don't fully control your own product — migrating it later is possible but painful.
| Apple Developer Program | Google Play Console | |
|---|---|---|
| Fee | $99 USD per year | $25 USD one-time |
| Individual account | Yes — app is published under your personal legal name | Yes — with identity verification, and new personal accounts must pass a closed-testing phase before production |
| Company account | Requires a legal entity, a D-U-N-S number, and a person authorized to sign for the company | Requires a legal entity and a D-U-N-S number |
| Verification time | Usually days; D-U-N-S registration for a new company can take 1–2 weeks | Usually days |
Three things trip people up here:
- Company vs. individual matters for branding and trust. An individual account shows a person's name as the seller. If you're a registered business — in Saudi Arabia, that means having a valid commercial registration (CR) — set up an organization account so your company name appears on the listing.
- The D-U-N-S number is free but slow. Both Apple and Google now require it for organization accounts. Request it early; it's the single most common cause of "we can't even start yet" delays.
- Google's closed-testing requirement. New personal Play Console accounts must run a closed test with a minimum number of opted-in testers over at least 14 days before they can publish to production. The exact tester quota has changed a couple of times, so check the current Play Console requirements — but plan for roughly two extra weeks if you're publishing as an individual on Android.
You'll also need banking and tax details in both consoles before you can sell anything, and Apple requires signed paid-app agreements before in-app purchases go live.
Why Apps Get Rejected in Review
Both stores review every submission against published guidelines — Apple's App Review Guidelines and Google Play's Developer Policy Center. Apple's review is stricter and more human; Google's is more automated but has become noticeably tougher since 2024. The most common rejection reasons I see:
- Crashes and incomplete features. Reviewers test on real devices. A broken login flow or a placeholder screen is an instant rejection.
- No demo account. If your app requires login, you must provide working test credentials in the review notes. Forgetting this is probably the #1 avoidable rejection.
- Minimum functionality. Apple rejects apps that are just a website wrapped in an app shell. If your "app" is a WebView of your site, expect guideline 4.2 pushback.
- Privacy gaps. Both stores require a privacy policy URL, accurate data-collection disclosures (Apple's privacy labels, Google's Data Safety form), and — if users can create accounts — an in-app way to delete the account, not just deactivate it.
- Permission overreach. Requesting location, contacts, or tracking without a clear in-app justification.
- Payment violations. Selling digital content through anything other than the store's own billing system (more on this below).
- Misleading metadata. Screenshots or descriptions that show features the app doesn't have.
A rejection isn't a disaster — you fix the issue, reply in the resolution center, and resubmit. But each round-trip costs days, which is why an experienced developer front-loads compliance instead of discovering it in review.
Store Listing and ASO Basics
Your listing is a landing page, and it deserves the same discipline as any campaign page. Running lead generation for six automotive brands taught me that the asset people see before they commit is what decides conversion — the same logic applies to app store listings.
The essentials:
- Title and subtitle carry the most keyword weight. Put your primary term in the app name or subtitle, not buried in the description.
- Apple has a hidden 100-character keyword field — fill it deliberately, no repeats, no spaces after commas.
- Google indexes your description; Apple largely doesn't. Write the Play description with search terms in mind, and write the App Store description for humans.
- Screenshots sell, icons get the tap. The first two screenshots do most of the work; use captions that state benefits.
- Localize everything. A listing in the user's language converts measurably better — critical for the Saudi market (see below).
- Ratings compound. Prompt for reviews at moments of success (after a completed purchase or lesson), never at first launch.
In-App Purchase Rules: When the Stores Force Their Billing
This is the part that surprises business owners most, so here's the rule stated plainly: if you sell digital goods or services consumed inside the app — courses, subscriptions, premium features, coins, content unlocks — Apple and Google require you to use their in-app purchase systems, and they take a commission (30% standard; 15% for smaller developers via Apple's Small Business Program and Google's reduced tier on the first $1M of annual revenue).
Physical goods and real-world services are the opposite: rides, food delivery, clothing, bookings for in-person services must not use store billing — you use your own payment gateway there.
When I built Tafrud, this shaped the entire payment architecture. Course purchases inside the app go through Apple and Google IAP, exactly as the guidelines require. Separately, the platform's website checkout supports Tamara (buy-now-pay-later) and bank transfer for customers who prefer to buy there — a common pattern in Saudi Arabia, where BNPL and bank transfer are everyday payment habits. The key is structuring the flows so each channel is compliant on its own terms; apps that try to steer users around IAP inside the app get rejected or removed.
The regulatory ground is also shifting: as of 2026, external-payment allowances vary by region (the EU and US have forced some openings). Don't design your business model around loopholes — design it around the base rules, and treat any regional exception as a bonus.
Timelines: What to Actually Expect
Typical first-launch timeline in my experience, assuming the app itself is finished:
- Developer accounts + D-U-N-S: a few days to two weeks (do this in parallel with development, not after)
- Store assets, listing copy, privacy forms: 2–4 days done properly
- Apple review: commonly 24–48 hours per submission in 2026
- Google review: first submission can take several days to a week; updates are usually faster
- One rejection cycle: add 2–5 days
Realistic total: one to three weeks from "code complete" to "live in both stores" — longer if it's a personal Google account with the closed-testing requirement. Any developer who promises "we'll be live tomorrow" on a first release hasn't done this before.
Saudi-Specific Notes
Publishing for the Saudi and Gulf market has a few particulars I've learned firsthand, building from Riyadh:
- Arabic listings are not optional. Both stores support full Arabic metadata for the Saudi storefront — title, description, keywords, and screenshots. An Arabic-first listing with Arabic screenshot captions consistently outperforms an English-only one for local audiences.
- RTL is a product decision, not a translation task. Arabic UI needs proper right-to-left layout and Arabic-appropriate typography inside the app, not just translated strings. Reviewers won't reject you for bad RTL, but users will.
- Payment expectations are local. Saudi users expect mada and Apple Pay for card flows, and BNPL options like Tamara or Tabby are now standard at checkout for physical goods and web sales. Inside the app, store IAP handles this for you — Apple and Google act as the merchant, support local payment methods on their end, and handle Saudi VAT collection on store sales (confirm specifics with your accountant).
- Price in SAR deliberately. Both stores let you set storefront-specific pricing; don't let auto-conversion produce awkward price points.
- A company account with your CR-registered entity signals legitimacy to both the stores and your customers.
Maintenance After Launch: The Part Everyone Underbudgets
An app store listing is not a one-time achievement; it's a subscription to an obligation. Concretely:
- Google requires apps to target a recent Android API level (within roughly a year of the latest Android release) or updates get blocked and visibility drops.
- Apple requires builds made with a recent iOS SDK each year, with deadlines every spring.
- Frameworks age fast. I recently took Tafrud through a major React Native version upgrade — dependency chains, native build tooling, and store requirements all move together, and skipping two years of updates turns a week of work into a month.
- Policies change under you. Data-safety forms, account-deletion rules, and billing policies have all been tightened mid-flight in recent years; someone has to be watching.
- Monitor crashes and reviews. Crash-free rate and review responses affect ranking on both stores.
Budget for at least a few maintenance releases per year even if you add zero features. A healthy pattern I use — with AI-assisted tooling in my engineering workflow — is small, frequent updates rather than one risky annual overhaul.
FAQ
How much does it cost to publish an app on the App Store and Google Play? Apple charges $99 USD per year for its Developer Program; Google Play charges a $25 USD one-time registration fee. Beyond that, both stores take a commission on digital sales — 30% standard, or 15% for smaller developers under Apple's Small Business Program and Google's reduced tier on the first $1M in annual revenue.
How long does app store review take in 2026? Apple typically reviews submissions within 24–48 hours. Google's first-time reviews can take several days up to a week, with faster turnaround on updates. Plan one to three weeks total for a first launch, including account setup, listing preparation, and a possible rejection cycle.
Can I publish an app without a registered company? Yes — both stores offer individual accounts. On Apple, the app is published under your personal legal name. On Google, new personal accounts must complete a closed-testing phase with real testers before going to production. For a business product, an organization account (which requires a legal entity and a D-U-N-S number) is worth the extra setup time.
Do I have to use Apple and Google in-app purchases? If you sell digital goods or services consumed inside the app — subscriptions, courses, premium features — yes, store billing is mandatory and the stores take their commission. Physical goods and real-world services must use your own payment gateway instead. Regional exceptions exist in 2026, but the safe default is to comply with the base rules.
If you're planning an app for the Saudi market — or anywhere — and want someone who has carried a product through both stores, from architecture to Arabic listings to IAP compliance, I can help. See how I built Tafrud end-to-end, browse what I offer, or get in touch and tell me what you're building.