Flutter vs React Native for Arabic apps: UAE and Saudi 2026

What changes between Dubai and Riyadh is less the framework than the market around it:

In React Native, layout direction belongs to the whole app. The I18nManager documentation says allowRTL and forceRTL take effect on the next application start and describes forceRTL as meant for development and testing. Expo's localisation guide adds that RTL is on by default and follows I18nManager, that on iOS the phone's language must be in the app's supported locales, and that dynamic changes need Updates.reloadAsync() and do not work in Expo Go.

So an app that follows the phone's language is easy. An app with its own العربية / English toggle needs a designed moment: one line saying the app will reopen in Arabic, then a reload that returns users where they were.

Once direction is set, the root view's direction comes from the locale, and start, end, marginStart and paddingEnd swap sides in RTL. Anything written with left and right stays put.

Flutter treats direction as part of the widget tree. Its internationalisation guide says GlobalWidgetsLocalizations.delegate defines the default text direction, and Directionality resolves EdgeInsetsDirectional into left or right padding. Change the app's locale and the tree rebuilds in the new direction, with no restart.

One fresh detail: in Flutter 3.47 (12 August 2026), Material and Cupertino moved into the standalone material_ui and cupertino_ui packages, and the old imports are scheduled for deprecation. Start new Arabic projects on the new packages.

Fonts and shaping

React Native renders <Text> through Android's TextView and iOS's UITextView, so each operating system joins and shapes the Arabic, and results can differ between an old Android phone and a new iPhone. Flutter lays text out in its own engine, shipped inside the app, so a screen looks the same everywhere once you bundle the Arabic font.

Either way, give Arabic its own type tokens: a screen-ready face, more line height, zero letter spacing. My RTL design guide for Arabic apps covers typefaces and licences. For amounts in tables, use tabular figures: fontVariant: ['tabular-nums'] or FontFeature.tabularFigures().

Digits: decide, then pin

Gulf markets disagree on digits. In my Node.js test (CLDR 48), ar-AE and plain ar format 1234567.89 as 1,234,567.89, while ar-SA gives ١٬٢٣٤٬٥٦٧٫٨٩. Neither framework follows that reliably:

Hermes uses platform facilities instead of bundling ICU, and on iOS it lacks numberingSystem in date formatting. In Flutter, a Saudi app that wants Arabic-Indic digits must ask for them. In both, write one formatting function, test it on real phones, and convert typed Arabic-Indic digits to 0 to 9 before validation.

Phone numbers and mixed text

A mobile number such as +966 50 123 4567 must stay left to right inside an Arabic screen. In Flutter, set textDirection: TextDirection.ltr on the Text or TextField; the intl package's BidiFormatter wraps strings for plain-text contexts. In React Native, the writingDirection text style works on iOS only, so wrap the number in Unicode isolates (U+2066 and U+2069) or give it its own left-to-right view, and check Android by eye.

In Arabic, the back arrow points right and the swipe back starts from the right edge. React Navigation's direction prop defaults to rtl when I18nManager reports RTL, and its docs warn that the layout may be wrong if the two disagree. In Flutter, Icons.arrow_back is defined with matchTextDirection: true, so it mirrors on its own, and horizontal scroll views follow the reading direction.

Neither flips custom icons, animations, anything drawn with absolute coordinates or hand-built swipe rows. Keep a list of directional icons in the design system, each marked flip or keep.

Dates need a decision too. Flutter's showDatePicker takes a calendarDelegate, Gregorian by default, which its docs say a custom one can replace for Hijri. React Native's community date picker wraps the native pickers and, on Android, follows the system locale. If Saudi users pick Hijri dates, prototype that first.

UAE PASS publishes two official mobile SDKs, an iOS framework added as a local CocoaPod and an Android .aar library, covering app-to-app login, a web view fallback, profile data and document signing. There is no official Flutter or React Native SDK.

Community packages fill the gap. The React Native module on GitHub is MIT licensed, says it is not affiliated with UAE PASS, had 16 stars and released 1.1.2 on 11 August 2026; its example Expo config sets newArchEnabled to false, yet React Native 0.82 and later run only on the New Architecture. A pub.dev search for "uaepass" returned ten Flutter packages, versions 0.0.3 to 1.1.1, none published by UAE PASS.

In both stacks, wrap the official native SDKs in a thin bridge your team owns: a Turbo Native Module or Expo module in React Native, a platform channel (ideally generated with Pigeon) in Flutter. Register your own URI scheme, as UAE PASS requires, and test against its staging app. My UAE PASS sign-in guide covers the screens.

Nafath is gentler on the framework. The public flow is server-side: the user enters a National ID or Iqama number, your server requests a check, your app shows a two-digit number, and the user approves in the Nafath app within 60 seconds. The app keeps the number on screen and rechecks the status when the user returns, with AppState in React Native or AppLifecycleListener in Flutter. I found no public documentation for a Nafath app-to-app deep link; Signit notes that the Elm route has separate credentials for app and web channels, so ask your provider. The Nafath login guide has the states.

Here the frameworks really differ, because each provider chooses what to support. What I found on npm, pub.dev and the providers' docs on 5 October 2026:

Two cautions apply in both. Tabby's no-SDK guide says the web view must reach the camera and photo gallery, because customers may upload ID, and that the client is never proof of payment: read the status from your backend and save the payment_id before the customer leaves the app. And version numbers are a snapshot.

For Saudi checkouts, mada and Apple Pay reach your app through the gateway's SDK, not the framework. An official package from your acquirer settles more than any benchmark.

Flutter's FAQ says it is designed for smooth 60 and 120 frames per second. Its Impeller renderer is the only option on iOS and the default on Android API 29 and later, with an OpenGL fallback on older phones; it precompiles shaders to avoid runtime stutter. On size, the FAQ says only that the engine adds a few megabytes compressed; the last measured example, from Flutter 1.17, was a 5.4 MB compressed iOS download.

React Native runs only on its New Architecture since 0.82 (October 2025), and Hermes V1 has been the default engine since 0.84 (February 2026). Its docs say Hermes improves start-up time, memory use and app size compared with JavaScriptCore, but give no figures.

Neither project publishes a current like-for-like comparison. Measure your own spike build with flutter build appbundle --analyze-size, and the Play Console and App Store Connect size reports for both.

Stack Overflow's survey puts the two frameworks almost level among professional developers:

In 2024, 9.4% of the 35,100 professional developers who answered used Flutter and 9.0% React Native. In 2023 it was 9.2% and 9.1% (52,046 answers), and in 2022 React Native led, 13.6% to 12.6% (41,060 answers). The 2025 survey dropped the question, and 2026 results were not out when I checked. Answer options change yearly, so compare within a year.

The bigger gap is the language. In 2025, 68.8% of professional respondents used JavaScript, 48.8% TypeScript and 6.1% Dart; 46.9% used React and 21.5% Next.js. A React Native team can borrow from a much larger web pool; Flutter hiring draws on a smaller one. I found no public Gulf-specific data: the job boards I tried refused automated reads, so treat local claims with suspicion.

What matters more than the pool is native skill: both frameworks will need someone who reads Swift and Kotlin, for UAE PASS, payments or the camera. Ask every candidate team who writes the bridges.

Most Gulf products are an app plus a website, portal or admin panel. React Native shares the language, React itself and the libraries for validation, API calls and translations with a Next.js web app. Expo Router's docs add one navigation structure across Android, iOS and web, with static rendering for search.

Flutter can target the web, but its FAQ says it is not suitable for text-rich static websites, because the output does not suit search engines. A Flutter app usually sits beside a separate Next.js site, sharing the API contract (both clients generated from one OpenAPI file) and one source of Arabic and English strings. My comparison of Framer, Webflow and Next.js covers the website side, and my team builds the web front end either way.

For an online store, decide first whether you need an app at all; my guide to Salla, Zid or a custom store helps.

1. List every SDK the app needs: identity, payments, maps, analytics, chat. Find each one's official packages on npm and pub.dev, with publisher and last release date.
2. Write down the Arabic rules: digit style per market, whether the app follows the phone's language or has its own toggle, and whether Hijri dates appear.
3. Build one spike screen, the checkout above, in the candidate framework or both.
4. Test it in Arabic on an older Android phone and a recent iPhone, with the phone in English and the app in Arabic, typing Arabic-Indic digits into every field.
5. Integrate the hardest SDK in staging, usually UAE PASS against its staging app, or the BNPL provider's test mode.
6. Name who owns the native bridges and the upgrades every few months.
7. Record the decision in the scope with the reasons, so nobody reopens it in sprint four.

• Choosing from benchmark blog posts instead of SDK support and team skills.
• Shipping forceRTL in production, which the React Native docs reserve for testing.
• Writing left and right in styles instead of start and end.
• Trusting locale defaults for digits, then finding two digit styles on one screen.
• Installing an unofficial identity package without reading its code and release history.
• Treating a payment redirect as proof of payment.
• Building the marketing website in Flutter web and expecting it to rank.

Is Flutter or React Native better for Arabic apps?

Neither is better at Arabic itself; both handle right-to-left layout, Arabic text and mirrored navigation when the team plans for it. Flutter switches direction live and draws text the same on every phone; React Native uses each platform's text views and sets direction at launch. Choose on SDK support, team language and web stack.

Does React Native support RTL properly?

Yes. I18nManager switches the whole layout to right to left, layout props such as marginStart and end mirror automatically, and React Navigation reads the same setting. The catch is timing: direction changes apply on the next app start, so an in-app language toggle needs a reload, which Expo documents with Updates.reloadAsync().

Can a Flutter app switch between Arabic and English without restarting?

Yes. Flutter takes text direction from the app's locale through its localisation delegates, so changing the locale rebuilds the widget tree right to left immediately. Material icons such as the back arrow mirror automatically. Custom icons, custom painters and digits still need your own rules.

Can I use UAE PASS in a Flutter or React Native app?

Yes, in both, but not with an official cross-platform SDK. UAE PASS publishes native iOS and Android SDKs, and every Flutter and React Native package I found is unofficial. The safest route is a thin native bridge your team owns, tested against the UAE PASS staging app before the onboarding assessment.

Do Tabby and Tamara work with Flutter and React Native?

Yes. Tabby publishes official SDKs for iOS, Android, Flutter and React Native, and documents a web view route without any SDK. Tamara lists Android, iOS, Flutter and React Native SDKs. Either way, confirm payment status from your backend, not the app screen.

Which framework is best for apps in Saudi Arabia?

For most Saudi apps, either. Nafath sign-in is server-side, and Moyasar, which supports mada, Apple Pay and STC Pay, publishes official SDKs for both. The Saudi-specific decision is digits: ar-SA defaults to Arabic-Indic, Flutter's intl falls back to Western, and React Native follows the phone, so choose and pin a rule.

Is it easier to hire React Native or Flutter developers in Dubai and Riyadh?

Public Gulf data is thin. Globally, Stack Overflow's 2024 survey found almost equal use among professionals (9.4% Flutter, 9.0% React Native), but far more developers know JavaScript than Dart, so React Native can draw on web developers. Check native Swift and Kotlin skills either way.

Should we build native Swift and Kotlin apps instead?

Consider it if the app leans on platform features such as UAE PASS signing, wallets, widgets or watch apps, and you can fund two codebases. For most Gulf startups, one cross-platform codebase with a small native layer for identity and payments is the better use of budget.

How much does a Flutter or React Native app cost in Dubai or Riyadh?

The framework moves the price less than the scope does: screens, user roles, Arabic and English, UAE PASS or Nafath, payments and an admin panel. My cost guides give sourced market rates for Dubai in dirhams and Saudi Arabia in riyals. For my own projects, scope comes first, then one fixed quote.

Do not pick the framework first. Settle the Arabic rules, sign-in and payment providers, check which official SDKs exist, then build one Arabic spike screen. With a React or Next.js web app, or N-Genius or Checkout.com, lean React Native. For custom-drawn screens identical on every phone, or a team that writes Dart, lean Flutter. Otherwise, choose what your team can maintain for years.

My team builds in both, remotely from Dhaka, inside most of the Gulf working day; read how I work and my mobile app design approach. Planning an Arabic and English app? Start with a free 30 minute intro call about app design and development for Dubai or for Riyadh, then a written scope and one fixed quote.

I read every source on 5 October 2026, unless a date says otherwise; package versions come from the npm and pub.dev registries that day. Digit formats come from my Node.js 24.14.1 test (ICU 78.2, CLDR 48) and the Dart intl source; I built no test apps for this post. No currency conversion was needed. Data is thin on app size, Gulf hiring and Nafath app-to-app sign-in.

• React Native docs, version 0.87: reactnative.dev, reactnative.dev, reactnative.dev, reactnative.dev, reactnative.dev, reactnative.dev, reactnative.dev
• React Native blog, 0.82 (8 October 2025), 0.84 (11 February 2026), 0.87 (11 August 2026): reactnative.dev, reactnative.dev, reactnative.dev
• Meta, Hermes Intl APIs: github.com
• Expo, localisation guide (7 September 2026), Expo Router (16 September 2026), Expo Modules: docs.expo.dev, docs.expo.dev, docs.expo.dev
• React Navigation 7, NavigationContainer: reactnavigation.org
• React Native community date picker README: github.com
• Flutter docs, updated 21 to 29 September 2026: docs.flutter.dev, docs.flutter.dev, docs.flutter.dev, docs.flutter.dev, docs.flutter.dev, docs.flutter.dev
• Flutter docs, Impeller (21 August 2026), app size (5 May 2026), what's new (13 August 2026): docs.flutter.dev, docs.flutter.dev, docs.flutter.dev
• Flutter API reference: api.flutter.dev, api.flutter.dev, api.flutter.dev, api.flutter.dev, api.flutter.dev, api.flutter.dev, api.flutter.dev, api.flutter.dev
• Dart intl package, number data (CLDR 48), locale fallback and BidiFormatter: github.com, github.com, pub.dev
• UAE PASS developer docs, mobile requirements, SDK guide and sample apps: docs.uaepass.ae, docs.uaepass.ae, docs.uaepass.ae
• react-native-uaepass on GitHub (unofficial) and the pub.dev search for "uaepass": github.com, pub.dev
• SDAIA, Nafath Platform User Guide, April 2025, and Signit Help Center, custom Nafath provider: sdaia.gov.sa, help.signit.sa
• Gulf News, Google Pay arrives in the UAE beside Apple Pay and Samsung Pay, 14 November 2018: gulfnews.com
• Tabby, mobile SDKs and integration without SDK: docs.tabby.ai, docs.tabby.ai, pub.dev
• Tamara, mobile SDKs and React Native SDK (updated 30 March 2026): docs.tamara.co, docs.tamara.co, pub.dev
• Moyasar, React Native and Flutter SDK docs: docs.moyasar.com, docs.moyasar.com, pub.dev
• Network International, N-Genius mobile SDKs and React Native wrapper: docs.ngenius-payments.com, github.com
• Checkout.com, Flow for mobile, and its React Native package: checkout.com, npmjs.com
• Stack Overflow Developer Survey 2022 to 2025, and its post of 30 September 2026: survey.stackoverflow.co, survey.stackoverflow.co, survey.stackoverflow.co, survey.stackoverflow.co, stackoverflow.blog
• Node.js, Intl documentation, for the digit test: nodejs.org