Most Arabic app problems are not caused by bad translation. They are caused by an interface that was designed for English and then flipped. In RTL app design, mirroring the layout is the easy part — what breaks is everything around it: icons, numbers, mixed-language text, fonts, dates, gestures and charts.
Below are the ten RTL app design issues we check on every Arabic-first app, with what to do about each one. If you are planning an app for Saudi users, raise these with your mobile app development team before design starts, not during testing — they are cheap to get right early and expensive to fix late.
1. Mirroring the layout — but flipping the wrong icons
In right-to-left (RTL) layouts the whole screen mirrors: navigation, lists, progress and reading order run from the right. Icons that show direction should flip with it — back and forward arrows, chevrons in lists, "next" buttons, undo and redo, and send icons.
Icons that represent real-world objects or fixed conventions should not flip: a clock, a checkmark, a camera, a phone handset, a search magnifier, logos, and media controls such as play and fast-forward, which follow the direction of the media rather than the text. Make a list of every icon in the design system and mark each one "mirror" or "keep". Developers cannot guess this.
2. Arabic and Western numerals, mixed carelessly
Arabic has its own digits (٠١٢٣) as well as the Western digits (0123) used in English, and both are seen in Saudi Arabia. The mistake is not choosing one; it is mixing them on the same screen — an Arabic-digit price next to a Western-digit order number.
- Decide one numeral style for the Arabic interface and apply it everywhere.
- Accept both styles in input fields and normalise them before saving — a customer typing a phone number with Arabic digits should not get an error.
- Keep phone numbers, card numbers and codes in a consistent left-to-right order, even inside RTL screens.
- Check where the currency label sits relative to the amount in each language.
3. Bidirectional text: brand names, URLs and codes inside Arabic
Arabic sentences often contain English: brand names, product codes, email addresses, URLs, usernames. The text engine has to guess which direction each piece runs, and it often guesses wrong around punctuation, brackets and numbers. The result is a full stop on the wrong side or a phone number split in two.
Mark these segments explicitly as left-to-right in the code, using the platform's text-direction and isolation features, and test every screen where user-generated or mixed content appears — names, addresses, search results and chat.
4. Fonts, line height and truncation
Arabic script has taller ascenders and deeper descenders than Latin, plus dots and diacritics above and below the letters. A line height that suits English will clip Arabic or crowd it.
- Choose an Arabic typeface designed for screens, paired with your Latin font, rather than relying on a system fallback.
- Give Arabic more vertical space, and avoid fixed-height text boxes.
- Never add letter-spacing to Arabic; it breaks the joins between letters.
- Watch truncation. An ellipsis that cuts an Arabic word mid-way can change or hide the meaning. Allow two lines where labels matter.
5. Text expansion and contraction
The same message can be much shorter or longer in Arabic than in English, and it changes again in button labels, tabs and notifications. Designs built around English string lengths break in Arabic: buttons overflow, tab labels wrap, and headings push content off screen.
Design with flexible widths, test with the longest real strings in both languages, and avoid putting text inside images where it cannot adapt.
6. Keyboards and input types
Forms are where Arabic apps feel most broken.
- Use the right input types so the correct keyboard appears: numeric for phone numbers and amounts, email for email addresses.
- Fields for email, URLs, passwords and codes should be left-to-right even in the Arabic interface; name and address fields should follow the language the user types.
- Align placeholders, labels and error messages consistently with the field.
- Test search with Arabic queries, including spelling variations and with and without diacritics.
7. Dates and the Hijri calendar
Many Saudi users work with both the Gregorian and the Hijri calendar. Depending on the app — government-related services, HR, bookings around Ramadan and Hajj — users may expect Hijri dates, Gregorian dates or both.
- Decide which calendar each screen shows, and whether users can choose.
- Use the platform's calendar and locale support rather than hand-rolled conversions.
- Show Arabic month names in the Arabic interface, and check how date pickers behave in RTL.
- Remember that the working week and weekend in Saudi Arabia differ from Western defaults when you design schedules and delivery slots.
8. Charts, progress bars and sliders
Progress bars, step indicators and sliders should normally run right to left in Arabic, because they represent reading order. Charts are less obvious: some teams mirror time axes, others keep them left to right because users are used to reading graphs that way. Either can work — what fails is mixing both in one app. Decide a rule, apply it to every chart and progress element, and test it with users.
9. Swipe gestures and navigation direction
Gestures carry direction too. In an RTL interface, the screen the user came from sits on the right, so the back gesture and page transitions should mirror. Carousels, onboarding swipes, image galleries and swipe-to-delete actions all need a deliberate decision.
The common bug is a mirrored layout where swiping still moves the "wrong" way, so the next onboarding step slides in from the side the user just read. Test every gesture in Arabic on real devices, on both iOS and Android.
10. Testing with real Arabic content — and an Arabic store listing
Lorem ipsum hides every problem above. Design and test with real Arabic copy, real Saudi names and addresses, real product titles, and long and short versions of each. Include mixed Arabic-English content, because your users will.
Then finish the job in the stores. The App Store and Google Play both let you localise the app name, description and screenshots. An Arabic-first app with English-only store screenshots tells Saudi customers it was not built for them. Write the Arabic listing natively and capture screenshots from the Arabic interface.
Where these RTL app design mistakes come from
Almost all ten come from one decision: treating Arabic as a translation step at the end. Whether you build native or cross-platform — see native vs cross-platform app development in Saudi Arabia — RTL support should be part of the design system from the first screen, alongside your bilingual brand guidelines.
Work with us: we design and build Arabic-first iOS and Android apps for Saudi businesses — see our mobile app development service, or read native vs cross-platform app development in Saudi Arabia.
FAQ
Do Flutter and React Native support RTL? Yes, both support right-to-left layouts. But framework support only handles the basics; icon choices, numerals, fonts, gestures and charts are still design decisions your team has to make.
Should the Arabic app use Arabic or Western digits? Either can work. The important thing is to choose one for the interface, use it consistently, and accept both in input fields.
Should we design English first and then Arabic? If most of your users are Arabic speakers, design Arabic first and adapt to English. At the very least, design both side by side from the start.
How do we test RTL properly? Use real Arabic content on real iOS and Android devices, include mixed-language text, and have native Arabic speakers walk through every main flow.