There is a version of this project that costs very little and a version that costs a great deal, and the difference was decided before anyone wrote a word of Arabic. It was decided by whether the app was built with leading and trailing layout constraints or with left and right.
That is the honest shape of Arabic app localisation. The translation is the small part. What surrounds it is layout engineering, grammar rules that English does not have, and a set of decisions about which parts of your interface must not mirror. This article covers what actually breaks, drawn from Apple's, Google's and Unicode's own documentation.
We already cover the website side in our guide to multilingual website development and the video side in our guide to Arabic voiceover and subtitling. This one is about native apps, where the mechanics are genuinely different.
Does UAE law require an Arabic app?
We found no requirement that private-sector apps offer Arabic. What the UAE government does publish is that Arabic is the official language, that five other languages have status in the courts, and that road, traffic and commercial outlet signage must be in Arabic and English [14].
The adjacent document people reach for is the National Policy for Digital Accessibility, and it does not help here either. It binds government entities and private companies when they are transacting digitally with government, and its subject is accessibility rather than language choice.
So this is a commercial decision. Make it the way our multilingual website guide argues: from the evidence you already own. The language of enquiries in your inbox and on WhatsApp, device language in your analytics, which segments convert and which stall. No official UAE source publishes language usage percentages, so anyone quoting you one has taken it from somewhere they should not have.
Right to left is a layout problem, not a text problem
Both platforms will mirror your interface automatically, but only if it was built in a way that lets them. Apple's engineering guidance is direct: use the Auto Layout leading and trailing attributes rather than the left and right attributes, and most of the interface appears mirrored in right-to-left languages [2]. Apple's design guidance adds that system-provided components flip automatically, so an app using standard elements and standard layouts might need no changes at all [1].
Android's equivalent has two halves. Add the supportsRtl flag to the application element in your manifest, then replace left and right attributes with start and end throughout your layouts, covering gravity, padding, margins, drawables and alignment [3]. Where both are present and the app targets a recent API, start and end take precedence [3]. For screens needing genuinely different treatment you can supply direction-specific resources in a layout-ldrtl folder, which the system loads for Arabic, Persian and Hebrew [3].
Android's own caveat is worth quoting in spirit: not everything mirrors on its own. Some framework elements do not support right-to-left direction and need explicit handling, and automatic drawable mirroring works for simple graphics whose mirroring is a straightforward flip, with complex multi-element drawables needing deliberate attention [3].
What must never flip
Logos, clocks, photographs and media player controls must not flip, and mirroring one of them is more noticeable than failing to mirror something that should. Apple is unambiguous about the categories: do not flip logos or universal signs and marks, and a flipped logo confuses people and can carry legal consequences [1]. Clocks look the same regardless of reading direction, because clocks work the same everywhere [1]. Photographs, illustrations and general artwork should not be flipped, since flipping changes an image's meaning, and flipping a copyrighted image may be a violation [1].
Material Design agrees and adds specifics. Media controls for video and audio players are always left to right [4]. Clock icons, circular refresh icons and clockwise progress indicators are not mirrored [4].
What should flip is anything expressing direction or reading order. Apple's list covers icons representing text or reading direction, icons showing forward or backward motion, and controls that help people navigate items in a fixed order, which is why a back button points right in Arabic [1]. Controls that refer to an actual direction keep pointing that way [1].
One detail deserves attention because it undermines the idea that this can be handled with a single flag. Material Design states that linear progress indicators should move right to left for most right-to-left languages, and then excepts Hebrew [4]. Right to left is a family of behaviours, not a switch.
Arabic grammar breaks English-shaped workflows
Arabic uses six grammatical plural categories where English uses two, which is the single clearest thing separating translating an app from localising one.
The Unicode CLDR publishes the exact rules [5]. For Arabic: zero when the count is nought, one when it is one, two when it is two, few when the count modulo one hundred falls between three and ten, many when it falls between eleven and ninety-nine, and other for the remaining cases, including exact hundreds.
Apple confirms this in its own documentation, stating that Arabic has different plural forms for the zero, one, two, few, many and other categories, and noting that although Russian also uses a category named many, the rules for which numbers fall into it differ from Arabic's [6].
Look at where those middle categories sit. Few covers three to ten. Many covers eleven to ninety-nine. Those are the quantities real interfaces display constantly: items in a basket, unread messages, days remaining, results found. A translation process built around English's singular-and-plural model has nowhere to put them, so Arabic strings either get forced into the wrong category or fall back to the general form for every quantity. The result is an app that is grammatically wrong in the most ordinary places, every single time.
The fix is to use each platform's plural mechanism rather than concatenating a number onto a string. On iOS that is a String Catalog or the older stringsdict file, mapping each category to its own string [6]. On Android it is a plurals resource supporting the same six category names [7]. Apple notes that only the general category is strictly required, and that a rule supplied for a category a language does not use is simply ignored [6].
Both platforms also push the per-language decision to the translator rather than the developer. Android's guidance is to always supply the one and other strings and let translators determine what their language needs [7], and Apple's export process generates the correct category slots per target language automatically [6]. Your responsibility is to use the mechanism at all.
Text, numbers and the bugs that only appear in Arabic
Use standard text views and the platform handles Arabic's connected letterforms for you. Apple's guidance is to use standard views and controls that automatically handle bidirectional text, and warns that custom text input controls mean handling bidirectional text yourself [2]. That alone is a good argument against custom-drawn text in any app that will carry Arabic.
Fonts are less of a decision than they look, at least on iOS. Apple ships SF Arabic, which it describes as a contemporary interpretation of the Naskh style built to pair with its Latin system font for multilingual typesetting [13]. On Android, the mechanism that maps a script to a fallback font is documented, but we could not confirm on an official page which specific font is mapped to Arabic by default across current versions, so we are not naming one. In practice the safer route on both platforms is to test your actual type at your actual sizes rather than assume a font choice carries across.
Apple does offer one piece of quantified type guidance worth knowing: Arabic or Hebrew text can look too small beside uppercase Latin text, and increasing the right-to-left font size by about two points often works well [1]. That is about visual balance rather than string length. On string length itself, neither Apple nor Google publishes an expansion figure for Arabic against English, so treat any percentage you are quoted as someone's estimate and design your layouts to flex instead.
Mixed-direction content is where correct mirroring still produces wrong output. An English address or a phone number inside an Arabic string will inherit the surrounding direction unless it is wrapped. Apple documents wrapping left-to-right content with Unicode directional formatting characters and using natural writing direction so the system infers direction from the text [2]. Android provides a bidirectional formatter that detects a string's direction and wraps it [3]. The classic symptom is a house number appearing on the wrong side of an address.
Numerals carry a decision most teams do not realise they are making. Apple notes that Arabic text may use Western or Eastern Arabic numerals, with usage varying between countries and regions and even within the same region, and recommends relying on the system's representation for the locale unless your app is specifically about numbers [1]. The digits within one number never reverse, so a phone number reads the same in either direction [1].
There is a related bug that never appears in English testing. Android documents that string formatting without an explicit locale uses the device's own digit set, which breaks machine-readable output such as a database query built from a user-entered number on an Arabic or Persian locale device [3]. User-facing text should follow the device. Machine-readable strings need an explicit locale.
Dates and the Hijri calendar
Both platforms support Islamic calendars natively, and there is more than one for a reason. iOS exposes several calendar identifiers, including a tabular civil variant that follows a fixed cycle and the Umm al-Qura variant used in Saudi Arabia, which Apple describes as based on astronomical calculation rather than tabular behaviour [11]. Android provides an equivalent Islamic calendar through its bundled internationalisation library, selectable through a locale tag with civil and Umm al-Qura variants [12].
The practical point is that this is a decision, not a default. A predictable fixed-cycle calendar suits scheduling. An observational one suits religious dates. If your app schedules anything against Hijri dates, pick deliberately.
Your store listing is a separate project
An Arabic listing and an Arabic app are two independent decisions, and Apple says so plainly: languages on the App Information page in App Store Connect are metadata, which differs from adding languages to your app in Xcode when you localise the binary [8].
Two details are worth planning around. First, Apple lists Arabic as the default App Store language for the United Arab Emirates, alongside Saudi Arabia, Bahrain, Iraq, Jordan, Kuwait, Oman, Qatar and Yemen [9]. Arabic-preferring shoppers in your own market are the default audience for your listing before you do anything.
Second, screenshots do not translate themselves. Apple states that when you add a language, screenshots and properties default to those of the primary language, with description and keywords the exceptions that do not inherit [8]. Google states that adding text translations without localised graphic assets means your graphics show from the default language [10]. Either way, an Arabic listing quietly ships with English screenshots until a person replaces them, which is where most half-finished Arabic listings come from.
On Google Play, keep two mechanisms apart. Play Console distinguishes store listing localisation by language from custom store listings by country or region, recommending the latter when you want to differentiate by market [10]. An Arabic translation is a language feature. A UAE-specific listing with Gulf imagery is a regional one.
There is also a route worth knowing for a market as multilingual as this one. Android 13 and later supports per-app language preferences, so a user whose phone is in English can choose Arabic in your app specifically [3]. Device language is a weak proxy for preference here, and an in-app switch is usually worth building.
Testing without reading Arabic
You can catch most layout defects before a translator sees anything. Android exposes a Force RTL layout direction option in on-device developer options, which renders your English build in right-to-left layout [3]. Broken alignment, clipped labels, and icons pointing the wrong way all show up immediately, in a language you can read.
What it will not catch is grammar, tone, or a plural category filled with the wrong string. That needs a native reviewer looking at real screens with real data, not a spreadsheet of strings out of context.
A pattern worth avoiding. An app ships in English, does well, and Arabic is added a year later as a translation line item. The strings come back in a fortnight and the project then runs for two months, because every screen used left and right constraints, the plural strings were concatenated, and nobody had decided whether the video player controls should mirror. None of that was a translation problem. All of it was decided at build time.
What it costs
Adding Arabic to an existing app starts from around AED 4,000 with us, where the app was built with localisation in mind and strings are already externalised. It rises steeply where left and right were hardcoded throughout, because at that point you are paying for a refactor rather than a translation. These are our own figures rather than a market survey, since no official body publishes rates for this work. Final pricing depends on scope.
The number that catches people out is the recurring one. Our mobile app development cost guide puts ongoing Arabic content work at around AED 600 to AED 1,500 a month where you publish updates frequently, because every new screen, notification, error message and push message needs translating and reviewing again. A second language behaves like a subscription rather than a project.
For comparison, a second language on a website starts from around AED 2,500 in our multilingual guide. Apps cost more for the reason this whole article describes: a website language is largely a content problem, and an app language is a layout and grammar problem as well.
If you are building now
Doing these on a new build costs close to nothing and removes the expensive version of this project entirely.
- Use leading and trailing constraints on iOS, and start and end attributes with the supportsRtl flag on Android
- Externalise every string, including error messages and notification text
- Use the plural mechanisms from day one, even in English, so the six Arabic categories have somewhere to go
- Format numbers and dates with the locale, and pass an explicit locale for anything machine-readable
- Decide your unmirrorable elements early: logos, clocks, media controls, photographs
- Run your English build in forced RTL once a sprint and look at it
- Treat the store listing as separate work, with its own screenshots
If you are weighing an Arabic version and want a straight answer on what your existing app would take, contact us and we will look at how it was built before quoting anything.
References
[1] Apple, Human Interface Guidelines: Right to left. developer.apple.com
[2] Apple, Supporting Right-to-Left Languages. developer.apple.com
[3] Android Developers, Support different languages and cultures. developer.android.com
[4] Material Design 3, Bidirectionality and RTL. m3.material.io
[5] Unicode CLDR, Language Plural Rules. unicode.org
[6] Apple, Localizing strings that contain plurals. developer.apple.com
[7] Android Developers, String resources: quantity strings. developer.android.com
[8] Apple, Localize app information, App Store Connect Help. developer.apple.com
[9] Apple, App Store localizations reference. developer.apple.com
[10] Google Play Console Help, Translate your store listing. support.google.com
[11] Apple, Calendar.Identifier, Foundation documentation. developer.apple.com
[12] Android Developers, IslamicCalendar reference. developer.android.com
[13] Apple, Fonts. developer.apple.com
[14] The Official Portal of the UAE Government, Fact sheet. u.ae
