App store optimisation · UAE
Two stores, two languages, and each of the four is indexed by different machinery. Webzenia writes all four, because a listing built for one cannot be found from the others.
Get a read on your store listingsWhat the work is optimising
Three jobs, and every one of them is done four times. Being found, being installed, and staying where you got to once the launch attention has gone.
A Dubai Internet City app company on a free zone licence is competing for words inside a store, not on the web. Each store reads a different set of fields, so the same phrase can rank in one and be invisible in the other.
The icon, the first two screenshots and the rating decide the install before anyone reads a description. In Arabic that set is read right to left, and what the app itself has to do about that is argued on mobile app development.
Store rank is fed by install velocity, retention and ratings, none of which is written into a listing. You can win a position and lose it without changing a word, which is why this is a standing job rather than a project.
How many listings you are running
Almost every UAE app is running the first of these and believes it is running the third. The stores do not treat them as the same thing.
| One, translatedThe same words, twice over | Two, one per storeEnglish only, done properly | Four, written eachTwo stores, two languages | |
|---|---|---|---|
| What carries the words | One keyword set, pasted into fields that do not work alike. | A keyword field on one store, a description on the other. | Four assets, each written for the field that actually indexes it. |
| How much room you get | Whatever survives the translation, usually less than you started with. | The full English allowance, on both stores. | The full allowance on each, counted in the unit each store uses. |
| What the store reads | Half of it. Fields differ and the copy was written for one of them. | Everything you gave it, in one language. | Everything, in both, with the terms researched per language. |
| Storefront serving it | Unconsidered, so the Arabic goes to whichever locale is default. | The English one, which is fine until half your users search elsewhere. | Chosen deliberately, including which Arabic locale carries it. |
| What a change costs | A retranslation, and the same guesswork again. | One edit, and one store still untouched. | One cell at a time, tested, with the other three unaffected. |
| Who ends up finding you | People who already know the name. | English searchers on both stores. | Everyone searching for what you do, in the language they think in. |
Usually, and it is the least expensive of the four to add because the research is already done by then. The honest exception is an app whose audience is genuinely English-speaking and professional, where a second language buys a smaller audience than a second store would. What is never worth it is the first column: a translated listing costs real money, reads as translated, and is indexed on words nobody searched. If the app itself is still being scoped rather than listed, build a mobile app is the earlier conversation.
The UAE context
Webzenia has worked with Gulf clients since 2018. Each of these turns one listing job into four, and none of them appears on a single page of this search.
A Business Bay property portal on a DET mainland licence that works only Google Play abandons the fifth that spends most, and one that works only the App Store abandons three quarters of the devices. Both mistakes are common here, and neither store can be worked the way the other is.
The App Store gives each localisation a name, a subtitle and a keyword field measured in bytes rather than characters, which matters because Arabic costs more than one byte per character. Google Play has no keyword field at all and reads your description instead.
So an ADGM fintech in Abu Dhabi publishing an Arabic listing is authoring against a locale that is not the Emirati one. That is a targeting fact rather than a language one, and it changes which terms are worth researching before a word is written.
Install velocity, retention and ratings move a store rank and none of them is a field anybody can edit. A JLT logistics firm under DMCC with two apps in two categories can rewrite both listings and still lose to an app people keep. We say which half of the problem is ours.
What the work includes
Six pieces of work, each done per cell rather than once. The first two decide what the other four are working with.
The terms people type inside each store, researched separately for each language rather than translated between them, and fitted to the field that indexes them: a byte-counted keyword field on one store, a description on the other
four keyword sets
Name, subtitle, keywords and descriptions written for all four cells against the limits each store sets, with the storefront and locale for each one chosen rather than defaulted
four listings you can edit independently
The icon and the first two frames that decide the tap, produced per language, with the Arabic set ordered right to left rather than reflowed
a creative set per storefront, not one resized
A prompt that asks at the right moment, and public developer replies in the language each review arrived in, because the rating is a ranking input and a conversion one at the same time
a rating that is being managed
Store-side tests on the icon, the first screenshots and the short description, run one variable at a time so a winner is a finding rather than a coincidence
a conversion rate you moved on purpose
Store installs with the organic share separated from the bought one, per store, so the work is visible rather than absorbed into a campaign total. What paid installs cost here is read on digital marketing in Dubai
a monthly read
Our stack
The kit behind four listings that are each written for their own index. Select one to see why it earns its place, and where we argue against it.
App Store Connect is where a localisation actually exists: each one has its own name, subtitle and keyword field, and the console is the only place the real limits are enforced rather than estimated.
We treat each localisation as its own listing rather than a translation slot, so the Arabic cell is researched, written and counted in its own right before it is submitted.
How the engagement runs
The grid is settled before a word is written. Everything after it is done four times, which is the whole reason to decide it first.
We settle which stores, which languages and which storefronts the app should occupy, and what each cell is plausibly worth given where your users actually are. Keyword research runs per cell rather than once, because the terms and the difficulty do not transfer between stores or between languages. Where a cell is not worth opening yet, that is written down with the reason rather than quietly skipped.
Names, subtitles, keyword assets and descriptions are written per cell against the limits each store sets, and counted in the unit each store uses. Creative follows: the icon and the first two frames per language, with the Arabic set ordered right to left rather than reflowed from the English. Nothing is copied between cells, because the two stores do not read the same fields.
Store-side experiments run one variable at a time, reviews are answered publicly in the language they arrived in, and keywords are refreshed as the category moves. Reporting separates organic installs from bought ones per store. Where a position slips because retention slipped rather than because a word changed, that is reported as what it is instead of being tuned around.
Reported per store and per language, with organic kept apart from paid.
Our commitment
This category sells a monthly price and rarely a method. These are the four things we hold ourselves to.
Organic and paid reported separately
A blended install number makes any ASO engagement look successful for as long as a paid budget is running. You get the organic share on its own, per store, so the work is visible and so is its absence.
Your listings and creative stay yours
Everything is written inside your own developer accounts with Webzenia added as a user, and the keyword research and the creative source files are handed over. Leaving costs you a handover, never a rewrite.
We do not guarantee a ranking
Nobody can promise a store position, and a supplier who does is describing something they do not control. What we commit to is four listings written and shipped, the experiments run, and a read that separates what moved from what did not.
We say when the problem is your app
Install velocity, retention and ratings move a store rank and none of them is a field we can edit. Where the listing is doing its job and the product is losing people, you hear that from us rather than a plan to rewrite the subtitle again.
Written per cell, reported organic apart from paid.
Common questions
Keep exploring
Search and Performance Max, built on what you may legally advertise.
Facebook and Instagram, built for an audience that saturates fast.
Reach a named few by title, once you know how many there are.
The ads buy the view. The channel is what keeps earning it.
A pool built on a basis you can produce, and on what it excludes.
Own accounts in two scripts, worked for enquiries not followers.
A cost per customer agreed in writing, then held to.
Enquiries captured, evidenced, and answered on a permitted rail.
Pipeline from the accounts your licence can actually invoice.
Next step
Send both store links. We will come back with what each one ranks for and what the Arabic listings are missing.
Tell us what you need.