Dubai · Web Development
Mobile app development in Dubai — released under your own store accounts.
iOS and Android, native or cross-platform, built on the same API and design system as the website they sit beside. You finish holding both apps live, the repository, the signing keys, and a pipeline that turns a merged branch into a release you can ship without us.
- Store accounts in your name
- Signing keys handed over
- One API behind both apps
What's included
Six things that exist only because it ships to a store.
An app is not a website in a smaller frame. These six are what separate the two, and none of them is visible in a screenshot.
The platform decision, made once
One shared codebase or two native ones, how far back the OS support runs, and what is genuinely in version one. The answer follows from how hard the app leans on the device, and the reasoning is written down rather than assumed.
Interfaces that follow each platform
Back behaves differently on Android; sheets, tabs and safe areas behave differently on iOS. Type has to survive a phone set to large text, and the layout mirrors when the phone is set to Arabic — that is an operating system setting, not something the app gets to ask about.
The API both apps talk to
One backend behind iOS, Android and the website, versioned so this week's change does not break the copy somebody installed a year ago and never updated. Old versions stay on phones for a long time, and the API has to keep answering them.
The device features you wanted an app for
Push notifications, offline use, camera, location, biometric sign-in, and payment through the platform's own sheet. Each carries a permission prompt, a denied state and a settings screen the user may never go back to — so each is designed as a flow rather than switched on as a feature.
Signed builds, produced by a pipeline
CI turns a merged branch into a signed build, testers receive it through TestFlight and Play's internal track, and the release reaches users in stages while crash reporting is watched. A release nobody can reproduce is a release nobody can fix — and here the fix still has to pass review before it reaches anyone.
Submission, and the review that follows
Listings, screenshots at every required size, age ratings, privacy labels and Play's data safety form — each of which has to describe what the app actually does, because the declarations are checked against its behaviour. Test credentials and a reviewer note go in with the build, not after the first rejection.
Who it's for
Three situations where the device is the requirement.
An app earns its place when a browser genuinely cannot do the job. If none of these describes you, an app is usually the expensive answer, and that is worth hearing in the first call rather than in month three.
Something used every week, not every year
Repeat use is what pays for an app: an icon on the home screen, a session that remembers who you are, and a notification that is welcome rather than resented. The habit has to exist before the app does — an app is somewhere to put a habit, not a way to manufacture one.
You can name the day of the week somebody opens it.
A web product that ran out of browser
The portal or the store works, and everything now being asked for is something a browser will not give you: a notification when a status changes, a scan instead of a typed reference, use that survives a lift or a basement. The backend exists already; what is missing is the device.
The feature you keep being asked for is a notification.
People working away from a desk
Inspectors, drivers, technicians and site staff recording what happened where it happened — photographs, readings, signatures, timestamps. Signal is unreliable by definition, so the app has to hold the work locally and reconcile it afterwards instead of failing at the moment of capture.
Your team photographs a paper form and sends it on WhatsApp.
How we deliver it
Five stages, and the store is one of them.
Every stage ends in something installable or signed off. The last one is the only part of the project whose timing belongs to somebody else, so it is scheduled rather than hoped for.
01
Scope, platforms and version one
Which platforms ship, how far back OS support runs, shared codebase or native, and which device features are genuinely load-bearing. It ends with a scope in writing, a fixed price, and a feature list we have actively tried to shorten — version one is meant to be the smallest app worth installing, not the roadmap.
02
The API and the offline story
What the app can do with no signal, what it queues, and what happens when the same record is changed on two phones. Settled before screens are built: retrofitting offline behaviour onto an app that assumed connectivity is close to a rewrite.
03
One journey, on a real handset
Sign in, do the thing, receive the notification — installed on real devices through TestFlight and Play's internal track in the early weeks rather than shown running in a simulator. Nothing exposes a wrong assumption like the thing being carried around in a pocket for a week.
04
The rest of it, and the states a phone invents
Remaining screens, then the conditions only devices create: permission denied, notifications switched off, storage full, the app killed in the background, a token expired overnight, an OS upgrade mid-flow, and the smallest screen still in support.
05
Submission, staged rollout, handover
Listings and declarations prepared alongside the build, submitted, then released to a share of users first while crash reporting is watched. After that the accounts, the keys and the pipeline are walked through with whoever cuts the next release.
Stack
Boring technology, chosen so the next developer recognises it.
Nothing here is exotic. That is the point: an unusual stack is a lock-in mechanism dressed up as innovation.
- Back-end & data
- Node.jsPostgreSQLLaravelRedisPrisma
- Infrastructure
- VercelAWSCloudflareGitHub ActionsSentry
Deliverables
Everything handed over, including the keys.
An app is not finished when it is approved. It is finished when somebody other than us can cut the next version, so the handover is written for that person.
- Both apps live under Apple and Google developer accounts enrolled in your company's name
- The repository, plus the CI configuration that turns a merged branch into a signed build
- Signing certificates, provisioning profiles and the Android upload key, with the recovery steps written down
- A README that gets a developer from a clean clone to the app running on a simulator and on a real handset
- The API documented, with the version each shipped build expects
- The store listings as source — screenshots at every size, descriptions, age ratings, privacy labels and data safety answers
- Crash and error reporting in your own Sentry project, not one we keep
- A recorded walkthrough of cutting a release, from merged branch to staged rollout
You hold all of it from day one, not from the day the last invoice clears — and on mobile that matters more than it does on the web. A website can be pointed at a new server in an afternoon. An app in someone else's developer account has to be transferred between accounts, or republished as a listing every existing user installs again.
Pricing
What an app costs, and what comes after it.
AED 95,000
from
That is the Platform tier, and apps are scoped per project rather than by feature list. Three things move the number: whether one platform ships or two, whether an API already exists or is built alongside, and how deeply the app uses the device. The year after launch is a separate line — care plans start at AED 1,500 a month. Prices exclude 5% VAT, and payment is milestone-based.
What changes the priceWhat that covers
- A written scope agreed before the price is fixed
- The API and data model, settled before screens
- Staging and a CI pipeline that produces signed builds
- Submission on your own developer accounts, review rounds included
- Multi-language, Arabic and RTL included
- SLA-backed response once it is live
Retail and delivery
The app is where repeat purchase lives — a saved card, a saved address, an order placed again in three taps. Push has to earn its permission: a status update on an order somebody is waiting for is welcome, and a promotion sent on a Friday night is how an app gets deleted. Checkout runs through the platform's own payment sheet, and Apple Pay carries a meaningful share of UAE mobile checkouts.
Construction and field services
The work happens where the signal does not: basements, plant rooms, sites hours from an office. Inspections, snag lists, readings and signatures have to be captured offline and reconciled later, with photographs compressed before they are queued rather than after. And the phone is held in gloves, in direct sun, by someone who cannot stop to read — which decides tap targets and contrast before anything else does.
Apps are one of the services under the rest of our web development work and this is the only one that reaches its users through somebody else's review queue. If nobody needs the device in their hand — accounts, roles and records worked through from a desk — the web application page answers that instead. And where the only new work is wiring systems you already run into each other, with nothing to release afterwards, start at API integration.
Questions
The questions that decide whether to build an app at all.
Apps start at AED 95,000, on the Platform tier, and are scoped per project rather than by feature list. Three things move the number: whether one platform ships or two, whether an API already exists or has to be built alongside, and how deeply the app uses the device. Prices exclude 5% VAT. Ask any app development company in Dubai what year two costs before comparing build prices.
Cross-platform, unless something specific argues against it. One shared codebase means one team, one release cycle and one place a bug gets fixed, and for most business apps the difference never reaches the user. Native earns its cost where the app leans hard on the device — heavy graphics, sustained background work, or a capability that lands on one platform first. The choice is made during scoping and written down with its reasoning.
Sometimes, and it is worth asking before committing to a build. A progressive web app installs from a link, updates the moment it is deployed, and never waits in a review queue. What it still cannot match is sustained background work, deeper hardware access, and a listing in the two places people actually go looking for software. If store presence is part of the point, it is not a substitute.
Almost always — though if you already run one, the work is an API layer rather than a new system. A phone is not a place to keep the truth: accounts, records and rules belong on a server that both apps and the website read from. The part usually underestimated is versioning. A copy installed a year ago is still out there, so the API has to go on answering it.
We fix it and resubmit, and a review round is planned into the schedule rather than treated as a failure. Metadata is a common cause of rejection rather than code — privacy declarations that do not match behaviour, missing test credentials for a login, a permission requested without explaining why, or an app judged to be a website in a wrapper. Each of those is covered by rules Apple and Google publish before you submit, and corrections of that kind are measured in days.
Yours, on both stores, and we work inside them rather than the other way round. Apple ties organisation enrolment to a D-U-N-S number registered to your own legal entity, so the account is naturally the company's. An app sitting in an agency's account has to be transferred, or republished as a listing every existing user installs again — and that only ever comes up when relations are already poor.
Somebody has to, because an app decays even when nothing about it changes. iOS and Android each take a major release every year that deprecates APIs and shifts how permissions behave, store policies change on their own deadlines, and every fix travels through review before it reaches a phone. Care plans run from AED 1,500 a month for updates and monitoring to AED 15,000 for a dedicated squad.
Usually, after an audit — and what decides it is access rather than code quality. We need the repository, the developer accounts, the signing credentials and whatever the app talks to. Where the account or the signing setup is genuinely gone, updating the existing listing may not be possible, and the honest route is a new one: new reviews, new ranking, and every user installing again.
Ready to build something that lasts?
Tell us what you need. You will get a scoped response with an indicative price — from an engineer, not a salesperson.