Arabic App Store Screenshots: 4 Typography Tripwires [2026]

Arabic App Store screenshots break in four typography ways that layout mirroring doesn't fix. Arabic needs shaping fonts because the same letter takes four positional forms (initial, medial, final, isolated); Hebrew has no shaping requirement. Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩) and Western Arabic numerals (0123456789) are both valid and carry different signals. The Unicode Bidirectional Algorithm reorders Latin brand names embedded inside Arabic captions [2]. And App Store Connect supports Arabic, Hebrew, and (since March 31, 2026) Urdu as RTL metadata languages [4], but Persian and Pashto are still not on the list.

This is the typography-layer companion to the cultural adaptation pillar, which covers the layout-direction layer (what mirrors, what doesn't, the 9-layout RTL difficulty table). That pillar maps the layout container. This post covers what breaks inside the container after the layout is correct.

TL;DR:

• Arabic requires shaping fonts. Most system stacks ship with Noto Sans Arabic or IBM Plex Sans Arabic; Latin-only fallback fonts produce disconnected glyphs because Arabic letters take initial, medial, final, or isolated forms based on position in the word [1]. Hebrew has no equivalent requirement and renders correctly with most Latin fallback stacks.
• Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩) and Western Arabic numerals (0123456789) are both Unicode codepoints, and App Store Connect accepts both. Saudi Arabia and the UAE increasingly default to Western digits in productivity, banking, and SaaS apps. Cultural, religious, and traditional-category apps lean Eastern.
• A Latin brand name inside an Arabic caption gets reordered by the Unicode Bidirectional Algorithm (UAX #9) [2]. "Try Notion free" written in Arabic puts the Latin "Notion" at a visual position most designers don't predict from a Photoshop preview. Preview-test inside App Store Connect, not in the design tool.
• App Store Connect supports 50 metadata languages as of March 31, 2026, including Arabic, Hebrew, and the newly-added Urdu [4]. Persian (Farsi) and Pashto are not supported. Teams shipping to Iran, Afghanistan, or Tajikistan must choose between Arabic-as-proxy or English-only metadata.
• Urdu requires Nastaliq style (a calligraphic descendant of Arabic with vertical baseline shifts); most system fonts ship Naskh only [7]. Browsers don't currently support automatic Nastaliq fallback [6], so screenshot designers using Photoshop or Figma have to install Noto Nastaliq Urdu manually before previewing the rendered listing.

Table of Contents

• Why does the pillar's RTL coverage miss the typography layer?
• Why does Arabic need shaping fonts and Hebrew doesn't?
• When should you use Eastern vs Western Arabic numerals?
• What does the Unicode Bidi Algorithm do to Latin brand names in Arabic captions?
• Which RTL languages does App Store Connect actually support?
• What's the pre-flight check for Arabic and Hebrew screenshot listings?
• Takeaways

Why does the pillar's RTL coverage miss the typography layer?

The cultural adaptation pillar covers the layout-direction layer: what mirrors (caption alignment, device-frame position, carousel order, directional icons), what doesn't (numbers, logos, photos, video controls, clocks, charts), and the 9-layout RTL difficulty table (which layouts absorb the mirror cleanly and which need parallel design). That work happens at the layout container level: where the elements sit, which way they read, how the composition flows.

The typography layer is downstream of that. The layout can be mirrored correctly, the device frame can sit on the right of the headline, the carousel can read right-to-left in App Store Connect's preview, and the screenshot can still render wrong because the text inside the caption broke at the font-fallback, numeral-choice, bidi-reorder, or unsupported-language level. Those four failures happen after the layout is correct, and most RTL guidance skips them entirely.

The four tripwires below are typography failures, not layout failures. Each one has a specific fix that doesn't change the layout, and each one breaks a specific listing if it isn't checked before the screenshots ship.

Why does Arabic need shaping fonts and Hebrew doesn't?

Arabic is a cursive script. Each letter takes up to four positional forms depending on where it sits in the word: isolated (standalone or after a non-joining letter), initial (start of a word), medial (middle of a word, connecting on both sides), and final (end of a word) [1]. Unicode encodes each Arabic letter as one codepoint, and the rendering software is expected to pick the right form based on context using OpenType features (isol, init, medi, fina). A font that doesn't ship those features renders Arabic as a sequence of disconnected isolated letters that Arabic readers immediately read as broken.

The common failure mode in screenshot design: the designer picks a custom Latin display font for the English brand mark, applies it to the whole screenshot, and the Arabic localized version inherits the same font stack. Latin-only fonts have no Arabic glyphs at all (best case: system fallback substitutes a default Arabic font and the caption renders correctly but with a visible weight or style mismatch against the brand mark) or they have isolated Arabic glyphs only (worst case: the caption renders as separated letters, an obvious typography defect).

The defensive font stack for Arabic screenshot captions:

• System fallback path: SF Arabic on iOS, Noto Sans Arabic on Android, Segoe UI Arabic on Windows. Ships with the OS, supports shaping correctly. Use as the default fallback when no custom Arabic font is available.
• Custom-font path: Noto Sans Arabic (Google Fonts, free, broad weight range) or IBM Plex Sans Arabic (free, designed for the IBM Plex family so it pairs cleanly with IBM Plex Sans for Latin brand marks). Both support shaping correctly.
• What not to do: don't use an Arabic Presentation Forms-B font that pre-encodes isolated/initial/medial/final as separate codepoints. Those exist for legacy compatibility only, not for modern screenshot design.

Hebrew is different. Hebrew letters in printed and screen typography do not join cursively. Each letter has one form, regardless of position in the word, so the rendering software doesn't have to pick a positional variant. Hebrew renders correctly with most Latin font stacks that include Hebrew glyphs, and the system fallback (SF Hebrew on iOS, Noto Sans Hebrew on Android) handles cases where the custom font lacks Hebrew coverage. The typography risk for Hebrew screenshot captions is mostly limited to weight matching against the English brand mark, not glyph shaping.

The practical rule: budget a separate Arabic font decision per screenshot set. The Hebrew font decision usually resolves to "the existing font stack works."

When should you use Eastern vs Western Arabic numerals?

App Store Connect captions in Arabic can use Eastern Arabic numerals (٠ ١ ٢ ٣ ٤ ٥ ٦ ٧ ٨ ٩, the digits Arabic readers in Iran, Egypt, Sudan, and parts of the Gulf historically use), or Western Arabic numerals (0 1 2 3 4 5 6 7 8 9, the digits English uses and that originated in the same Arabic mathematical tradition but moved through Europe). Both are valid Unicode codepoints. Both render correctly in App Store Connect. The choice is editorial, and the convention varies by region and category [8].

Per-region defaults:

• Saudi Arabia and the UAE: Western Arabic numerals are increasingly the modern default in productivity, banking, fintech, e-commerce, and SaaS categories. Eastern numerals are still common in newspapers, government documents, religious content, and street signage. Apps targeting business or tech audiences typically use Western; apps targeting traditional or religious audiences lean Eastern.
• Egypt and the wider Levant: Eastern Arabic numerals remain more common in everyday print and consumer-facing app contexts, though Western digits show up in fintech and ride-share apps. The split is closer to 50/50 than in the Gulf.
• Iran: Persian uses Eastern Arabic numerals with two character substitutions (٤ becomes ۴, ٦ becomes ۶, and a few others). Persian is not an App Store Connect metadata language [3], so this matters for in-app captions and screenshot images rather than App Store metadata text, but it matters for the rendered screenshot if the app supports Persian users.
• Algeria, Libya, Morocco, Tunisia: Predominantly Western Arabic numerals in modern app contexts, despite Arabic being the primary spoken language. Maghreb conventions diverged from Mashreq earlier.

Per-category defaults:

• Banking, fintech, SaaS, productivity, e-commerce: Western Arabic numerals are the safer default across all Arabic-speaking regions. Pairs cleanly with English brand marks. Reads as modern and category-appropriate.
• Cultural, religious, educational (Arabic language teaching), historical: Eastern Arabic numerals signal cultural authenticity and read as native. Some Quran reader apps mix both deliberately.
• Gaming: Most major gaming apps use Western digits in score displays, level indicators, and currency. Eastern digits show up in story text and dialogue when the game is set in a historical or culturally specific context.

The practical rule: pick one numeral system per Arabic screenshot set and stick with it. Don't mix Eastern and Western digits in the same caption layer or in adjacent stats panels; the visual inconsistency reads as a localization defect even to users who can read both. Document the choice alongside the Arabic font choice so future updates stay consistent.

What does the Unicode Bidi Algorithm do to Latin brand names in Arabic captions?

The Unicode Bidirectional Algorithm (UAX #9) is the standard that defines how mixed-direction text gets rendered [2]. It assigns each character an embedding level: 0 for left-to-right base text (English), 1 for right-to-left runs (Arabic, Hebrew), 2 for left-to-right embedded inside RTL (Latin brand names embedded inside an Arabic caption), and so on. The algorithm resolves the levels per paragraph and then reorders the runs into visual order using rule L2.

The case screenshot designers hit constantly: an Arabic caption that includes a Latin brand name. "Try Notion free for 14 days" translated to Arabic, with "Notion" left as Latin because the brand name doesn't translate. The Arabic words are level 1 (right-to-left). The Latin word "Notion" is level 2 (left-to-right, embedded inside the Arabic run). When the rendering engine reorders for display, the Latin "Notion" sits at a position the designer didn't predict from a left-to-right preview.

Numbers behave the same way. A stat panel reading "1,247 users" with "users" translated to Arabic but "1,247" left as Latin digits puts the digits at an unexpected visual position because the digits are level 2 inside a level 1 Arabic run.

What goes wrong in practice:

• Photoshop and Figma render bidi inconsistently across versions. A caption that looks correct in Photoshop 2024 may render differently in Photoshop 2025, and both may differ from how App Store Connect's preview renders it on Apple's servers. The fix is to preview-test inside App Store Connect itself, not in the design tool.
• Punctuation gets pulled toward the wrong side. A trailing exclamation mark or period on an Arabic caption can swap sides depending on whether the rendering engine treats it as a "neutral" character that picks up the surrounding direction. Some captions end up with the punctuation visually before the first Arabic character.
• Phone numbers and URLs inside Arabic captions are particularly fragile. A phone number like "+966 11 234 5678" inside an Arabic caption gets the country code and area code treated as separate runs. The visual order may put the country code in the middle of the number.

The defensive workflow:

1. Write the Arabic caption with the Latin brand names and numbers in their natural source order.
2. Paste the caption into App Store Connect's Arabic localization field and preview the rendered listing in App Store Connect's preview tool (not the design tool).
3. If the visual order looks wrong, add Unicode bidi control characters (LRM, RLM) to force the Latin runs to a specific position. The Unicode standard's Bidi FAQ covers the control characters.
4. Re-test after every text change. The bidi algorithm is sensitive to surrounding context, so changing one word can shift the visual order of others.

The Arabic screenshot caption layer is the most bidi-fragile surface in the entire listing. The captions are short (under 30 characters typical), brand names and numbers are common (most apps have at least one), and the preview gap between design tool and App Store Connect render is wide.

Which RTL languages does App Store Connect actually support?

App Store Connect supports 50 metadata languages as of March 31, 2026 [4]. Three are RTL: Arabic (locale code ar-SA, supported across Saudi Arabia, UAE, Egypt, and the wider GCC and MENA region), Hebrew (he, supported in Israel), and Urdu (ur, added March 31, 2026 alongside ten other South Asian and European languages [4]). The Apple Developer announcement explicitly framed the expansion as targeting India and other markets where these languages have major user bases.

Three RTL languages, three different typography requirements:

• Arabic uses Naskh-style shaping (the standard cursive form with four positional letter forms) [1]. System fallback fonts on iOS, Android, and Windows handle Arabic Naskh correctly. Custom screenshot fonts must include Arabic OpenType features (isol, init, medi, fina) or system fallback kicks in with a visible weight mismatch.
• Hebrew uses non-joining letterforms with no positional shaping. The text-rendering complexity for Hebrew is significantly lower than for Arabic. The font decision usually resolves to "the existing font stack works."
• Urdu uses Nastaliq style, a calligraphic descendant of Arabic with strict vertical baseline shifts. Urdu readers expect Nastaliq. Most system fonts on Windows, Android, and earlier iOS versions ship Naskh only and fall back to Naskh for Urdu text, which Urdu readers read as wrong. The W3C Arabic Layout Requirements working group has an open issue (alreq #276) documenting that neither Gecko, Blink, nor WebKit currently supports automatic Nastaliq fallback selection [6]. The fix is to install Noto Nastaliq Urdu (free from Google Fonts, 1,138 glyphs) manually in the screenshot design tool and confirm it ships embedded in the screenshot image, not as a system-resolved render.

What's missing from App Store Connect: Persian (Farsi) and Pashto are not supported as metadata languages [3]. Both are native RTL languages with substantial user bases (Persian: 110+ million speakers in Iran, Afghanistan, Tajikistan; Pashto: 60+ million speakers in Afghanistan and Pakistan). Apps shipping to Iran, Afghanistan, or Tajikistan have to pick one of three options:

1. English-only metadata, accepting that users see the English listing.
2. Arabic-as-proxy metadata, shipping the Arabic localization to Persian-reading and Pashto-reading users. Most can read Arabic script; the language is foreign, but the script is familiar. Reads as "translated but to the wrong language" rather than "not translated at all."
3. In-app localization only, with English App Store metadata but full Persian or Pashto support inside the app. Common for apps where most installs come from referrals or in-app sharing rather than App Store search.

The decision typically depends on whether the app's discovery channel is App Store search (option 1 or 2 needed) or word-of-mouth referrals (option 3 acceptable). For RTL-language teams, the lack of Persian and Pashto support in App Store Connect is a known constraint to plan around, not a bug to wait out.

For the multi-market priority decision, the three supported RTL languages (Arabic, Hebrew, Urdu) cover 600 million+ App Store users between them. The two unsupported languages cover another 170 million who see whatever fallback the team picks.

What's the pre-flight check for Arabic and Hebrew screenshot listings?

A practical checklist for the typography layer, applied to every Arabic or Hebrew screenshot set before upload:

Font check:

• Does the Arabic caption font include OpenType shaping features (isol, init, medi, fina)? Render the caption in the design tool and zoom in: letters should connect on the inside of words and stand alone at word boundaries. If letters stay separated mid-word, the font lacks shaping and needs to be swapped or system fallback needs to take over.
• Does the Hebrew caption font include Hebrew glyphs at the same weight as the English brand mark? Render side by side: weight mismatch between the brand mark and the Hebrew caption is a visible defect.
• For Urdu listings: is Noto Nastaliq Urdu installed in the design tool and embedded in the screenshot image? Confirm the rendered text shows Nastaliq style (curved, vertical baseline shifts, calligraphic) and not Naskh fallback (horizontal baseline, geometric).

Numeral check:

• Is the numeral system consistent across the screenshot set? Eastern Arabic numerals (٠١٢٣) or Western Arabic numerals (0123), not both. Stats panels, prices, dates, and percentages all use the same system.
• Are dates and currency formatted to the target market convention? "1,247 ريال" or "ر.س 1,247" in Saudi Arabia, ₪1,247 in Israel, etc. The Hebrew shekel symbol renders differently across font stacks; verify the rendered glyph matches what users expect.

Bidi check:

• Are Latin brand names and numbers embedded inside Arabic or Hebrew captions previewed in App Store Connect's preview, not in the design tool? Photoshop and Figma can render the same caption differently from how the App Store renders it.
• Is the trailing punctuation on the correct side of the caption? Period, comma, exclamation, question mark all behave as "neutral" characters that pick up the surrounding direction; the visual position can swap when the surrounding text changes.
• For captions that include phone numbers or URLs: does the rendered visual order match what a native reader expects to see? Country code and area code can split apart in unexpected ways.

Language coverage check:

• For Persian or Pashto target markets: has the team explicitly chosen one of the three fallback options (English, Arabic-as-proxy, in-app only)? The default of "no Persian metadata" should be a deliberate choice, not a missed decision.
• For Urdu listings: has the screenshot design pass been done in the Nastaliq style, not Naskh? Urdu users reading a Naskh-rendered listing read it as a sloppy port of the Arabic listing, not as a localized Urdu listing.

The check is fast (under 10 minutes per screenshot set) and catches most of the failures that ship to production undetected. The cost of skipping it is a listing that reads as broken to native users, which signals "not maintained for this market" louder than no localization at all.

Takeaways

Layout-level RTL coverage gets a screenshot from "obviously English" to "structurally Arabic." The typography layer gets it the rest of the way to "actually localized." The four tripwires (font shaping, numeral choice, bidi reordering, language coverage gaps) live downstream of the layout decisions and have to be checked separately. Skipping them produces screenshots that pass the layout-mirror eyeball test and fail the native-reader eyeball test.

Three RTL languages get full App Store Connect metadata support: Arabic, Hebrew, and Urdu (added March 31, 2026 [4]). Each has different typography requirements. Arabic needs shaping fonts; Hebrew renders with most stacks; Urdu needs Nastaliq, which most system fonts don't ship. Persian and Pashto remain unsupported as metadata languages and require an explicit fallback decision (English, Arabic-as-proxy, or in-app only).

For the multi-language workflow, the localization global growth guide covers the broader decision of which markets to prioritize. The cultural adaptation pillar covers the layout-direction and color-meaning layers. This post is the typography layer that sits between them. The work compounds: layout decisions enable typography work, typography decisions enable a localized listing that actually converts.