Most comparisons of ChatGPT, Claude and Gemini for building apps are written in English, about English apps. That misses the part that decides whether a tool works for a clinic in Riyadh, a training centre in Abu Dhabi or a real estate office in Doha: can it build something that works properly in Arabic, for customers who switch between Arabic and English in the same sentence?
I'm not going to hand you a scorecard. The models change every few months, and a ranking from September is stale by December. What doesn't change is what an Arabic business app needs. Below is the test I'd run on each tool before trusting it with a real project, the Gulf-specific details that usually break, and where each of the three fits.
The short version
- Claude is the quickest way to get a small interactive tool you can share from a chat. Claude Code is its coding agent for real codebases.
- ChatGPT pairs the general assistant with Codex, a coding agent that runs on the web, in a CLI and in your editor.
- Gemini has the most "app builder" of the three: Google AI Studio's Build mode can add a Firestore database, Firebase sign-in and hosting on Cloud Run.
All three can write Arabic text and right-to-left layouts. None of them, on its own, gives a non-developer a hosted app with a database, staff logins and a custom domain, except AI Studio on Google Cloud. For the full feature and pricing table, see our ChatGPT vs Claude vs Gemini guide.
Why Arabic apps fail in ways English apps don't
When an AI tool builds an English app badly, you usually see it. When it builds an Arabic app badly, the screenshot often looks fine and the problems show up a week later with real data. These are the ones I check first.
1. Right-to-left is more than dir="rtl". Setting the page direction flips the text. A proper RTL layout also mirrors the navigation, puts the back arrow on the right, flips icons that imply direction (arrows, progress, "next"), and keeps things that shouldn't flip, like phone numbers, prices and logos, the right way round. Ask the tool to switch the page to Arabic and look at the sidebar, the breadcrumbs and every arrow.
2. Mixed text. Gulf data is bilingual inside single fields: an Arabic customer name with an English company name, an address with a building number and a Latin street name, a WhatsApp message that mixes both. Bidirectional text breaks punctuation and number order in ways that are easy to miss. Paste in a real line like "شركة الريم - Al Reem Trading LLC, Office 1204" and see where the dash and the number end up.
3. Search that ignores how people type Arabic. People type أ, إ and آ interchangeably, ة and ه at the end of words, ى and ي, with or without diacritics and tatweel. A search for "احمد" should find "أحمد". If the app does a plain text match, half your customers can't be found. Ask for normalised search and test it.
4. Numbers and dates. Some users expect Eastern Arabic numerals (١٢٣), most Gulf business software shows Western ones (123), and either way they must sort and calculate correctly. In Saudi Arabia many forms still need the Hijri date next to the Gregorian one. Decide which you want and tell the tool, or you'll get whatever the model guessed.
5. Fonts. The default system font for Arabic on many devices is fine for reading and poor for a branded app. Good open fonts exist (IBM Plex Sans Arabic, Noto Kufi Arabic, Tajawal, Cairo); ask for one and check that bold weights and numbers render well.
6. Local business rules. VAT is 5% in the UAE and 15% in Saudi Arabia, invoices in Saudi Arabia have to meet ZATCA's e-invoicing rules, phone numbers come as +971 and +966 with different lengths, and customers expect a WhatsApp button, not just a contact form. A general model knows these facts when asked. It won't apply them unless you tell it to.
7. Where the data lives. The UAE and Saudi Arabia both have personal data protection laws. If you're storing patient or customer records, know which region your database runs in and who can see it. This is a question for your hosting choice more than for the chatbot.
The test: one prompt, three tools
Give each tool the same small, realistic app. Here's the prompt I use. It's short enough for a free tier and covers most of the list above:
Build a bilingual (Arabic and English) appointment booking page for a dental clinic in Riyadh. Default language Arabic, full right-to-left layout with a language switch. Patients choose a service, a dentist and a time slot, and enter their name and a Saudi mobile number (+966). Show prices in SAR including 15% VAT. Show the appointment date in both Gregorian and Hijri. Staff see a list of today's bookings, searchable by patient name in Arabic or English, where a search for احمد also finds أحمد.
Then check, in this order:
- Does it run? Can you click through a booking in the preview?
- Is the RTL real? Mirrored layout, correct arrows, numbers and prices not reversed.
- Mixed input. Enter a name like "محمد Al-Harbi" and a phone number with spaces. Does it save and display correctly?
- Search. Try the أ/ا case, and a name with ة.
- VAT and dates. Is the VAT maths right, and is the Hijri date there and plausible?
- Where did the booking go? Close the preview and come back. If the booking is gone, the "app" kept data in the browser. That's a demo, not an app.
- Can staff log in? A booking list anyone with the link can read is a privacy problem for a clinic.
Steps 1 to 5 test the model. Steps 6 and 7 test the tool around it, and that's where the three differ most.
What to expect from each
Claude. Artifacts open next to the chat and can be shared by link, so you'll see the booking page quickly and can send it to a colleague in Arabic. Artifacts can keep some persistent data on paid plans, which helps for a small internal tool. For a clinic's real booking system with patient data and staff logins you'd move to Claude Code and choose your own hosting and database.
ChatGPT. The chat can preview supported code such as HTML and React components, which is enough to judge the layout and the Arabic. To get a real app, Codex can build it in a project, and then you decide where it's hosted and where the database lives.
Gemini (AI Studio Build mode). This is the closest of the three to a full app out of the box: it can provision Firestore, add Firebase sign-in and deploy to Cloud Run. Check which Google Cloud region it deploys to if data location matters to you, and expect Cloud Run and paid model usage to add costs.
The honest summary: for the Arabic itself, the gap between the three is smaller than the gap between "a preview" and "an app with a database, logins and a domain". Pick the model whose output you like, then decide how you'll get it online.
Building it as a real app with Mythex
Disclosure: I work on Mythex, an AI app builder, so take this section as one option rather than a verdict.
Mythex is aimed at the step-6-and-7 problem. You describe the app in chat, in Arabic or English, and its agent writes the code, runs it in a cloud sandbox with a live preview, attaches a Postgres database and file storage, and publishes it to a public address or your own domain. It builds fully in Arabic, including right-to-left layouts.
The same dental clinic prompt works as a first message. Then I'd follow up with the parts that usually need a second pass:
Make Arabic the default for patients and English the default for staff, each with a switch. Store every patient name in two fields, Arabic and English, and search both with Arabic normalisation (أ إ آ → ا, ة → ه, ى → ي, ignore diacritics).
Add a staff login. Only signed-in staff can see bookings. Add a daily view per dentist and a button to send the patient a WhatsApp reminder with the appointment time.
You can click on any element in the preview to change it, which is quicker than describing a misaligned Arabic label in words.
When it's ready, publishing gives it a live address, and on Pro you can put it on the clinic's own domain.
Honest limits. Mythex builds web apps, which work on phones in the browser but aren't App Store apps. Login providers, email and payments use your own accounts and keys, which the agent wires in for you but which you still have to set up. And like any AI-built app, you should test the VAT maths, the date handling and the search yourself before patients rely on it.
If you'd rather stay in Claude or Codex, Mythex also runs a remote MCP server, so those tools can build and publish in a Mythex sandbox.
For teams
If more than one person will build or use these apps (a clinic group with several branches, an agency building for Gulf clients), the team setup matters as much as the model:
- A shared workspace with roles, so the operations manager can edit and the front desk can only use the app.
- Members-only apps, so the bookings list opens only for colleagues who are signed in.
- SSO on your company domain, so staff sign in with their work accounts and leavers lose access when IT removes them.
On Mythex these are on the Business plan; see pricing for the current plans.
A checklist to keep
- Same prompt in each tool, with real Arabic and mixed data.
- RTL mirrored properly; numbers, prices and phone numbers not reversed.
- Arabic search normalised (أ/ا, ة/ه, ى/ي, diacritics).
- Dates and numerals decided on purpose; Hijri where Saudi forms need it.
- VAT, currency and phone formats for your country.
- Data kept on a server, not in the browser, and you know which region.
- Staff logins and members-only access before any real customer data goes in.
Run that list on all three this week. It takes an afternoon, and you'll learn more from it than from any benchmark.
Top comments (2)
Feels like we are past the "can it do it" phase and into "can you trust it to do it".
Agreed, and for Arabic apps "trust" is very concrete. All three models produce a screen that looks right; the differences show up in the boring checks: does a mixed Arabic/English line keep its order, do phone numbers and prices stay left-to-right inside an RTL form, does a Hijri date survive being saved and read back, does search find "احمد" when the record says "أحمد". That's why the plan grades on your own data rather than a sample prompt. A model you can trust is one whose mistakes you'd catch before a customer does.