Apps people keep on the home screen.
Native and cross-platform apps with the performance, polish and reliability your users expect from everything else on their phone.
An app is a harder promise than a website. It occupies space on a device, it has to survive review, and a bad release cannot simply be redeployed — it sits in the store until the next one is approved.
So we build them conservatively: offline behaviour decided early, release process set up before the first submission, and crash reporting live from the first build a real user touches.
There are three routes and only one of them is "an app" in the way people mean it. Native, cross-platform, and a progressive web app that installs to the home screen without a store between you and your users. The third is right more often than the industry admits, because the industry does not bill for it.
What we build
Cross-platform products
One codebase across iOS and Android where the product does not warrant two, without the app feeling like a website in a shell.
Native where it matters
When performance, hardware access or platform integration is the point, we build native rather than fight a framework.
Companion apps
Mobile alongside an existing platform — sharing the API, the identity layer and the content model rather than duplicating them.
Progressive web apps
Installable from the browser, works offline, sends push on both platforms, updates the moment you deploy — and never waits for a review. No store listing, no developer account, no 15–30% cut on anything sold inside it. Where discovery does not depend on the store, this is frequently the honest answer.
Release and store operations
Signing, provisioning, staged rollout, store listings and the review cycle, handled rather than handed to you.
How we work
Decide the offline story first
What works with no signal, what queues, what fails loudly. Retro-fitting this is the most common cause of an app rewrite.
Test on real devices
Including the mid-range Android handset much of your audience actually carries, not only the newest phone in the studio.
Ship behind a staged rollout
A percentage of users first, crash rate watched, then widened. A bad release caught at 5% is an inconvenience, not an incident.
The three routes, and what each one costs you
Not the technology — the friction. What it costs to publish, how long you wait, what you hand over, and how quickly you can fix a mistake.
| iOS (App Store) | Android (Play) | Progressive web app | |
|---|---|---|---|
| Developer account | USD 99 a year | USD 25, once | None |
| First review | Usually under a day | Days, and longer for a new account | None — you deploy |
| Fixing a bad release | Resubmit and wait | Resubmit and wait | Minutes |
| Commission on sales | 15–30% on in-app purchases | 15–30% on in-app purchases | None |
| Install | Two taps from the store | Two taps from the store | Add to home screen — needs prompting |
| Push notifications | Yes | Yes | Yes, on both platforms |
| Found by searching the store | Yes | Yes | No — discovery is your website |
Correct at the time of writing; store policy moves and we check it against the current rules before advising. The row that decides it is usually the last one: if people will find you by searching the store, you need to be in the store. If they will arrive from your site, an ad or a QR code, the store is a queue you joined for nothing.
What you get
- iOS and Android builds in your own store accounts
- Source and CI pipeline on your repository
- Crash reporting and analytics wired in
- Store listings, screenshots and review submission
- A release runbook your team can follow
- Privacy labels and data-safety declarations, completed accurately
Before you ask
- Do we need an app at all?
- Often not. If the job can be done by a good mobile site, we will tell you — an app you cannot justify maintaining is worse than no app. The question we ask first is how people will find it: if the answer is "by searching the App Store", you need an app; if it is "from our website or a QR code on a receipt", a progressive web app will do the same job with none of the queue.
- What is the catch with a progressive web app?
- Discovery and habit. Nobody browses for one, and adding to the home screen has to be prompted rather than assumed — on iOS it is a share-sheet tap most people have never made. Deep hardware access is also thinner than native. In exchange you keep every dirham of what you sell, and a bug is fixed in minutes rather than after a review.
- How long does the first release take to appear?
- Apple is usually under a day now. Google is the one that surprises people: a new developer account can face a closed test with a set number of testers over a fortnight before production access is granted at all. We start that clock at the beginning of the build rather than at the end, which is the single most common reason a launch date slips.
- What gets an app rejected?
- Almost always the same handful: an incomplete or inaccurate privacy declaration, a sign-in wall with no way for the reviewer past it, payments routed around the store, a crash on the reviewer's device, or a listing screenshot that does not match the build. We check all of them before submitting rather than finding out a week later.
- Who publishes it?
- You do, from your own developer accounts. We set them up and submit on your behalf, but the listing stays yours.
The rest of the stack
Tell us what you're building.
Send the brief — or the problem, if the brief doesn't exist yet. We come back within one business day with an honest view of how we can help.
Start a project