How does Flutter actually handle Arabic and right to left?

Through the layout, not through the strings. The localisation delegates supply the reading direction, Directionality sets it for a subtree, and EdgeInsetsDirectional takes start and end instead of left and right, so a widget written that way mirrors itself. The catch is the inverse: a widget written with hardcoded left and right padding does not mirror at all, and no translation fixes it. That is why the directional decision belongs in week one rather than in a later phase called Arabic.

What does Flutter buy that React Native does not?

One rendered result instead of two. Flutter draws every pixel through its own engine, so there is no per-platform layout drift to chase and, more usefully here, a mirrored reading is the same tree told to read the other way. React Native renders the platform’s own components, which is the stronger answer when a React team already exists and the interface is conventional. Which of those matters more is a decision that follows your integration list, and the hub page makes it.

Should we hire a Flutter developer or commission the build?

Commission it if this is one product; hire if it is the first of several. A single developer is the smaller line and the larger risk, because one product needs design, a build pipeline, store accounts and someone who can still read the code in year two, and one person is all four points of failure at once. Hiring makes sense when there is a pipeline of work to keep that person busy and someone in the building who can assess their output. We will say which applies to you, including when it is hiring.

Can Flutter reach UAE PASS and the payment sheets?

Yes, through platform channels, and the work is native on both sides of the channel. A method channel from Dart routes to a Swift handler on iOS and a Kotlin handler on Android, which is how a native payment SDK or an identity app-switch is reached from one codebase. On Android the app-switch also needs the manifest to declare what it wants to see, and the approval to use national identity sign-in sits outside the build entirely. The Dubai page sets out what those approvals wait on.

Can an existing app be converted to Flutter?

It is a rebuild of the interface and a reuse of everything under it. The API layer, the data model and the business rules survive because they were never platform code; the screens do not, because converting an interface means writing it again in a different toolkit. Flutter can also be added to an existing native app screen by screen, which is the sensible route when one flow needs rebuilding and the rest does not. Whether either is worth doing depends on why the current app is a problem, and that is a shorter conversation than it sounds.

Is Flutter a safe choice for a product we will run for years?

Yes, with one condition that has nothing to do with Flutter. The framework is actively developed, widely used in production and reaches both stores from one codebase, so the platform risk is ordinary. The real long-term risk on any framework is a codebase only one person understood, which is the more common way an app in this market becomes unmaintainable. Documentation, a written architecture and accounts in your own name matter more to year three than the framework name does, and the pillar sets out what year two costs.

When is Flutter the wrong choice?

Three cases, and we will name them before a proposal rather than after one. A graphics-heavy product where the rendering is the product itself is better native. A platform SDK with no maintained plugin, on a hard date, is a risk you would be carrying rather than us. And a team that already writes React every day will maintain a React Native codebase more happily than a Dart one, which matters more than any benchmark. Whether an app is the right shape at all is a question before this one, and it is answered here.

Flutter app development · UAE

Flutter apps with Arabic and English built in.

One Dart codebase for both stores is the part everyone sells. The part that matters here is direction, because a product in two scripts is where a borrowed layout gives up.

Settle the direction before the first screen

What Flutter app development is

What Flutter app development gives you.

Flutter renders every pixel through its own engine rather than borrowing the platform’s widgets. Direction becomes something the layout is told, instead of something each platform decides for it.

One engine draws every screen.

Impeller draws the interface directly, so the app does not inherit two sets of platform layout quirks. The screen you approved is the screen that ships, on both stores and across a wide manufacturer tail.

One layout, mirrored for Arabic.

Directionality sets the reading direction and EdgeInsetsDirectional takes start and end rather than left and right. An Arabic screen is the same screen, mirrored by the framework, not a second design somebody maintains.

Native code where it is needed.

Identity and payment still reach native code, through a channel into Swift and Kotlin. One language does not mean one runtime, and the honest version of a Flutter pitch says so before the build rather than after.

The scope

What a Flutter build gives you.

Six outputs from a Flutter engagement. Four come from the rendering model, one from the language, and one from the seam it cannot render its way past.

Screens Flutter draws itself.

Every element is a widget in one tree, so a brand interface is composed rather than negotiated with two platform toolkits

Output

the design you signed off, rendered rather than approximated

WidgetsOne tree

Changes you can see instantly.

A change appears in the running app in under a second, so a screen is reviewed in the round it was drawn rather than the round after

Output

more passes inside the same fortnight, including the Arabic one

Hot reloadMore rounds

Dart, with a route to native code.

A method channel invoking a native payment SDK on both platforms, handled in Swift and in Kotlin

Output

one language, and a written list of what still needs two

DartChannels

The same result on both phones.

The same widget tree drawn by the same engine, so there is no per-platform layout drift to chase and no second visual QA pass

Output

one interface to review rather than two

Own engineNo drift

Android and iPhone styles included.

Platform conventions available where a user expects them, without maintaining two design systems to get them

Output

an app that reads as native where that matters and as yours everywhere else

MaterialCupertino

The same code on the web.

The build extended to a browser only where a user genuinely arrives there, such as a partner portal nobody will install

Output

a surface added on evidence rather than on principle

WebOn evidence

Three ways an Arabic screen gets built

Three ways to ship in Arabic.

Every approach produces a correct first Arabic screen. They diverge at the tenth, and again the first time somebody adds a feature.

	Translated stringsOne layout, the text swapped	A second mirrored designDrawn again, maintained separately	One directional layoutBuilt once, mirrored by the framework
The first Arabic screen	Quick, and wrong: hardcoded left and right padding does not mirror.	A full second design pass, and it does look right.	The same screen with direction supplied, rather than a screen drawn twice.
The tenth	Ten screens of alignment faults nobody put in the plan.	Ten more artboards, and two files that have to stay in step.	No extra layout work at all, because the widgets already read direction.
A new feature	Ships in English, breaks in Arabic, and a user finds it first.	Built twice, and the Arabic one lags by a release or two.	Built once and correct in both, because there is only one layout.
When a designer leaves	Nothing to hand over, because nothing was ever decided.	Two design files, and only one of them was being maintained.	One file and one rule: start and end, never left and right.

When Flutter is the right call.

When the product genuinely ships in both scripts, which in this market is most consumer work and a good deal of the rest. Where English is the whole audience, this column is worth very little and the framework should be chosen on the integration list instead, which is the hub’s argument rather than this page’s. The type half of the same problem, an Arabic companion face that actually exists, is settled at identity.

What we find on Flutter work here

Why Flutter pays off here.

Webzenia has worked with Gulf clients since 2018. Four things about Flutter in a bilingual market, including the one a third of this market is actually searching for.

01of 04
Consistency across scriptsNot across platforms
One engine keeps Arabic and English identical.
One engine draws both, so a mirrored layout is the same tree told to read the other way. A Deira family trading house on a mainland DET licence, serving an Arabic counter trade and an English corporate one, is buying that second consistency rather than the first.
Our methodThe directional decision taken in the same week as the device floor.
02of 04
A retrofit is every screenIt is every screen
Fixed left and right spacing will not mirror.
Flutter mirrors a layout written with start and end. One written with left and right stays where it was put, so adding Arabic later means revisiting the padding, the alignment and the icon direction on every screen rather than editing a file of strings.
Our methodDirectional insets from the first widget, checked in review rather than at the end.
03of 04
The seam is still nativeOne language, two runtimes
Payments and sign-in still need native code.
A Jumeirah beauty brand on a mainland DET licence taking instalments and a verified sign-in is reaching two native SDKs from Dart, not avoiding them. The rail list decides that scope, and it is written before the framework is defended.
Our methodEvery channel and its native handler named in the scope document.
04of 04
Hire, or commissionA third of this search
Much of the demand for this term is job seekers.
That makes the real decision hire against commission, and it turns on year two rather than year one. A Dubai Internet City software firm on a free zone licence that inherited a Flutter portal from a departed contractor has already run the experiment.
Our methodThe maintenance question answered before the build question.

What the engagement covers

Inside a Flutter build.

The engagement in six stages. The direction is settled in the first, because every stage after it is priced by that answer.

Scope and the Arabic decision.

The feature list, the device floor, and whether the product ships in one script or two. That last answer changes the design system, the review cycle and the store listing, so it is settled first rather than deferred.

Scope
Direction

Designing both directions at once.

One set of screens with start and end alignment rather than left and right, reviewed in both directions on the same artboards. The Arabic version is a reading of the design, not a second copy of it.

One file
Both directions

Payment sheets and sign-in.

Your APIs, the payment sheet and the identity app-switch, each reached through a named channel with a native handler on both sides. Nothing is dropped to keep the Dart codebase tidy.

Channels
Native handlers

Testing in both languages on real phones.

The build run in English and in Arabic on physical devices from both platforms, because a mirrored layout and a longer string are the two things a simulator is most confident and most wrong about.

Both scripts
Real devices

Store listings in both languages.

Listing text, release notes and screenshots produced in both languages, with the Arabic screenshots taken from the mirrored build rather than the English one with translated captions bolted on.

Two languages
Real screenshots

Handover, with the Arabic rule written.

Code, documentation and the one rule that keeps the product bilingual: directional insets, never hardcoded sides. A team that inherits the rule keeps the property; a team that inherits only the code loses it in a sprint.

Documented
One rule

Our stack

Built with Flutter and Dart.

The framework, the language, the design file, the crash log and the build service. Select one to see what it does for the second script.

Flutter

Why Flutter

Flutter ships its own rendering engine, its own widget set and its own directional primitives, so reading direction is a property of the layout rather than a behaviour each platform supplies differently.

How we excel

We use the directional widgets from the first screen rather than the first bug report, because the framework mirrors a layout that asked to be mirrored and leaves one that did not exactly where it was put.

Mirrors a layoutOne rendered resultDraws

FlutterOwn engine

React NativePlatform views

Two native buildsTwice

A web view shellBrowser

How the build runs

From the Arabic decision to both stores.

A bilingual product does not break at launch. It breaks in the third release after it, when a feature ships in one script and waits in the other.

01Weeks 1 to 2Scoped

Deciding the Arabic approach.

We settle whether the product ships in one script or two, and design against that answer rather than around it. In the same fortnight the rails are listed, because identity and payment reach native code through channels regardless of the framework and that is the part a Flutter quote most often leaves out.

Directiondecided, not deferred
Designone file, both readings
Channelsnamed before the build

02Weeks 3 to 9Built

Building one screen set.

The interface is built with directional insets from the first widget, so a mirrored reading needs no second layout. The channels are written with a native handler on each side, and hot reload is spent on reviewing screens in both directions while changing them is still an afternoon rather than a sprint.

Layoutdirectional from widget one
Seamnative on both sides
Reviewboth readings, every screen

03Month 3 onwardRunning

Keeping both languages in step.

Every release ships both readings or it does not ship, and crash reports are read with the active locale attached so a fault that only appears in one direction is visible rather than averaged away. A bilingual product decays quietly: the English side keeps moving, the Arabic side stops being checked, and eighteen months later there are two products with one budget.

Releasesboth readings or neither
Crashestagged with the locale
Listingsupdated in both languages

Reported with the locale attached, so a fault in one direction is never an average.

Both readings, in writing

DirectionalBoth scriptsOne tree

Our commitment

Our written commitments.

A bilingual Flutter product fails in the second script, months after launch. These four are written into the scope because that is where it happens.

Arabic layout from the first screen.
Start and end rather than left and right, everywhere, from the first widget. Retrofitting direction into a laid-out interface is a second pass over every screen, and it is the single most avoidable cost on a bilingual build.
A native speaker reads the Arabic.
Before it ships, not after a customer writes in. A layout can mirror correctly and still read badly, and no amount of framework support substitutes for a person who reads the language checking the screen.
Every feature ships in both languages.
Release parity is a rule in the scope rather than an intention. The alternative is a product whose second language slowly stops matching the first, which is how a bilingual app becomes an English app with an Arabic archive.
We say when Flutter is wrong for you.
A graphics-heavy product, a platform SDK with no maintained plugin and a hard date, or a team that already writes React every day. In those cases we say so, and the honest recommendation costs us the build rather than you the year.

Common questions

Flutter apps, answered.

Through the layout, not through the strings. The localisation delegates supply the reading direction, Directionality sets it for a subtree, and EdgeInsetsDirectional takes start and end instead of left and right, so a widget written that way mirrors itself. The catch is the inverse: a widget written with hardcoded left and right padding does not mirror at all, and no translation fixes it. That is why the directional decision belongs in week one rather than in a later phase called Arabic.
FAQ · 01
One rendered result instead of two. Flutter draws every pixel through its own engine, so there is no per-platform layout drift to chase and, more usefully here, a mirrored reading is the same tree told to read the other way. React Native renders the platform’s own components, which is the stronger answer when a React team already exists and the interface is conventional. Which of those matters more is a decision that follows your integration list, and the hub page makes it.
FAQ · 02
Commission it if this is one product; hire if it is the first of several. A single developer is the smaller line and the larger risk, because one product needs design, a build pipeline, store accounts and someone who can still read the code in year two, and one person is all four points of failure at once. Hiring makes sense when there is a pipeline of work to keep that person busy and someone in the building who can assess their output. We will say which applies to you, including when it is hiring.
FAQ · 03
Yes, through platform channels, and the work is native on both sides of the channel. A method channel from Dart routes to a Swift handler on iOS and a Kotlin handler on Android, which is how a native payment SDK or an identity app-switch is reached from one codebase. On Android the app-switch also needs the manifest to declare what it wants to see, and the approval to use national identity sign-in sits outside the build entirely. The Dubai page sets out what those approvals wait on.
FAQ · 04
It is a rebuild of the interface and a reuse of everything under it. The API layer, the data model and the business rules survive because they were never platform code; the screens do not, because converting an interface means writing it again in a different toolkit. Flutter can also be added to an existing native app screen by screen, which is the sensible route when one flow needs rebuilding and the rest does not. Whether either is worth doing depends on why the current app is a problem, and that is a shorter conversation than it sounds.
FAQ · 05
Yes, with one condition that has nothing to do with Flutter. The framework is actively developed, widely used in production and reaches both stores from one codebase, so the platform risk is ordinary. The real long-term risk on any framework is a codebase only one person understood, which is the more common way an app in this market becomes unmaintainable. Documentation, a written architecture and accounts in your own name matter more to year three than the framework name does, and the pillar sets out what year two costs.
FAQ · 06
Three cases, and we will name them before a proposal rather than after one. A graphics-heavy product where the rendering is the product itself is better native. A platform SDK with no maintained plugin, on a hard date, is a risk you would be carrying rather than us. And a team that already writes React every day will maintain a React Native codebase more happily than a Dart one, which matters more than any benchmark. Whether an app is the right shape at all is a question before this one, and it is answered here.
FAQ · 07

Keep exploring

Explore Mobile App Development

Part ofMobile App Development

iOS App Development

Native Swift, and the entity Apple publishes as seller.

Android App Development

Kotlin, and the five manufacturer skins this market runs.

Cross-Platform Apps

One codebase, and the parts written per platform.

React Native Development

For teams that already write React and have to hold it.

eCommerce App Development

A shopping app costed against the repeat order.

On-Demand App Development

Two-sided products where the fleet is the harder half.

Enterprise App Development

Internal apps for staff who are not at a desk.

SaaS App Development

Subscription products whose customer is a licensed company.

App UI/UX Design

A component system engineering builds from, in both directions.

Next step

Get your Flutter app scoped.

Send what the app has to do and which scripts it ships in. We will come back with the build shape and where the directional work sits.

Tell us what you need.

What Flutter app development gives you.

One engine draws every screen.

One layout, mirrored for Arabic.

Native code where it is needed.

What a Flutter build gives you.

Screens Flutter draws itself.

Changes you can see instantly.

Dart, with a route to native code.

The same result on both phones.

Android and iPhone styles included.

The same code on the web.

Three ways to ship in Arabic.

Why Flutter pays off here.

One engine keeps Arabic and English identical.

Fixed left and right spacing will not mirror.

Payments and sign-in still need native code.

Much of the demand for this term is job seekers.

Inside a Flutter build.

Scope and the Arabic decision.

Designing both directions at once.

Payment sheets and sign-in.

Testing in both languages on real phones.

Store listings in both languages.

Handover, with the Arabic rule written.

Built with Flutter and Dart.

From the Arabic decision to both stores.

Deciding the Arabic approach.

Building one screen set.

Keeping both languages in step.

Our written commitments.

Flutter apps, answered.

Explore Mobile App Development

iOS App Development

Android App Development

Cross-Platform Apps

React Native Development

eCommerce App Development

On-Demand App Development

Enterprise App Development

SaaS App Development

App UI/UX Design

Get your Flutter app scoped.