I test Arabic builds as a native speaker, and most of the RTL bugs I find would never appear on an English-speaking team's radar — not because they are subtle, but because you need to feel that something reads wrong. Testing Arabic and RTL apps well is a discipline of its own. This checklist collects what I actually check, in the order I check it.
Mirroring: what flips in RTL apps and what must not
In RTL, the layout mirrors: the back arrow points right, list chevrons point left, progress bars fill right to left, and swipe-back gestures reverse direction. But not everything flips. Media controls stay LTR — play still points right because it represents time, not reading direction. Clocks, phone icons, and logos do not mirror either. The bug patterns to hunt: arrows baked into images or icon fonts that ignore layout direction, and swipe gestures that still assume LTR after the layout mirrored around them.
Bidirectional text: where the severe bugs live
Arabic sentences routinely contain LTR fragments — numbers, URLs, English product names, phone numbers — and the Unicode bidi algorithm decides how the mix renders. It often guesses wrong. Classic failures: a phone number like +962 79 000 0000 rendering with the plus sign on the wrong end; "10 items" becoming "items 10"; punctuation jumping to the far side of a mixed sentence. Test every string that combines Arabic with digits or Latin text, and pay special attention to strings assembled by concatenation in code — they break in ways that professionally translated whole strings do not.
Numerals, dates, and formats
Arabic locales may use Western numerals (123) or Arabic-Indic numerals (١٢٣), and the convention varies by country and platform settings. Decide what your product does, then verify it is consistent — one screen showing ١٢٣ next to another showing 123 looks broken to users even if both are "correct." Dates add another layer: order, separators, and month names differ across Arabic locales, and some products also need Hijri calendar support. Verify inputs as well as display: can users type either numeral style into a phone or OTP field, or does validation reject half your audience's keyboard?
Expansion, truncation, and fonts
Arabic translations often run longer than the English source, and because Arabic letters connect and change shape by position, truncation mid-word looks far worse than in Latin script. Check buttons, tab labels, and notification previews using the longest real strings from your translations, not lorem ipsum. Fonts deserve more attention than they get: does your app's custom font actually include Arabic glyphs, or is the OS silently substituting a fallback that clashes with the design? If your content uses diacritics (tashkeel), do they render at all, and do they collide with the line above at your line heights?
Keyboard and input
Type Arabic everywhere text can be entered. Does search normalize alef variants (أ / إ / ا) and teh marbuta, or do users get zero results for reasonable spellings? Check mixed input — an Arabic sentence with an English word in the middle — and watch cursor movement and text selection around the direction change, a classic home of editing bugs.
Pseudo-locales help, but only a native reader signs off
Android's ar-XB pseudo-locale and iOS's right-to-left pseudolanguage are genuinely useful: they catch unmirrored layouts and hardcoded strings early, cheaply, and without waiting for translations, and they are easy to run in CI. But a pseudo-locale cannot judge whether a translation is natural, whether bidi text reads correctly, or whether truncation broke a word's connected shape. Use pseudo-locales to find structural bugs during the sprint, and a real Arabic build in front of a real reader before release.
Takeaway: if you can only afford a short RTL pass, spend it on two things: mirroring of navigation and gestures, and every string that mixes Arabic with numbers or Latin text. That is where the severe bugs concentrate.
Arabic support is not a translation file; it is layout, text rendering, input, and formatting behaving together. A checklist gets you most of the way — a native reader gets you the rest.