Most RTL launch failures aren't caused by engineers who didn't know better — they're caused by assumptions about who was handling which part of the review. This checklist exists to close that gap before it becomes a post-launch incident.
This checklist is an operational artifact. It's designed to be copied into a pull request template, attached to a release sign-off workflow, or handed directly to a localization QA vendor as a handoff specification. If your team has already read through our post on RTL layout testing and the five platform-specific ways RTL breaks your mobile app, you have the theoretical grounding. This post is what you do with it.
Who this is for: Engineers and QA leads doing a final review before launching Arabic, Hebrew, Persian/Farsi, or Urdu support. It's also useful for engineering managers who need a concrete handoff document — something that answers "what exactly are we checking and who's responsible?"
Scope: Items cover iOS, Android, and React Native. Platform-specific items are labeled with [iOS], [Android], or [RN]. Items without a platform label apply to all three.
How to use it: Treat this as a gate, not a suggestion. Every unchecked item is a potential regression or a user-facing bug in a market you presumably care about enough to ship into.
Assign to: developer
1. All custom views respect layoutDirection / semanticContentAttribute — verified with pseudo-RTL locale
[Android] Set android:layoutDirection="rtl" in your debug build and inspect every custom view. Anything that positions children manually (custom onDraw, manual coordinate math) will need explicit RTL handling.\
[iOS] Check semanticContentAttribute on UIView subclasses that override layout. The default inherits correctly, but manual overrides break it.\
[RN] React Native respects the device locale for layout direction, but inline styles with hardcoded left/right will not — see item 5.
2. Navigation flow direction is mirrored (back gestures, swipe navigation, ViewPager/PageView)
[Android] ViewPager2 handles RTL correctly; ViewPager (v1) does not. If you haven't migrated, this is overdue.\
[iOS] The standard navigation controller back-swipe mirrors automatically. Custom transition animations and edge-swipe gesture recognizers do not.\
[RN] react-navigation stack navigator mirrors correctly in recent versions. Lateral swipe gestures in custom navigators need manual RTL testing.
3. Directional icons are mirrored (autoMirrored / flippedForRTL) — back arrows, forward arrows, progress bars
[Android] Use android:autoMirrored="true" in your vector drawables. Run ./gradlew lint and check for RtlCompat warnings on drawables that should be mirrored but aren't flagged.
<!-- res/drawable/ic_arrow_back.xml -->
<vector xmlns:android="http://schemas.android.com/apk/res/android"
android:autoMirrored="true"
... >
[iOS] Use .imageFlippedForRightToLeftLayoutDirection() on UIImage for directional assets.
let backArrow = UIImage(named: "ic_arrow_back")?.imageFlippedForRightToLeftLayoutDirection()
4. Non-directional assets are NOT mirrored — logos, play/pause, checkmarks, star ratings
This is the mirror-image of item 3, and it's easier to get wrong. A mirrored logo or a backwards checkmark is a visible quality signal to Arabic and Hebrew users. Audit every icon that was given autoMirrored="true" and confirm it actually represents a directional concept.
5. No hardcoded left/right gravity or text alignment in XML or code ([Android] Lint RtlHardcoded passes clean)
<!-- WRONG -->
<TextView android:gravity="left" ... />
<!-- CORRECT -->
<TextView android:gravity="start" ... />
Run Android Lint with the RtlHardcoded check enabled and treat warnings as errors in your RTL release gate. In React Native, alignItems: 'flex-start' respects layout direction; alignItems: 'left' is not even a valid value, but marginLeft and paddingLeft are — and they will not mirror.
6. No hardcoded textAlignment = .left or .right in iOS code — uses .natural or .justified
// WRONG
label.textAlignment = .left
// CORRECT
label.textAlignment = .natural
.natural resolves to leading edge based on the locale. This is a simple find-replace exercise, but it needs to happen before a human QA reviewer spends time on it.
7. Horizontal ScrollView and carousel direction is correct in RTL
The first item in a horizontal carousel should appear on the right in RTL. This is frequently wrong because content is loaded left-to-right programmatically, independent of layout direction. Test this with actual Arabic or Hebrew content loaded in the view, not placeholder content.
8. FlatList / RecyclerView horizontal scroll direction is RTL-aware
[Android] RecyclerView with LinearLayoutManager supports setLayoutDirection(View.LAYOUT_DIRECTION_RTL). Verify it's not being overridden.\
[RN] FlatList horizontal mode does not automatically reverse scroll direction based on locale. You may need to set style={{ transform: [{ scaleX: -1 }] }} on the list and { transform: [{ scaleX: -1 }] }} on each item — a known and documented workaround that has real visual tradeoffs. Verify your approach is intentional.
Assign to: developer
9. Arabic and Hebrew text renders with the correct font — no Latin-only font fallback
If you've specified a custom font that doesn't include Arabic or Hebrew glyph coverage, the system will silently fall back to a different font for those characters. The visual result ranges from "slightly inconsistent" to "completely broken." Test with actual strings loaded from your production translation files, not hardcoded test strings.
10. Arabic text uses connected letterforms — no glyph isolation bugs
Arabic is a cursive script. Letters connect differently depending on their position within a word. If your string handling is mangling the encoding — particularly if strings pass through any non-Unicode-aware text processing — you may see isolated glyphs instead of connected forms. The word "مرحبا" (hello) should not look like five disconnected characters.
11. Bidirectional strings (mixed Arabic + numerals, Arabic + brand names) render correctly
Bidi strings are where things get technically interesting. The Unicode Bidirectional Algorithm handles most cases correctly, but edge cases around punctuation, embedded LTR segments, and paragraph-level directionality are real failure points. Test with strings that actually appear in your UI — product names embedded in Arabic sentences, prices inside Arabic copy, URLs inside translated strings.
12. Line height and font metrics accommodate Arabic diacritics (tashkeel) without clipping
Arabic diacritics extend above and below the baseline. If your line height is set to exactly match Latin font metrics, tashkeel will be clipped — visible as chopped-off accent marks. Check this with strings that actually contain diacritics, since many Modern Standard Arabic translations omit them while Gulf-market Arabic may include them.
13. No text truncation on translated strings
Arabic and Hebrew do not follow a predictable length relationship to English. Arabic can be significantly shorter (Arabic uses fewer characters to express some concepts) or longer (especially for formal/MSA register). Hebrew tends to be shorter than English. Neither assumption is safe. Verify that your UI handles variable-length strings gracefully across the full range of your translated content.
14. RTL punctuation is present in translations where appropriate
Arabic has its own comma (،) and question mark (؟). If your translations contain Latin punctuation marks, that's a quality error — either the translator used the wrong characters, or your translation tooling substituted Latin equivalents. Neither is acceptable in a production app. This is a string quality check, not a rendering check.
Assign to: QA
15. Numbers display in the correct numeral system for the target locale
This is a product decision that needs to be made explicitly, not left to chance. ar-SA conventionally uses Eastern Arabic-Indic numerals (١٢٣). ar (generic Arabic) defaults to Western numerals (123) in most system formatters. Confirm which locale tags you're shipping and what numeral system your target market expects.
// iOS — always use NumberFormatter, never format numbers manually
let formatter = NumberFormatter()
formatter.locale = Locale(identifier: "ar-SA")
formatter.numberStyle = .decimal
let result = formatter.string(from: 1234) // "١٬٢٣٤"
// Android
val formatter = NumberFormat.getInstance(Locale("ar", "SA"))
val result = formatter.format(1234) // "١٬٢٣٤"
16. Currency formatting uses locale-aware formatter — no hardcoded $ prefix concatenation
A string built as "$" + amount is wrong for every locale that isn't en-US. Use NumberFormatter (iOS) or NumberFormat.getCurrencyInstance(locale) (Android) and let the formatter handle symbol placement, spacing, and the symbol itself.
17. Date and time formatting respects locale calendar
The default calendar in ar-SA is the Hijri calendar (islamic-umalqura). If your app shows event dates, timestamps, or scheduling UI, you need a deliberate decision here: are you showing Gregorian dates (common in international-facing apps) or Hijri (required for some government and regional use cases)? Whatever you decide, the formatter needs to reflect it explicitly — don't rely on a default that might differ between OS versions.
18. Percent and unit symbols appear on the correct side of the value
In Arabic locales, percent signs and some unit symbols appear on the left of the number (i.e., the trailing position in RTL). Using NumberFormatter with .percent style handles this automatically. Manually appending % does not.
Assign to: developer (automated checks) + localization lead (quality review)
19. All translated strings have been checked for placeholder parity
Missing or reordered placeholders cause crashes in production. This is one of the most common failure modes in AI-assisted translation workflows — see why placeholders break during translation and how to make them safe for a full breakdown. Your CI pipeline should be running a placeholder validation step on every strings file before it merges.
// React Native — source
{ "greeting": "Hello, {name}! You have {count} messages." }
// Translated — broken (placeholder renamed)
{ "greeting": "مرحباً، {user}! لديك {count} رسالة." }
// Translated — correct
{ "greeting": "مرحباً، {name}! لديك {count} رسالة." }
20. Plural forms are present and correct for Arabic (all 6 CLDR categories)
Arabic has six grammatical plural categories: zero, one, two, few, many, and other. English has two. Most translation workflows that haven't explicitly handled this will produce Arabic plural files with only one and other entries — meaning your UI will use the wrong grammatical form for numbers like 3, 11, or 100.
[Android] The <plurals> resource in strings.xml supports all CLDR quantities. Verify all six are present for Arabic strings that use plurals. See Android plurals explained for the full breakdown.\
[iOS] .stringsdict handles Arabic plurals correctly when all six keys are populated. See iOS pluralization with stringsdict.\
[RN] ICU plural rules in React Native support Arabic categories. See React Native pluralization explained.
21. No untranslated English fallback strings leaking into Arabic or Hebrew UI
Run a coverage check on your Arabic and Hebrew strings files against the source locale. Every key that exists in English should have a translation. Missing keys that silently fall back to English are a common result of string additions that happened after the initial translation batch.
22. Gender agreement in Hebrew translations has been reviewed by a native speaker or professional reviewer
Hebrew grammatical gender affects verb conjugation, adjective agreement, and pronoun choice in ways that automated tools frequently miss. A fluent speaker can produce grammatically correct Hebrew that still has gender agreement errors in context — because gender agreement depends on who is being addressed, which requires understanding the UI flow. Automated checks cannot catch this. Schedule a native-speaker review for Hebrew UI strings that address the user directly.
Assign to: QA
23. Text input fields default to RTL keyboard layout when device locale is Arabic or Hebrew
On a device configured for Arabic or Hebrew, text fields should surface the Arabic or Hebrew keyboard by default. Verify this on a physical device — simulators do not reliably reproduce input method behavior. Also verify that fields with keyboardType or inputType overrides haven't inadvertently forced a Latin keyboard.
24. Cursor placement and text selection handles are on the correct side for RTL input
In an RTL text field, the cursor starts at the right edge and moves left as the user types. Text selection handles mirror accordingly. This is handled correctly by native UITextField/EditText when the field's layout direction is set properly. Custom text input implementations frequently get this wrong.
25. Search fields and forms accept and correctly display RTL input without reversing characters
This is distinct from item 24. Some text fields render correctly but have preprocessing logic (debounce handlers, input formatters, validation functions) that processes character-by-character in a way that can reverse RTL input. Test end-to-end: type an Arabic or Hebrew string, submit it, verify what the app receives and displays as the result.
Assign to: localization lead
26. App Store / Google Play listing is translated and RTL-appropriate
Store listing copy is frequently treated as an afterthought relative to in-app strings. It shouldn't be — it's the first thing Arabic and Hebrew users see. Verify that the app title, subtitle, description, keyword fields, and screenshot captions are correctly translated and reviewed. Screenshots in particular need to show RTL UI, not LTR screenshots with Arabic text overlaid. See how localizing your App Store listing actually boosts installs for the business case.
27. App name and store metadata do not contain hardcoded LTR punctuation or English phrases mixed into RTL copy
Arabic App Store descriptions that contain English phrases mid-sentence, or that use Latin punctuation (! instead of !, . instead of ، where appropriate), signal to native speakers that the localization wasn't seriously invested in. Check the metadata the same way you'd check in-app strings: with a native speaker or professional reviewer, not just a grammar tool.
Add the following to your .github/pull_request_template.md (or your team's equivalent) as a required section for PRs tagged with an RTL locale milestone:
## RTL Localization Sign-off (required for ar/he/fa/ur releases)
**Layout & Mirroring** (developer)
- [ ] 1. Custom views respect layoutDirection / semanticContentAttribute
- [ ] 2. Navigation flow mirrored
- [ ] 3. Directional icons mirrored
- [ ] 4. Non-directional assets NOT mirrored
- [ ] 5. No hardcoded left/right gravity (Lint RtlHardcoded clean)
- [ ] 6. No hardcoded textAlignment .left/.right in iOS
- [ ] 7. Horizontal ScrollView / carousel direction correct
- [ ] 8. FlatList / RecyclerView horizontal RTL-aware
**Text Rendering** (developer)
- [ ] 9. Correct font — no Latin-only fallback
- [ ] 10. Arabic connected letterforms verified
- [ ] 11. Bidi strings render correctly
- [ ] 12. Line height accommodates diacritics
- [ ] 13. No truncation on translated strings
- [ ] 14. RTL punctuation present in translations
**Formatting** (QA)
- [ ] 15. Numeral system confirmed for target locale
- [ ] 16. Currency uses locale-aware formatter
- [ ] 17. Date/time respects locale calendar
- [ ] 18. Percent/unit symbols on correct side
**String Quality** (developer + localization lead)
- [ ] 19. Placeholder parity verified
- [ ] 20. Arabic plural forms — all 6 CLDR categories present
- [ ] 21. No English fallback strings in RTL UI
- [ ] 22. Hebrew gender agreement reviewed by native speaker
**Input & Keyboard** (QA)
- [ ] 23. RTL keyboard defaults correctly
- [ ] 24. Cursor and selection handles correct
- [ ] 25. Search/form input accepts RTL without reversal
**Distribution** (localization lead)
- [ ] 26. Store listing translated — title, description, screenshots
- [ ] 27. No hardcoded LTR punctuation in store metadata
The checklist maps cleanly to three roles:
If your team doesn't have a dedicated localization lead, the Section 4 and 6 items should be assigned to whoever owns the translation workflow — not left unassigned.
Simulators are sufficient for layout direction checks (items 1–8), text rendering verification (items 9–14), and formatting output (items 15–18). Use them early and often — they're faster to iterate on.
Physical devices configured for Arabic or Hebrew locale are required for keyboard behavior (items 23–25) and any check that involves system input methods. They're also strongly recommended for font rendering verification (item 9), because simulator font fallback behavior has historically differed from device behavior in subtle ways.
Automate what can be automated: placeholder parity, plural form coverage, untranslated string detection. These should run in CI on every merge.
A native speaker or professional reviewer is required for: Hebrew gender agreement (item 22), Arabic punctuation review (item 14), and store metadata (items 26–27). The business cost of getting these wrong — in user trust and store reviews — is significantly higher than the cost of a review.
RTL launch failures tend to be diffuse. Layout breaks because someone assumed an engineer had already audited the custom views. Plural forms are wrong because the translation pipeline wasn't configured for Arabic's six CLDR categories. Store metadata contains Latin punctuation because no one owns that step.
This checklist, combined with the testing infrastructure covered in Localization Testing 101 and the failure mode analysis in 5 Platform-Specific Ways RTL Languages Break Your Mobile App, gives your team a complete, repeatable RTL QA process with explicit ownership at each step.
If your team is scaling RTL support and running into issues at the translation layer specifically — placeholder corruption, Arabic plural errors, or bidi string mangling introduced during AI translation — see how GetTranslated.AI handles format-safe AI translation for RTL languages. The translation layer is where a lot of these problems originate, and it's worth making sure that layer is solving the problem rather than adding to it.