An app that will not pass review is not a broken app. It is usually a finished, working app missing one small thing that a human reviewer needs, and the gap between those two states is where most first-time publishers lose two or three weeks they did not budget for.
The rules are published in full. Apple's App Store Review Guidelines and Google Play's policy centre are both public, both readable in an afternoon, and both largely ignored until the first rejection email arrives. What follows is the set of rules that actually catches businesses shipping their first app, drawn from those two sources and nothing else.
Why do apps get rejected from the App Store?
The most common rejections are administrative rather than technical: an incomplete submission, a missing privacy policy, no way to delete an account, metadata that oversells, or a permission nobody explained. Apple's guidelines open with app completeness for a reason [1]. Very few rejections say your app is badly built. Most say the reviewer could not verify what you claimed.
That distinction matters commercially, because it changes who fixes it. A rejection for a crash is a developer problem. A rejection for a missing Data safety declaration is a console problem, and the person holding the console login is usually the client, not the agency.
The rejection that costs nothing to avoid
If your app has a login, put working demo credentials in the review notes and keep your backend running during review. Apple's guideline on app completeness asks for exactly this, in plain language: include demo account info, and turn on your backend service if your app includes a login [1].
The failure is entirely mechanical. A reviewer opens the app, sees a sign-in form, has no account, and cannot proceed. The submission fails on access. Nothing about the app was assessed at all. Where a demo account genuinely cannot be provided for legal or security reasons, Apple may accept a built-in demo mode that shows full functionality, but that needs agreeing with Apple in advance rather than assuming.
Test the credentials on a clean device before you submit. An account that works on your machine because you are already authenticated is not a test.
Is a website in a wrapper enough to pass review?
No, and both stores block it from different directions. Apple's minimum functionality guideline states that apps should include features, content, and an interface that take them beyond a repackaged website, and says directly that an app which is not particularly useful, unique, or app-like does not belong on the App Store [1].
Google does not use the phrase, but its functionality policy reaches the same place. It disallows apps that are static without app-specific functionality, naming text-only and PDF-file apps as examples, along with apps with very little content that do not provide an engaging experience [5].
This is worth understanding before you commission a build rather than after. If the honest answer to "what does this do that our mobile site does not" is nothing, you are buying a rejection. That question is the same one we work through in our guide to choosing between a native app and a progressive web app, and for a meaningful share of UAE businesses the correct answer is not to build the app at all.
What both stores require on privacy
Every app needs a privacy policy that loads in two places, and a separate structured disclosure of what it collects. Apple requires the policy linked in your App Store Connect metadata and accessible inside the app, covering what you collect, how, why, who else receives it, how long you keep it, and how a user withdraws consent or requests deletion [1]. Alongside that, App Store Connect requires the App Privacy disclosure, the label showing data types, purposes, whether data is linked to identity, and whether it is used for tracking. It is required for new apps and every update, and must stay accurate [3].
Google's equivalent is the Data safety form, and a privacy policy is a prerequisite for completing it [6]. Google is unusually direct about where responsibility sits: you alone are responsible for making complete and accurate declarations, and apps that do not become compliant face blocked updates or removal [6].
The trap here is the third-party SDK. An analytics library, a crash reporter, or an advertising SDK collects data your declaration has to account for, whether or not you wrote that code. A declaration that describes only what your own code does, while three SDKs quietly collect more, is inaccurate even though nobody set out to mislead. We cover the consent side of this for websites in our guide to cookie consent and privacy for UAE websites.
The account deletion rule that catches older apps
If users can create an account, they must be able to delete it, and Google requires a route that works even after the app is uninstalled. Apple's requirement is in-app deletion for any app supporting account creation [1]. Google requires both an in-app path and a web-based one, a URL someone can visit without having the app installed, and deleting the account must delete the associated data apart from narrow exceptions for security, fraud prevention, or regulatory compliance [7].
That web requirement is the one that gets missed, because it is not an app task. It lands on whoever owns the website, which on most projects is a different supplier entirely. An app built before this policy arrived will not have either path, which is why apps that sailed through review years ago now fail on an update.
Login services and the alternative sign-in requirement
Offering Google or Facebook login on iOS generally obliges you to offer a privacy-respecting alternative alongside it. Apple's login services guideline, numbered 4.8 at the time of writing, requires that an app using a third-party or social login for the primary account also offers an equivalent option that limits collection to name and email, lets the user keep their email private, and does not collect interaction data for advertising without consent [1]. Exceptions exist, including apps that use only their own account system, education and enterprise systems, government identity systems, and apps that are a client for one specific third-party service.
Apple renumbers and retitles guideline sections periodically. Check the current numbering on the live guidelines page before quoting a section in a specification document.
Payments, and why the UAE storefront matters
Selling digital content inside your app generally means using the store's billing, and the external-link exceptions that exist in the United States do not travel. Apple's in-app purchase guideline requires unlocking features, subscriptions, in-app currency, and premium content to run through In-App Purchase, and rules out licence keys, codes, and similar workarounds [1]. On external links, Apple's own text states that in all storefronts except the United States, apps and their metadata may not include buttons, external links, or other calls to action directing customers to purchasing mechanisms other than in-app purchase [1].
The UAE storefront is not the United States storefront. Any business modelling its economics on linking out to its own checkout should read the current guideline text directly before building. This deserves its own treatment, and gets one in our guide to in-app purchases, subscriptions and store commission.
Permissions, purpose strings, and Google's declaration form
Every permission your app requests needs a plain-language justification, and the sensitive ones need Google's separate approval. Apple requires consent for collecting user or usage data even when anonymous, prohibits gating paid functionality behind mandatory data access, and asks that purpose strings clearly and completely describe your use of the data [1]. A purpose string reading "we need camera access" explains nothing. One reading "used to scan delivery barcodes at handover" explains everything.
Google's process is heavier. Sensitive permissions including SMS and call log access, all files access, and broad package visibility can require a Permissions Declaration Form covering your core use case, written review instructions, and a video demonstrating the feature [8]. This triggers an extended review that can run to several weeks, and while it is open you cannot publish any changes to your app, including changes to your store listing [8].
That freeze is the part worth planning around. If your app needs a sensitive permission, start the declaration long before the launch window, not inside it.
Google Play's target API level, and the failure you cannot see
Google enforces a rolling minimum for how modern your Android build is, and falling behind makes your app invisible to new users rather than removing it. As checked in August 2026, new apps and updates were required to target Android 16, while an existing app had to target at least Android 15 to stay visible to new users, with different thresholds again for Wear OS, Automotive, TV and XR [9].
Those numbers move roughly annually, so treat the live page as the source rather than any figure printed here. What does not change is the behaviour on failure. An app below the floor for existing apps stays in the store for people who already have it, but becomes unavailable to new users on newer Android versions, who are shown a message saying the app was made for an older version of Android [9].
This is the quietest problem in app ownership. Nothing crashes, no email arrives, and installs simply taper off while everyone looks at the marketing. It is also the clearest argument for treating app maintenance as a running cost, which we set out in our guide to mobile app maintenance costs in Dubai.
The fourteen-day wall before your first Google Play release
A personal Google Play developer account created after 13 November 2023 must run a closed test with at least twelve opted-in testers for fourteen continuous days before the Production track opens at all [11]. Only then can you apply for production access, which Google says usually takes seven days or less but may occasionally take longer [11].
Read that again if you are planning a launch date. It is not a review outcome and it has nothing to do with the quality of your app. It is a minimum two-week gate that exists before your first submission is possible, and if you do not hit the twelve-tester threshold for the full fourteen days, Production and Pre-registration stay disabled while you keep testing.
We could not confirm whether the same bar applies to organisation developer accounts, and Google's published requirement is written for personal accounts. Check which account type you are registering, because the answer moves your launch by a fortnight.
Finding twelve real testers is its own small project in a company of eight people. Start it early, use staff and friendly customers, and make sure they actually opt in through the tester link rather than merely agreeing over WhatsApp.
How long review takes, honestly
Apple publishes an average and Google publishes an outer bound, and neither is a commitment you can safely pass to a client. Apple's figure is that on average ninety per cent of submissions are reviewed in less than twenty-four hours [2]. That is a rolling platform-wide average, not a service level for your app.
Google's language is more conditional: review may take up to seven days or longer in exceptional cases for certain developer accounts that receive additional scrutiny [10]. That is an outer bound for some accounts rather than a norm for everyone.
There is one mechanism worth knowing on Apple's side. If a bug-fix submission has only minor outstanding issues and there is no legal or safety concern, Apple can offer to approve the current build provided you resolve them in your next release [2]. That avoids a full second cycle, and it is a reason to keep correspondence with App Review constructive rather than combative.
What to do when you are rejected
Read which guideline you failed, fix that specific thing, and resubmit. Apple identifies the guideline section and lets you correspond with App Review inside App Store Connect before resubmitting [2]. Google shows a rejected status and offers a fix-and-resubmit path or an appeal [10].
Appeal only when you believe the reviewer misunderstood your app. Apple's App Review Board allows one appeal per submission that did not pass, closes duplicate appeals without review, and expects specific reasons your app complies rather than general disagreement [4]. Appealing a guideline that plainly applies wastes a cycle you could have spent shipping the fix.
A pattern we see repeatedly. A UAE business commissions an app, the build finishes on time, and the launch slips by a month. Almost none of that month goes on code. It goes on registering a developer account in the right name, writing a privacy policy nobody scoped, building an account deletion flow on a website managed by a different supplier, and discovering the fourteen-day testing requirement after the marketing date is already set. Every one of those is knowable at kick-off.
Does the UAE require approval to publish an app?
We could not confirm any UAE requirement specific to publishing on the App Store or Google Play. We looked for an official government page stating that submitting to the UAE storefront needs a separate licence or no-objection certificate, and did not find one. Claims of that kind appear on advisory sites, and we are not repeating them here because we could not verify them against an official source. If you operate in a regulated sector such as health or finance, confirm your own position with your regulator rather than relying on a general article.
What does apply is the data law. Federal Decree-Law No. 45 of 2021 came into force on 2 January 2022 and covers processing of personal data through electronic systems, inside or outside the country [12]. It is a general law rather than an app-specific one, so it adds no store step, but it does mean an app holding UAE users' data needs a lawful basis, a real privacy notice, and working answers to correction and deletion requests. Those obligations sit comfortably alongside what Apple and Google already ask for.
Separately, and independently of anything either store checks, the business behind a commercial app still needs its own UAE trade licence. That is a company formation matter, not a submission requirement.
What getting this wrong costs
A rejection costs a review cycle plus the fix, and the fix is what varies. A missing demo account costs a resubmission and nothing else. A missing account deletion flow is genuine development work across both the app and your website. A sensitive permission declaration started late can hold your listing frozen for weeks.
If you would rather find these before a reviewer does, a focused test pass on an existing build starts from around AED 4,000 with us, covering the submission checks alongside functional testing. These are our own figures rather than a market survey. Final pricing depends on scope, and the same ground is covered in more detail in our guide to software testing and QA in Dubai.
The recurring cost is smaller and easier to ignore. App maintenance with us starts from around AED 500 a month for a simple, lightly used single-platform app, or budget fifteen to twenty-five per cent of the original build cost per year. Store compliance belongs in that budget, because target API levels and policy deadlines arrive whether or not you have planned a release.
The submission checklist worth keeping
Run this before every submission, not just the first one.
- Demo account credentials in the review notes, tested on a clean device, with the backend live
- Privacy policy reachable from the store listing and from inside the app
- App Privacy disclosure completed on Apple, Data safety form completed on Google, both matching what your SDKs actually collect
- Account deletion available in the app, plus a web URL for Google
- An alternative login offered wherever you offer social sign-in on iOS
- Purpose strings that explain each permission in specific, ordinary language
- Any sensitive permission declaration filed weeks ahead, not days
- Screenshots showing real screens in use, and a description that matches what the app does
- Target API level checked against Google's current requirement
- Developer accounts registered in your company's name, with the agency added as a user
Most of those items cost nothing but attention, and the ones that do not, such as building an account deletion flow, are cheaper to plan than to retrofit. That is the honest summary of app review: the barrier is rarely capability, and almost always preparation.
If you are planning an app and would rather not learn these rules through rejection emails, contact us about the submission path before the build starts rather than after.
References
[1] Apple, App Store Review Guidelines. developer.apple.com
[2] Apple, App Review. developer.apple.com
[3] Apple, App Privacy Details. developer.apple.com
[4] Apple, Submit an appeal to the App Review Board. developer.apple.com
[5] Google Play, Functionality, Content and User Experience policy. support.google.com
[6] Google Play, Provide information for Google Play's Data safety section. support.google.com
[7] Google Play, Understanding Google Play's app account deletion requirements. support.google.com
[8] Google Play, Declare permissions for your app. support.google.com
[9] Google Play, Target API level requirements for Google Play apps. support.google.com
[10] Google Play, Publish your app. support.google.com
[11] Google Play, Testing requirements for new personal developer accounts. support.google.com
[12] The Official Portal of the UAE Government, Data protection laws. u.ae
