Arabic and RTL apps: what changes in design and code

Supporting Arabic is not just translating the text. A right-to-left app mirrors its layout, reorders navigation, treats icons and numbers carefully and needs proper Arabic fonts and testing. It is far cheaper to design for RTL from the first screen than to retrofit it, because the change touches almost every screen in the app.

Layout mirrors, but not everything

In an RTL interface the reading flow starts on the right. Lists align right, back buttons sit on the right, progress moves from right to left and tab bars read in the opposite order. Padding and margins that were left and right become start and end.

Not everything flips. Media controls such as play and pause usually keep their orientation, as do charts with a time axis in some contexts, phone number fields and logos. Directional icons like arrows and chevrons should mirror, while icons of real objects generally should not. The rule is to flip things that express direction of reading or navigation, and leave things that represent the physical world.

How it works in React Native

React Native supports RTL through its I18nManager and through start and end style properties in place of left and right. If a codebase is written with start and end from the beginning, mirroring mostly takes care of itself. If it is full of hard-coded left and right values, someone has to go through every screen.

Switching the layout direction at runtime also usually needs an app reload, so decide how language switching will behave and test it. Our mobile apps are built in React Native with Expo, so iOS and Android share one codebase and one RTL strategy.

Text, fonts and numbers

Arabic text needs a font with good Arabic glyphs, and line height often needs more room than Latin text. Test long strings, because Arabic and English translations rarely have the same length and buttons can overflow.

Mixed content is the hard case. A sentence with an English brand name or a product code inside Arabic text can display in a confusing order if direction is not handled. Product names, order numbers and addresses should be tested in realistic mixed form.

Numbers need a decision too. Some audiences expect Western digits and others expect Arabic-Indic digits, so ask your users and make it consistent across the app, receipts and notifications.

Backend and content

RTL is not only a front-end task. The backend should store translations as proper fields, return content in the requested language and keep emails, push notifications, invoices and PDFs consistent with what the app shows. Search should also work across both languages.

Someone who reads Arabic should write and review the copy. Machine translation is fine as a placeholder, but it is risky as the final text on payment screens, legal text and error messages.

Our experience

We have shipped Arabic and English work, including Belleza, a beauty storefront in Bahrain with Arabic and English localisation, and AtUrHome, a last-mile logistics platform in Saudi Arabia with a driver app on the App Store and Google Play.

Testing deserves its own line in the plan. Check every screen in both directions, on small phones and large ones, with long names, long addresses and mixed Arabic and English strings. Also test the keyboard, text selection and date pickers, which can behave differently once the direction changes. Most RTL bugs are small, but users notice them immediately.

If you plan a bilingual app, tell us at the scoping call. It affects design, build and testing time, and we would rather account for it in the written scope than discover it halfway through.