Start a project
Start a project Book a call
International

Mobile app or mobile website: a decision guide for Gulf businesses

A plain guide to choosing between a responsive website, a progressive web app and a native app. It covers store accounts, review, payment rules, Arabic right-to-left support, yearly costs and a decision list.

ESTASOFT
11 min read
Lilac cover with a browser window and a phone, with the title App or mobile website
On this page
    On this page

      Your team says you need an app. A competitor has one, or customers ask for one. But an app is not a website in a smaller box. It brings store accounts, review queues, yearly updates and payment rules that a website does not have. Sometimes a mobile website is enough.

      This guide explains a responsive website, a progressive web app and a native app. It covers what an app needs that a site does not, Arabic and right-to-left checks, and costs that return every year. It ends with a decision list for your next meeting. Store facts were read on 4 November 2026 and change often.

      Three options in plain words

      • Responsive website. One site that adapts to phone, tablet and desktop. Customers open it in a browser, and you need no store account.
      • Progressive web app (PWA). A website with extra abilities. The web.dev learning course describes a PWA as a website with enhanced features, not a separate kind of software. It can be installed to the home screen, show a clear message when offline and send push notifications where the browser allows it.
      • Native app. Built for iPhone or Android and delivered through Apple's App Store or Google Play. It needs a developer account and it passes store review.

      A PWA does not happen by itself. The web.dev page on installing (last updated 19 September 2024) says Chrome offers its install prompt only when the site uses HTTPS, has a manifest file with a name, start address, display mode and icons (including 192 and 512 pixel sizes), and the visitor has clicked on the page and spent at least 30 seconds on it.

      iPhones add a step. A WebKit post dated 16 February 2023 says web push arrives with iOS and iPadOS 16.4 for web apps that a person has added to the Home Screen. The permission request must respond to a direct action, such as a tap. The same post says developers do not need to join the Apple Developer Program for this. Later iOS versions may differ, so check Apple's current documentation. Then ask how many of your customers would add your site to the Home Screen and agree to notifications.

      What an app needs that a website does not

      Store accounts in your company's name

      Apple lets you enrol as an individual or as an organization. For an organization, Apple's help page says the company must be a legal entity that can sign contracts with Apple. Trade names and branches are not accepted. You need a nine-digit D-U-N-S number, a work email on the company domain, a working public website and a person with legal authority to enrol. The legal entity name appears as the seller on the App Store. Apple says these numbers are free in most places. Its D-U-N-S page says allow up to 5 business days to receive the number and up to 2 more business days for Apple to receive it. Apple's membership page showed a fee of 99 US dollars per membership year, or in local currency where available, when read on 4 November 2026.

      Google Play's help page showed a one-time registration fee of 25 US dollars when read on 4 November 2026. Check both fees before you pay. An organization account also needs a D-U-N-S number, and Google says applying for one can take up to 30 days. Google's testing page says personal accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in for 14 days in a row before they can apply for production access. That page covers personal accounts only, and rules change, so check it. Payment method checks can take up to 5 days.

      Start these accounts early, because other organizations set the pace. The company, not a freelancer or an agency, should own them. The same goes for the code: see who owns the code in a software project.

      Check your country too. Google's list of supported locations shows the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain, Oman and Iraq under developer registration. Under merchant registration it shows the same list except Iraq. The page does not say what merchant registration covers. If your company is registered in Iraq and plans to sell inside an Android app, ask Google support or a local adviser how this applies before you design the payment flow. Apple says enrolment may not be supported in certain regions, for example because of sanctions or other restrictions, so confirm that your country is covered before you start.

      Store review

      Every app and every update goes through review. Apple says App Review works around the clock and typically looks at at least half of submissions in under 24 hours and 90% in under 48 hours. It calls these times typical, not promised. Apple lists common problems such as crashes, placeholder content and broken links, and it requires a privacy policy link in every app. Its guidelines also say an app should offer more than a repackaged website (4.2) and must let people delete their account inside the app if it lets them create one (5.1.1). Google's publishing page says certain developer accounts get a more thorough review that can take up to seven days or longer in exceptional cases. Plan your launch date with slack.

      Payment rules

      Both stores split payments by what you sell. Apple's guidelines (3.1.1) say digital features unlocked in the app, such as subscriptions, must use Apple's in-app purchase, with some exceptions. Physical goods, and services used outside the app, must use other methods such as Apple Pay or card entry (3.1.3(e)). Google's payments policy page lists digital items, subscriptions and cloud software as requiring Google Play's billing system. It lists physical goods, such as groceries and electronics, and physical services, such as food delivery and transport, among purchases the billing system does not support.

      A shop, delivery or booking app usually sells physical goods or services, so these rules may not touch its payments. An app that sells courses, subscriptions or paid features probably falls under them. Platform fees apply when the store's billing is used. Apple's membership page and Google's service fees page both show tiered rates that differ by region and programme, so read the current pages and ask which rate applies to you.

      Yearly upkeep

      The stores raise their technical requirements every year. Apple's upcoming requirements page says apps uploaded to App Store Connect must be built with Xcode 26 or later since 28 April 2026. Google's target API page gives 31 August 2026 as the date by which new apps and updates must target Android 16 (API level 36), with an extension to 1 November 2026 that developers could request. Both dates have passed, so read the page for the current level. It adds that existing apps that fall behind stop being offered to new users on newer Android versions, while people who already installed the app are not affected. A website has no such calendar. An app needs a maintenance line in your budget every year, even with no new feature.

      Arabic and right-to-left in an app

      Right-to-left support is a design and build decision, not a translation job. Both major platforms document it.

      • Android. The Android guide says to switch on right-to-left support in the app manifest, to replace left and right in layouts with start and end, and to test with the "Force RTL layout direction" developer option. It warns that some framework components do not mirror on their own.
      • iPhone. Apple's Human Interface Guidelines say system interface frameworks support right-to-left by default, so standard layouts may flip without extra work. They say not to flip logos, photographs or a checkmark, and not to reverse the digits inside a number such as a phone number. They say to align a paragraph of three or more lines to its own language. They also note that Arabic text can look small beside capital Latin letters and suggest raising its size by about 2 points.
      • Numbers. Apple's guidance says Western and Eastern Arabic numerals both occur and that use varies between countries and even areas. Ask real users which digits they expect.
      • Website or PWA. W3C advises setting the dir attribute to rtl on the html element of a right-to-left page and giving the language separately, because a language tag does not set direction. It also recommends start and end style properties instead of left and right, and automatic direction for text that people type in.

      For the website side of Arabic layout, fonts and search, see Arabic store website: RTL, fonts and search. Whatever you choose, test both languages on real phones. How to test a bilingual Arabic and English website gives a test plan that also works for the web part of an app.

      Costs that come back every year

      • Store account fees and platform fees on digital sales.
      • Updates to meet store requirements, and review for every update.
      • Support in Arabic and English, including who answers on which day.
      • Server costs: hosting, storage, backups and monitoring.
      • Push message services, analytics, error reporting and real-phone testing in both directions.

      A decision list for your meeting

      These questions are rules of thumb, not laws. Write the answers down.

      1. Can a customer finish the main task in a mobile browser? If yes, start with a responsive website.
      2. Do you need reminders? Test a PWA first. On iPhone, find out how many customers would add it to the Home Screen.
      3. Does the idea depend on a phone feature? Ask your developer to name each feature, such as camera, scanning or background location, and test it in the browsers your customers use. A feature that is missing is a real reason to go native.
      4. Will people open it often? A loyalty card, a booking tool or a field team app may justify an icon on the phone.
      5. What do you sell inside it? Digital items bring the store's billing rules and fees. Physical goods and services use other payment methods.
      6. Which phones do your customers use? Check your own site analytics.
      7. Who owns the accounts and the code? The company. Name the person who holds the logins.
      8. Can you pay for yearly updates and two-language support? If not, start smaller.

      Many teams move in steps: a responsive website, then PWA features, then a native app once evidence shows the need. If your answers point to a native app, ask a mobile apps partner to scope a first release.

      This is general information, not legal or tax advice. Check the current rules or ask a qualified adviser before you decide.

      ESTASOFT can help with mobile apps. To start, send a short brief on the contact page. If you are planning a whole product, not only an app, read from idea to first release.

      Sources

      Written by
      ESTASOFT

      Need help with a project?

      Share a short brief. We reply with next steps.

      Start a project Book a call

      Book a call

      30 minutes. Free.

      Tell us about your project and we will suggest a time.

      Send a request

      Or email us at info@estasoft.com

      Cookie preferences

      Necessary

      Needed for the site to work. Always on.

      Always on

      Preferences

      Remember choices such as language and region.

      Analytics

      Help us understand which pages are useful.

      Marketing

      Used to measure and improve campaigns.