Saudi app development: PDPL, right-to-left layout and payments

Saudi app development succeeds when three things are designed in from day one: Personal Data Protection Law readiness, an Arabic-first right-to-left interface, and local payment and identity integrations such as mada cards and national sign-in. Treat them as architecture, not polish, and your timeline and budget stop drifting after the first demo.

This guide is for founders, product managers and IT leads preparing to brief an app team for the Saudi market. It draws on the localization and data-handling patterns in the ImadDhin portal and our public case study. These are code-level observations, not client outcomes or guarantees.

Why Saudi app projects need a different brief

Saudi Arabia is one of the most mobile-first markets in the region, and users arrive with high expectations shaped by polished government and banking apps. An app that renders Arabic awkwardly, forces an English-only checkout or asks for unnecessary personal data feels untrustworthy immediately.

The market also has specific infrastructure. mada debit cards are central to everyday payments alongside international cards, Apple Pay and local wallets. Many flows involve national digital identity services such as Nafath for verification. Addresses often use the national address format. Some users and government-related contexts still reference the Hijri calendar. None of these are hard on their own, but each one needs to be named in the scope.

Then there is regulation. The Personal Data Protection Law, overseen by the Saudi Data and AI Authority, sets rules for collecting, using, storing and transferring personal data. Government entities, critical infrastructure and regulated sectors such as finance and health also follow cybersecurity controls and sector rules. A proposal that does not mention any of this is incomplete.

What teams often get wrong

• Designing in English left-to-right and flipping the layout at the end, which breaks alignment, icons and forms.
• Offering only international card payments and losing users who expect mada or a local wallet.
• Collecting national ID numbers, dates of birth or location without a clear purpose, retention period or legal basis.
• Storing personal data abroad without checking the transfer rules.
• Leaving the admin panel English-only, so the operations team in Riyadh or Jeddah works around it with spreadsheets.
• Estimating by screen count instead of by integrations and compliance work.

A practical approach

Structure the project around decisions that must be made before design, then the build, then the operations that keep the app compliant after launch.

Decide the language model first

For most consumer apps in the Kingdom, Arabic should be the default language with English available. Design Arabic screens first, or at minimum in parallel, using direction-aware layout rules. Decide how numerals, dates and currency are displayed, and whether Hijri dates are shown alongside Gregorian ones for specific features.

Map personal data before building

List every personal data field the app collects, why it is needed, where it is stored, who can access it and when it is deleted. Collect the minimum. This data map drives your privacy notice, consent screens, database design and hosting decision, and it is the first document a compliance reviewer will ask for.

Name every integration

Payment gateway and methods, identity verification, maps and addresses, SMS for one-time codes, push notifications, customer support channels such as WhatsApp, analytics and any government or enterprise system. For each, write down the owner, the test environment and the failure behavior.

Plan operations and compliance tooling

Build admin tools for data subject requests, such as access, correction and deletion, from the start. Add audit logs for access to sensitive records, monitoring, crash reporting, and a documented release process. Decide who owns the app store accounts and the cloud accounts, which should be your company, not the vendor.

PDPL and related rules, at a high level

This section is orientation, not legal advice. Have counsel familiar with Saudi law review your design.

The Personal Data Protection Law covers the lawful processing of personal data, transparency through privacy notices, consent where required, the rights of individuals to access and correct their data, security safeguards, breach notification and restrictions on transferring personal data outside the Kingdom. Sensitive data such as health, genetic or credit data attracts stricter treatment. Implementing regulations and guidance from the regulator add detail, so check the current versions during scoping rather than relying on summaries.

In engineering terms, the law pushes you toward data minimization, clear consent flows, encryption, access control, retention schedules and a deliberate hosting choice. Major cloud providers now operate regions in or near the Kingdom, and some clients or sectors will require in-country hosting. If your app serves government entities or critical sectors, cybersecurity control frameworks from the national cybersecurity regulator may apply as well.

Implementation considerations

Right-to-left is a layout system, not a mirror. Use start and end instead of left and right. Flip directional icons such as back arrows, but not media controls, logos or charts that have their own conventions. Test bidirectional text in real flows: an Arabic sentence with an English brand name, an order number and a phone number is where bugs appear.

Choose Arabic fonts that stay legible at small sizes and support the weights your design uses. Expect Arabic strings to differ in length from English ones and design flexible containers. Localize push notifications, emails, SMS templates and store listings, including screenshots.

For payments, work with a gateway that supports mada alongside international cards and wallets, and design every failure state: declined card, timeout, duplicate charge, refund. Payment webhooks must be idempotent so that a retried notification never creates a second order. Our guide to idempotent Stripe webhooks explains the pattern, which applies to any gateway.

For identity, use national sign-in only where the use case justifies it, and store the minimum returned attributes. Phone-number login with one-time codes is common for consumer apps.

Trade-offs

Cross-platform frameworks such as Flutter or React Native keep Arabic behavior consistent on iOS and Android and reduce duplicated work. Native development offers finer platform control for demanding apps. Both require disciplined right-to-left testing.

In-country hosting simplifies some compliance conversations but can limit service choices and increase cost. Hosting in another region may be acceptable for some data and not for others. Decide per data category, with legal input, instead of one blanket rule.

A local vendor brings procurement familiarity and in-person workshops. A remote studio can bring senior engineering and a different cost structure. What matters most is who writes the code, who owns the accounts, and who is accountable after launch.

Lessons from ImadDhin work

These are implementation observations from our own public code and case study.

The ImadDhin portal ships an Arabic locale with right-to-left direction applied once at the document level by the locale layout, so every component inherits the correct direction. Exceptions such as logos are opt-outs, not the default. This approach removed a whole class of mixed-direction bugs compared with setting direction component by component.

The portal's inquiry flows save the primary record before calling optional integrations such as email or CRM, and do not require account creation to submit. For a Saudi app, the same principle applies to personal data: store what the core flow needs, make optional processing clearly optional, and never let a failing integration break the main action.

The public FoCoCo case study shows a Flutter app with a companion web app and shared accounts across both. The transferable lesson is that account identity, deletion and data export should work across every surface from the first release.

Common mistakes to test for

• Every screen in Arabic at the smallest supported phone width and the largest system font size.
• Directional icons flip; media controls and logos do not.
• Mixed Arabic and English text with numbers renders in the correct order.
• mada, international card and wallet payments, including declines, timeouts and refunds.
• Duplicate payment notifications do not create duplicate orders.
• Data access, correction and deletion requests can be completed from the admin panel.
• Logs and analytics do not contain national ID numbers or other sensitive fields.

When a simpler solution is better

If your users interact with you occasionally, a fast Arabic-first responsive web app may serve them better than a native app and avoids store review. If the main need is answering questions and taking orders, a WhatsApp flow with human support can carry the business until usage justifies an app. If you are still validating demand, a lean prototype tested with real users in Riyadh, Jeddah or Dammam is cheaper than a full build.

Invest in a full native app when you have repeat usage and features that need notifications, offline access, camera or device integration.

Next step

If you are planning Saudi app development and want a second opinion on scope, data handling or vendor proposals, see how we approach web and mobile product engineering, send a brief through the project form, or book a 30-minute call.