Arabic and English apps: what bilingual (RTL) support involves

Why Arabic changes the scope

Adding a language like French mostly means swapping words. Adding Arabic changes the direction of the whole interface. Menus, back buttons, progress bars, lists and text alignment all move to the other side, and some things deliberately do not. If the app is designed in English first and Arabic is added later, every screen gets touched twice.

That is why I ask at the start whether Arabic is in version one. If it is, the design, the code and the content model are built for two directions from day one, which costs far less than retrofitting it.

Layout mirroring: what flips and what stays

Flutter supports this well. By default a Flutter app only includes US English, so the app adds the flutter_localizations package and lists Arabic and English as supported locales. The localization delegates then set the default text direction, and the Directionality widget passes it down to every screen. Layouts written with direction-aware values, such as EdgeInsetsDirectional with start and end instead of left and right, mirror without separate Arabic screens.

Android's own guidance follows the same idea: declare RTL support and use start and end rather than left and right. Apple's Human Interface Guidelines are useful for the judgement calls, because not everything should flip.

Fonts, numerals and dates

Pick a font family that has proper Arabic glyphs, and check it in both weights you use. Apple notes that Arabic can look small next to Latin text and suggests increasing the RTL font size by about 2 points when the two sit together. I check headings, buttons and form labels in Arabic before signing off a design, because Arabic words are often a different length from the English.

Numbers need a decision. Apple points out that Arabic text might use either Western or Eastern Arabic numerals, and the choice varies by country and region. Most apps can rely on the system's number formatting. In Flutter, the localization tools use the intl package's NumberFormat and DateFormat to format numbers and dates for the active locale. One technical trap: Android warns that formatting numbers in some Arabic locales produces non-ASCII digits, which break things like database queries, so values sent to a server should be formatted in a fixed locale and only displayed in the user's.

Mixed text is the other trap. An English address or product name inside an Arabic sentence can render in the wrong order unless the app marks its direction. Android's BidiFormatter exists for exactly this, and the same care applies in Flutter.

Arabic listings on the App Store and Google Play

Both stores let you publish an Arabic listing alongside English. In App Store Connect, Arabic is one of the supported localizations; you add it as a language and enter a localized description, keywords, app name and privacy policy URL. Screenshots default to the primary language unless you upload Arabic ones. In Google Play Console, you add translations under Manage translations for the title, short description and full description, and you can add localized screenshots and graphics.

Play Console offers free machine translation into Arabic, and Google states plainly that these translations are not reviewed by humans. For a business listing in the UAE, I recommend having a fluent speaker write or review the Arabic text and taking screenshots of the app running in Arabic.

Managing content in two languages

Interface text (buttons, labels, error messages) lives in translation files that ship with the app. In Flutter these are ARB files, one per language, with each message under a key. That part is straightforward once every string goes through the file instead of being typed into the code.

Content you change after launch is different: menus, services, offers, notifications, help articles. If you edit it from an admin dashboard, each item needs an Arabic and an English field, and someone has to decide what happens when only one is filled in. Push notifications and emails need both versions too.

• Will users switch language inside the app, or follow the phone's language? Android 13 and later also lets users set a language per app.
• Who writes and reviews the Arabic copy, and by when?
• Which content is edited after launch, and does the admin show both language fields?
• Which notifications, emails and receipts go out, and in which language?
• Which screens hold mixed Arabic and English text, such as names and addresses?
• Who tests the Arabic build, ideally a native reader?

Testing in both directions

Every screen gets checked twice: once in English and once in Arabic on a real device. Android has a developer option called Force RTL layout direction that shows an English build mirrored, which catches layout bugs before translations arrive. After that, a native reader should go through the real Arabic build, because only a person who reads Arabic will notice text that is cut off, misaligned or worded badly. I include both languages in the device testing and in the store screenshots.

Which package fits a bilingual app

All my packages are built in Flutter, which handles Arabic and English from one codebase. Launch ($999, up to 10 screens) suits a bilingual app whose text is fixed in the translation files. Growth ($1,699, up to 25 screens) adds a Node.js backend, a PostgreSQL database and admin tools, which is where two-language content fields belong. Scale ($2,500, up to 50 screens) adds a full admin dashboard, integrations and push notifications. I write the language requirements into the scope before work starts, including who supplies the Arabic copy, so nothing about the second language is left to assumption.