Retrofitting right-to-left support is one of the most expensive mistakes in Gulf-market app development. Here is what breaks, why, and what to do instead.
RTL is an architecture decision, not a translation task
The common failure is treating Arabic as a localisation ticket for the end of the project. Someone adds an Arabic strings file, the text renders, and it looks like the job is done. It is not, because right-to-left affects layout rather than content.
In an RTL locale the entire interface mirrors. Navigation moves to the opposite side, back buttons point the other way, progress bars fill in reverse, and any screen with asymmetric spacing needs its padding and margins swapped. If your layout code hard-codes `left` and `right` rather than `start` and `end`, every one of those values is now wrong.
The cost difference is stark. Designing for RTL from the first sprint typically adds 10-15% to layout work. Retrofitting it into a shipped app frequently means rebuilding the navigation layer and revisiting every custom component.
Use logical properties everywhere
The single highest-return rule: never write directional values. Use logical equivalents that resolve based on locale.
In React Native this means `marginStart` and `marginEnd` instead of `marginLeft` and `marginRight`, and `paddingStart`/`paddingEnd` in place of their directional counterparts. In CSS use `margin-inline-start`, `padding-inline-end`, `inset-inline-start` and `text-align: start`. In SwiftUI, `.leading` and `.trailing` already behave correctly; the trap there is people reaching for explicit alignment to fix a visual issue and breaking RTL silently.
A useful enforcement step is a lint rule that fails the build on directional properties in layout code. It is far cheaper to catch these at commit time than during an RTL QA pass three months later.
What does NOT mirror
Mirroring everything is as wrong as mirroring nothing. Several categories must stay in their original orientation, and getting this wrong produces interfaces that feel subtly broken to native speakers.
Media playback controls do not mirror — play still points right, because it reflects tape direction rather than reading direction. Clock icons keep their direction. Logos and brand marks stay as-is. Phone numbers, email addresses and URLs remain left-to-right even inside Arabic text. Numerals are a judgement call: Arabic-Indic numerals are used in some contexts, but Western Arabic numerals are common in UAE commercial interfaces, so ask rather than assume.
Icons that imply forward motion — a next arrow, a submit chevron — should mirror. Icons that represent physical objects generally should not.
Bidirectional text is where subtle bugs live
Mixed Arabic and Latin text in one string is handled by the Unicode Bidirectional Algorithm, and it usually works. The failures cluster around punctuation and embedded LTR content.
A string like "اتصل بنا على +971 4 123 4567" contains an Arabic phrase and an LTR phone number. Without explicit isolation, trailing punctuation can jump to the wrong end of the line. The fix is Unicode isolate characters — U+2066 LEFT-TO-RIGHT ISOLATE through U+2069 POP DIRECTIONAL ISOLATE — wrapped around embedded LTR runs.
Test with real content rather than lorem ipsum. Bidi bugs are invisible in placeholder text and obvious to a native speaker on the first screen.
Typography: your font probably does not cover Arabic
Most Latin-first font families either lack Arabic glyphs entirely or ship a weak Arabic companion. When glyphs are missing the system substitutes silently, so the app renders but looks inconsistent between screens.
Arabic script also needs more vertical space than Latin at the same point size, because of ascenders and descenders in connected forms. Line heights tuned for English will feel cramped, and text that fits an English button often overflows in Arabic. Design with roughly 20-30% more horizontal space for Arabic strings, and avoid fixed-height containers around translated text.
Fonts worth evaluating: IBM Plex Sans Arabic and Noto Sans Arabic both have genuine multi-weight Arabic support rather than a single fallback weight.
Testing RTL properly
Switching the simulator to Arabic is necessary but insufficient, because it changes locale and layout direction together. Both iOS and Android offer a forced-RTL developer setting that flips layout while keeping English text — this is the fastest way to spot layout bugs without needing to read Arabic.
On Android, enable Force RTL layout direction in Developer Options. On iOS, add the `-AppleTextDirection YES` launch argument in your scheme. Run your existing UI test suite under that setting and a surprising number of layout assumptions surface immediately.
Before release, have a native Arabic speaker walk the primary flows. Layout correctness and linguistic correctness are different problems, and automated testing catches only the first.
A realistic sequence
If you are starting fresh: adopt logical properties from day one, pick an Arabic-capable font family before design begins, and add forced-RTL to your CI test matrix. The incremental cost is small.
If you are retrofitting an existing app: audit for directional properties first to size the work honestly, then fix the navigation layer, then components, then screens. Resist shipping partial RTL — a half-mirrored interface reads as broken rather than incomplete.