Most app store optimisation advice fails at the first step, because it treats the App Store and Google Play as two versions of the same thing. They are not. Apple searches four fields, one of which your users never see. Google has no equivalent hidden field at all, and reads the description your users are reading.
That single difference means the same listing text pasted into both stores is wrong in at least one of them. What follows is drawn only from what Apple and Google publish about their own systems, which turns out to be more than most people assume and considerably less than the tool vendors imply.
What is app store optimisation?
App store optimisation is the work of getting found and getting chosen inside the App Store and Google Play, rather than through Google or advertising. It splits cleanly into two halves that most teams collapse into one: the text fields that decide whether you appear for a search, and the images and ratings that decide whether anyone taps install once you do.
Getting the first half right and the second half wrong produces impressions with no downloads. That combination is visible in both stores' own analytics, which is the reason to look at conversion rate rather than installs alone.
What does the App Store actually search?
Apple searches four fields, and states them plainly: your app name, your subtitle, your keywords, and your company name [1]. Apple's discoverability guidance goes further and describes ranking as a combination of text relevance, explained as matches for the title, keywords, and primary category, and customer behaviour, explained as downloads plus the number and quality of ratings and reviews [2].
Read that list for what it leaves out. The description is not named among the text-relevance factors. Apple never states in plain words that the description carries no search weight, so we are not going to put those words in Apple's mouth, but the omission is consistent and the neighbouring field is explicit: Apple says promotional text does not affect search ranking and should not be used to display keywords [3].
The practical conclusion is freeing rather than restrictive. Your App Store description does not have to carry search terms, so it can be written purely to persuade the person already reading it.
The 100-character field your users never see
Apple gives you a keywords field inside App Store Connect that is capped at 100 characters, entered comma-separated with no spaces, and never shown on your product page [3]. Apple's guidance is that keywords help determine where your app displays in search results, so choose them carefully [3].
One hundred characters is tighter than it sounds. A few practical consequences follow from the format itself: you do not need to repeat words already in your app name or subtitle, since those are separately searched, and spaces after commas would waste characters you cannot spare. Singular and plural forms, and the terms a UAE user would actually type rather than the terms your industry uses internally, are what belong there.
What does Google Play actually search?
Google Play has no hidden keyword field, and its description is live text that both users and the ranking system read. Google's discovery guidance says metadata such as title, description, and category, along with other signals, is used to determine which apps best address a query [8].
Google is unusually direct about the tension this creates. Its store listing guidance tells developers to apply search sense in the description, while its policies separately prohibit keyword spamming, and its own advice is not to fill a description with lists of words unrelated to the app, using everyday language rather than a list of keywords [7][9].
So the Google Play description has to do two jobs in the same sentence. It has to read like a human wrote it for a human, and it has to contain the phrases someone would search. That is genuinely harder than filling in a hidden field, and it is why the two listings need writing separately rather than once.
The asymmetry, and what it means for your listing
Copying your App Store listing into Google Play wastes Apple's keyword field or fills Google's description with keyword soup. Set out side by side, the difference is stark: on the App Store your search terms live in an invisible 100-character field and the description persuades; on Google Play the 80-character short description and the 4,000-character full description are both visible text and both feed search.
| App Store | Google Play | |
|---|---|---|
| App name | 30 characters, searched | 30 characters, searched |
| Subtitle or short description | Subtitle, 30 characters, searched | Short description, 80 characters, visible and searched |
| Keyword field | 100 characters, hidden from users | No equivalent field exists |
| Full description | 4,000 characters, not named as a ranking input | 4,000 characters, explicitly a search input |
| Promotional text | 170 characters, explicitly not a ranking factor | No equivalent field |
Character limits and field behaviour are confirmed against Apple's product page guidance and Google's store listing help [3][7]. Both stores revise these pages, so check the live limits before you commission copy.
Naming, subtitles, and what Google will not accept
Both stores cap the app name at thirty characters, and Google adds rules about what may go in it. Google's guidance is that a title should accurately describe the app's functionality and content, be unique and accessible, avoid profanity, all-capitals except as part of a brand, emojis, and special characters, and it cannot include promotional language such as free or no ads, or claim rankings and awards [7].
Apple's subtitle is the most valuable line in either listing. At thirty characters it is both one of the four searched fields and the line users read directly under your name. Apple frames its purpose as summarising the app in a concise phrase, and suggests using it rather than the app name to explain your value in more detail [3]. It is the only place where a search match and a sales argument can be the same words.
Screenshots and previews
Your first few screenshots are doing work in search results, not only on your product page. Apple allows up to ten screenshots and up to three app previews, and notes that depending on orientation the first one to three images appear in search results when no app preview is available [3]. Previews run to a maximum of thirty seconds and autoplay muted, which is why the opening seconds have to communicate without sound [3].
Google requires a minimum of two screenshots to publish at all, and recommends at least four at a reasonable resolution to be eligible for enhanced placement in recommended sections [10]. A feature graphic is a Google Play concept with no App Store equivalent, and it surfaces in places your screenshots do not.
The honest summary is that screenshots are where most listings are weakest, because they are usually exported at the end of a build by whoever has the design files rather than designed as an argument. Three screenshots that explain what the app does for a specific person beat ten that show every screen.
Category, tags, and why the wrong one costs you twice
On the App Store the primary category is a named ranking input, not just a navigation choice. Apple lists it among text-relevance factors, says the primary category is important for discoverability, and warns that choosing categories inappropriate for your app is against the App Review Guidelines [2][4]. That means a category chosen to chase a less competitive chart can cost you a rejection as well as relevance.
Google assigns one category per app plus up to five discovery tags, and requires the relevance of a tag to be clear to a user unfamiliar with the app based on the store listing or the initial experience [11].
Do ratings and reviews affect ranking?
Both stores name them as ranking inputs in their own documentation. Apple lists customer behaviour, meaning downloads and the number and quality of ratings and reviews, as one of its two ranking factor groups [2]. Google describes ranking as drawing on a combination of ratings, reviews, downloads, and other factors [8].
The rules on asking are stricter than most teams realise. Apple's sanctioned prompt is capped at a maximum of three per 365-day period, and you control neither the wording nor whether it actually appears [5]. Google's in-app review API has a time-bound quota that Google explicitly describes as an internal detail subject to change, and Google advises against building a custom button that triggers it, because the quota may already be spent and the dialog will silently not appear [12].
Both stores prohibit buying the outcome. Apple's review guidelines bar forcing users to rate or review in order to access functionality or content [6]. Google prohibits inflating ratings, reviews, or install counts by illegitimate means, naming incentivised installs, reviews, and ratings, and asks that prompts be clear and non-deceptive [13].
Google adds a rule that catches a common design. Your app must not ask the user any question before or while presenting the rating prompt, including whether they like the app or how they would rate it [12]. The filter-out-the-unhappy-users pattern is not permitted.
One claim we will not repeat: that shipping updates more frequently improves ranking. Neither store states it in their own documentation. Ship updates for the reasons that hold up, including store policy compliance, which moves whether or not you do.
Arabic listings and the UAE storefront
Both stores support Arabic as a full listing language, and Apple will not carry your keywords across for you. Arabic is a supported App Store localisation language, and Play Console lists Arabic among the languages it supports for store listing translation [14][15].
The detail worth knowing is in Apple's own help text: when you add a language, screenshots and properties default to the primary language, except for the description and keywords [16]. Those two start empty deliberately. An Arabic keyword list has to be built from how Arabic-speaking users phrase a search, which is frequently not a translation of your English list.
The UAE is also its own competitive picture rather than a slice of a global one. Apple calculates summary ratings per territory rather than globally, and users can search with localised keywords in the regions where that language is supported [5][16]. Google offers country and region specific custom store listings as a separate mechanism from language translation [15].
What neither store publishes is any suggestion that Arabic listings rank more easily or receive preferential treatment. That argument circulates widely, and it may well be true in your category simply because fewer competitors bother, but it is a commercial judgement you should test rather than a rule either store confirms. If you are weighing full Arabic support rather than just a listing, our guide to Arabic voiceover, subtitling and localisation covers the wider question.
What you can measure, and what nobody can
Both stores give you defined metrics and free A/B testing, and neither gives you a keyword rank. Apple publishes precise definitions: impressions counts views of more than one second across the Today, Games, Apps, and Search tabs including product page views; conversion rate is total downloads and pre-orders divided by unique device impressions; first-time downloads, redownloads, sessions, active devices, deletions, and crashes are each separately defined [17]. Play Console reports installs, uninstalls, active users, ratings volume, store listing visitors and acquisitions, and crash and non-responsive reports [18].
The testing tools are the part most teams never switch on. Apple's Product Page Optimization tests icons, screenshots, previews, and descriptions against live traffic using Bayesian techniques, requires a minimum number of attributed downloads before reporting anything, applies a confidence threshold before labelling a variant better or worse, and runs for a bounded period [19]. Google's Store Listing Experiments tests the icon, feature graphic, screenshots, and localised descriptions against your current listing, with a calculator for estimating time to significance and a stated auto-stop [20]. Both sets of mechanics are product features that Google and Apple change, so confirm the current limits in your console.
Neither store reports an exact keyword rank position anywhere in its documented metrics. Any tool telling you that you rank fourth for a term is estimating. Those estimates are useful for spotting movement and useless as a contractual promise.
Why nobody can tell you what ASO is worth
There is no credible figure for how much app store optimisation lifts downloads, because neither Apple nor Google publishes one. Every version of that statistic we found came from a company selling the service, which is not a source we will cite.
What is measurable is your own result. Run a change through Apple's Product Page Optimization or Google's Store Listing Experiments and you get a lift for your app, in that test, over that window. That number is real and it is yours, and it does not transfer to anyone else's app. Anyone quoting you an industry average for a service they are selling is describing their marketing, not your outcome.
A pattern worth recognising. A UAE business launches an app, sees flat installs, and buys an ASO retainer. Three months later the terms have been fiddled with and nothing has moved, because the actual problem was two screenshots showing a login screen and an app name that used all thirty characters on the company's legal entity. The cheapest wins in this field are usually structural and one-off, not monthly.
What ASO costs
A one-off listing overhaul starts from around AED 2,500 with us. That covers keyword research per store and per language, rewritten metadata for both listings separately rather than copied, and a screenshot plan built around what the app does for a specific user. An ongoing programme starts from around AED 1,500 a month, covering iteration, experiments, and review monitoring.
These are our own figures, taken from projects we quote and run rather than a published market survey, because no government body or platform publishes rates for this work. Final pricing depends on scope.
For context against the rest of your marketing, our SEO cost guide sets out where organic search sits, and the store account setup itself is already scoped inside our mobile app development cost guide. Keeping a listing current is part of the ongoing work covered in our app maintenance guide.
Where to start
If you do nothing else, do these in order.
- Rewrite the app name and Apple subtitle so the thirty characters explain what the app does, not who owns it
- Fill Apple's keyword field properly, with no spaces after commas and no words already in the name or subtitle
- Rewrite the Google Play short and full descriptions as their own text, not a paste of the App Store version
- Replace the first three screenshots with ones that state a benefit in words a user would recognise
- Check your primary category is the honest one, on both stores
- Switch on the store's own A/B testing before paying anyone for an opinion
- Add an Arabic listing with its own researched keywords if a real share of your users prefer Arabic
Most of those cost nothing but a careful afternoon. That is the part the tool vendors tend not to lead with.
If you would like the listing work done properly once rather than fiddled with monthly, contact us and we will start with what your current listing is structurally getting wrong.
References
[1] Apple, View and edit app information, App Store Connect Help. developer.apple.com
[2] Apple, App Store Discoverability. developer.apple.com
[3] Apple, Product Page. developer.apple.com
[4] Apple, App Store Categories. developer.apple.com
[5] Apple, Ratings and Reviews. developer.apple.com
[6] Apple, App Store Review Guidelines. developer.apple.com
[7] Google Play, Set up your app's store listing. support.google.com
[8] Google Play, How Google Play works: discovery and ranking. support.google.com
[9] Google Play, Store listing and promotion policy. support.google.com
[10] Google Play, Store listing best practices and graphic assets. support.google.com
[11] Google Play, Choose a category and tags for your app. support.google.com
[12] Google, In-app review API, Android Developers. developer.android.com
[13] Google Play, Spam and minimum functionality policy. support.google.com
[14] Apple, App Store localizations, App Store Connect Help. developer.apple.com
[15] Google Play, Translate your store listing. support.google.com
[16] Apple, Localize app information, App Store Connect Help. developer.apple.com
[17] Apple, App Analytics metrics definitions. developer.apple.com
[18] Google Play, View app statistics in Play Console. support.google.com
[19] Apple, View Product Page Optimization results. developer.apple.com
[20] Google Play, Run store listing experiments. support.google.com
