A good share of the mobile app enquiries that come out of Abu Dhabi are not really consumer app enquiries. They are operational systems that happen to need a phone at one end: a field inspection tool, a workforce app for a facilities contractor, a patient or member app attached to an existing back office, a logistics app that has to talk to a system somebody installed in 2014.
That distinction matters more than any technology choice, because it moves the difficulty. A consumer app is hard because of design, retention and acquisition. An operational app is hard because of integration, permissions, offline behaviour and the data quality of the systems it connects to.
Where the cost actually sits
Clients tend to price an app by counting screens. Screens are the cheap part. The expensive parts are usually invisible in a wireframe.
Integration is first. Connecting to an existing ERP, HR system or booking platform is straightforward when it has a documented modern API and genuinely difficult when it does not, which in this region is common. A system with no API means building one, and that is a back end project sitting underneath the app project.
Offline behaviour is second, and it is the requirement that most often arrives late. An inspector in a basement plant room, a driver in a warehouse, a technician on a site with no signal. Supporting that properly means local storage, sync, and a rule for what happens when two people edited the same record. It is a substantial piece of engineering and it changes the architecture, so it needs deciding at the start rather than in month three.
Roles and permissions are third. Operational apps almost always have several kinds of user with different rights, and permissions designed casually become the thing you rewrite.
Then the long tail: push notifications that work reliably on both platforms, Arabic and right to left layouts, app store review, device management if the phones are company owned, and accessibility where a public entity is involved.
Native, cross-platform, or neither
For most Abu Dhabi business apps, cross platform is the right default. One codebase, both platforms, and the performance ceiling is far above what an operational app needs.
Native earns its cost when you are doing something genuinely device-heavy: continuous location tracking with strict battery behaviour, camera or sensor work beyond photographs, tight integration with platform features, or a consumer product where the last ten per cent of polish is the product.
The option worth considering more often than it is: not building an app. If your users are on a desktop most of the day, if the workflow is occasional, or if you mainly need a form and a list, a well built responsive web application delivers sooner, costs less and updates without an app store review. Reserve an app for cases that need the phone itself.
How to scope it without guessing
Write down the three things a user must be able to do on a phone that they cannot do today. Not the feature list, the three. Everything else is phase two until proven otherwise.
Then find out what your existing systems can actually expose, before design starts. This single step reorders most app projects, because the honest answer is frequently that the back end needs work first and the app is the easy half.
Then decide the offline question deliberately, and the permissions model, and who owns the app store accounts. Those accounts should be yours. An app published under a supplier's developer account is a hostage.
Budget for year two from the start. Both platforms release annually, certificates expire, dependencies age, and an app left untouched for eighteen months does not stay still, it degrades.
For the cost question in more detail, the honest breakdown of mobile app development cost sets out the ranges, and app development costs in Saudi Arabia compares the neighbouring market. On the technology choice, see Flutter against React Native, native iOS against Flutter for MENA startups, and the progressive web app decision.
