Arabic and English in the app and in the stores
Both the App Store and Google Play let you publish a separate listing for each language, with its own name, description, keywords and screenshots. Treat the Arabic listing as a product page, not a translation: write it natively, and show screenshots of the real right-to-left screens rather than mirrored English ones. Users who search in Arabic find apps by Arabic words, so the keywords need their own research.
Inside the app, the work is the same as on the web, with mobile-specific traps. Layouts mirror, but not everything should: back arrows and progress bars flip, while play buttons, clocks, charts and brand marks usually do not. Text grows when translated and grows again with the device's font-size setting, so buttons and cards must wrap rather than clip. Arabic needs more line height than Latin text to stay legible. Both platforms allow a language choice per app, so let people use the app in a different language from their phone.
Read Arabic and RTL design and mobile app design for the design side, and the glossary entry on localization for what to separate from code.
One regional detail: some people use phones without Google services and install apps through Huawei's AppGallery. If your audience includes them, decide early whether to publish there, because it changes which libraries for maps, push notifications and sign-in you can rely on.
In-app payments and wallets
For physical goods and services, a native payment sheet such as Apple Pay on iPhone and Google Pay on Android is the fastest checkout and the one users trust. Cards with 3-D Secure stay the fallback. Buy-now-pay-later providers usually offer an SDK or a hosted page, and some retailers still need a cash-on-delivery path, which adds order states your app must show clearly.
Store rules decide which payment method you may use. Digital goods and subscriptions sold inside an app generally have to go through the store's own purchase system, while physical goods and real-world services can use external payment providers. The rules change, so check the current ones before you design checkout, not after.
Payments on unreliable connections
A phone moves between Wi-Fi and mobile data, enters lifts and car parks, and drops requests. If the app retries a payment request after a timeout, the customer can be charged twice. Send an idempotency key with each payment attempt, confirm the final status on your server with the payment provider, and show a clear pending state until it arrives. Never mark an order paid because the app said so.
Keep card numbers off your servers by using the provider's hosted fields or tokens. Ask your provider and counsel which licences and card-industry rules (PCI DSS) apply to your set-up, and ask your accountant what receipts should show. Multi-factor authentication and device checks are worth considering for high-value actions.
Signing in with national digital identity
UAE Pass is the national digital identity and signing app. For a service that must know who the user is, such as a bank, a clinic or a government-linked service, it can replace a long registration form with a verified identity. In general terms, sign-in hands the user to the identity app and back, so the return path into your app has to work on iOS and Android, including when the identity app is not installed and the user falls back to another route.
Integration means onboarding as a service provider, and the requirements depend on your sector, so ask the programme and your regulator what they need before you plan the schedule. Design it as one sign-in option, not the only one. Keep your own account recovery, ask only for the data you need, and keep tokens in the platform's secure storage (the Keychain on iOS, the Keystore on Android).
Notifications, consent and privacy awareness
Ask for notification permission in context, after the user has seen why it helps, not on the first launch. On iOS the system prompt appears once, so a premature refusal is hard to undo, and recent Android versions also ask at runtime. Write notifications natively in Arabic and in English, check that they render right-to-left, and think about when they land: evenings and late nights follow a different rhythm in Ramadan.
Separate service messages (an order shipped, a payment failed) from marketing, and record marketing consent with its date, the wording shown and the language. Make withdrawal as easy as opting in. Keep tracking and advertising libraries to the minimum you can justify, because the privacy details you give each store must match what the app and its libraries really do.
The UAE has a federal personal data protection law, and the DIFC and ADGM free zones have their own regimes. Questions such as where data is stored, how long it is kept and which transfers are allowed belong with your counsel; the UAE page lists the questions to bring.
Awareness, not legal advice. We design apps with awareness of data protection rules and we do not promise compliance. Confirm what applies to your app and your sector with qualified local counsel.
Device and network testing
Test on the devices your users actually hold: current and older iPhones, and Android phones across screen sizes and price ranges, not only the newest flagship. Run the Arabic build with the largest font setting and with a screen reader in Arabic. A layout that survives these three checks rarely breaks in the field.
Test the network as well. Throttle the connection, switch from Wi-Fi to mobile data mid-request, and turn on airplane mode in the middle of a form. The app should keep what the user typed, show cached content while it loads, retry safely and explain failures in plain Arabic and English. Keep images and responses small so screens load quickly on a weak signal.
Whether you build native or cross-platform changes the testing effort. Read iOS and Android development, Flutter and React Native, or the article on native or cross-platform, before you choose.
Release timing and store review
Put store review into the schedule. Review times vary, and a rejection costs days, so submit early, with working demo accounts and clear notes for the reviewer. Use staged rollouts where the store offers them, and keep a server-side switch to disable a risky feature without a new release.
Plan around the calendar. A Ramadan or Eid campaign needs the app update live before the campaign starts, which means submitting well before. Avoid release days right before a weekend or holiday, when support is thin. The guide to launching software in the Gulf covers the regional calendar, and the UAE page covers the UAE week and holidays.
How we build mobile apps for UAE teams
We work remotely and plan calls around your working day. You see working builds every week, installed on real devices through the stores' test channels, so you can try the Arabic flow yourself. Every project begins with a threat review: for a mobile app that covers secure storage, how the app talks to the API, what happens on a lost or shared phone, and how payments and identity flows can be abused.
Before launch there is a security review with a prioritised fix list, and cybersecurity for UAE businesses explains the testing options. For the full service, see mobile development; for the planning question, see what a mobile app costs and pricing models.