Localisation beyond two languages
Arabic and English are the base, but Qatar's residents read many languages, so decide which ones your app needs by looking at your users. Both iOS and Android mirror layouts for right-to-left languages when you build with start and end rather than left and right, and both let users set a language per app. What the platform does not do is judge your content.
- Mirror with intent. Back arrows, progress bars and swipe gestures mirror. Media playback controls, phone number fields and brand logos do not. Decide this per component in the design system.
- Plural forms. Arabic has six plural categories in the Unicode CLDR rules and English has two. Use the platform's plural handling instead of building "1 item" and "2 items" with an if statement.
- Fields that stay left-to-right. Email, phone and URL inputs run left to right even on a right-to-left screen.
- Text size. Arabic needs more line height than Latin text. Test the largest accessibility text size so nothing clips.
- Notifications. Send them in the language the user chose in the app, not the one in the phone settings.
Mobile app design and Arabic and RTL design cover the design side. The bilingual products guide and the glossary entries for localization and right-to-left design go further.
App store listings in Arabic and English
The App Store and Google Play both let you localise the name, subtitle, description, keywords and screenshots for each language. For Qatar that means an Arabic listing with screenshots of the mirrored interface, not English screenshots with Arabic captions, and search terms written in Arabic and in Latin letters, because people search both ways.
- Fill in the privacy details honestly. Apple's privacy labels and the Google Play data safety form must match what the app and its third-party SDKs really collect.
- Give reviewers a way in. If sign-in depends on a national digital identity or a local phone number, store reviewers cannot use it, so provide a demo account or a reviewer mode.
- Check availability. Choose the release countries on purpose, and confirm that the age rating and content settings suit the audience.
- Think about devices without Google services. Some phones in the region ship without Google Play services. If your audience includes them, ask whether you need another store and a push route that does not depend on Google.
In-app payments and wallets
Two kinds of purchase follow different rules. Digital content sold inside an app generally has to use the store's own billing, while physical goods and services such as food delivery, retail or bookings can use an outside payment gateway. Store rules change, so we check the current text before the design is final.
For gateway payments the payment sheet matters more than the logo. Apple Pay and Google Pay are the smoothest way to take a card in an app where your gateway supports them. Local debit cards, mobile wallets and bank transfer options depend on the gateway and your acquiring bank, so ask which you can have before you promise them to the business.
- Never store card numbers. The gateway tokenises them.
- Handle the 3-D Secure step inside the app and return the user with a deep link.
- Assume the app can be killed in the middle of a payment. The server confirms the result by webhook, and the app asks the server for the final state.
- Make requests idempotent, so a retry on a weak connection cannot charge twice.
- Show receipts in the user's language, with amounts formatted for the riyal.
Our pages on fintech and e-commerce go into the product side.
Sign-in with national digital identity
Qatar has a national digital identity that residents use for government e-services, and some other services accept it. If your app needs it, the work is mostly an agreement with the identity owner: eligibility, a test environment and an approved flow. That process, not the coding, often sets the timeline, so start it early.
- Where the provider documents a standard flow such as OpenID Connect, use it, and open it in the system browser or the provider's app rather than a custom web view.
- Ask for the fewest identity attributes you need, and do not keep the national ID number longer than you need it.
- Keep another way in: email or phone verification with multi-factor authentication for people the identity route does not cover.
- Use biometrics to unlock the app on the device, with tokens held in the iOS Keychain or the Android Keystore.
Notifications, consent and privacy
Both platforms ask the user for permission to send notifications, and Android 13 and later asks at run time, as iOS does. Ask in context, after the user has seen why a notification helps, not on the first launch.
- Separate transactional messages, such as order status and security alerts, from marketing. Marketing needs a recorded consent and an easy way to stop.
- Keep sensitive details off the lock screen: balances, medical information and one-time codes can be read by anyone nearby.
- Think about timing. Notifications on Ramadan evenings and early mornings land differently, and prayer times matter to many users.
- List every SDK. Analytics, crash reporting and advertising SDKs send data to their owners, which is a cross-border transfer question for counsel.
Qatar's Law No. 13 of 2016 on Personal Data Privacy Protection is the starting point, and the Qatar Financial Centre has its own data protection rules. Ask counsel what consent you need, how long you may keep data, and where it may be processed.
This page is awareness, not legal advice. Confirm legal and regulatory duties, including rules on electronic marketing, with qualified local counsel.
Device testing and performance on real networks
Test on real devices: current and several-years-old iPhones, a spread of Android makers and screen sizes, small phones with large Arabic text, dark mode and low power mode. Emulators miss many problems.
Networks in cities are strong, but your users still meet weak indoor signal, lifts, car parks and visitors on roaming data. Design for them: show cached content first, retry with back-off, keep payloads small, size images for the screen and show clear offline states. Subset Arabic fonts so they do not bloat the app, and use monitoring to measure start-up time, crash-free sessions and slow screens in production.
The choice between native and cross-platform matters less than these habits. Flutter, React Native and iOS and Android builds all handle Arabic well when the design system is right. The glossary defines a cross-platform app and a native app.
Release timing around Ramadan and Eid
Store review times vary, and a rejected build in the days before Eid means a lost holiday window. Submit early, keep a buffer, and avoid shipping on Thursday afternoon, when the Sunday to Thursday week ends.
- Use phased rollout, which both stores support, so a new version reaches a share of users first.
- Put risky features behind remote switches, so you can turn them off without a store review.
- Keep a forced-update path for the case where a server change breaks old versions.
- Freeze changes before Eid and name someone on call.
- For consumer apps, decide whether to be live before Ramadan, when use patterns change, and load-test the server side before busy shopping periods.
The guide to launching software in the Gulf and the page on software development and security for Qatar cover the calendar in more detail. For the wider service, see mobile development.