CookiesWe use audience-measurement cookies (Google Analytics) to understand how this site is used. Nothing is stored on your device without your agreement.
Mobile apps
Native, hybrid or PWA: we tell you which one fits your project, then we build it. One codebase, iPhone and Android, published on the stores.
The essentials
A mobile app can be built four ways: native, cross-platform, hybrid or PWA. They differ in how many codebases there are to write and maintain, in access to the phone’s hardware, and in whether they go through the app stores.
One Swift codebase for iPhone, one Kotlin codebase for Android. Two codebases to write, two to maintain. In exchange: the best performance and access to all of the phone’s hardware.
A single codebase, compiled for both stores. It is now the default choice for the vast majority of business apps.
A website wrapped in a native shell. The cheapest way onto the stores, and the one you notice most in daily use.
A website installable from the browser. No store, no commission — but limited hardware access and very low visibility on iPhone.
The real trade-off is not about technology but about three questions: what the second platform costs you, what hardware you need, and whether your users will actually install anything. The table below answers the first two, the selector further down answers the third.
The comparison
Indicative ranges for a production app, back end included. The full cost breakdown is on our page how much does a mobile app cost.
In detail
One Swift codebase for iPhone, one Kotlin codebase for Android. You write twice, test twice, maintain twice. In exchange, you get the very best of each platform: perfectly fluid animations, access to every sensor, and deep system integration — widgets, smartwatch, voice shortcuts.
The real cost of native is not the initial build — it is maintenance. Every change, every fix, every OS update has to be handled twice, for the whole life of the app. That is what explains the three-year budget gap, far more than the initial quote.
A single codebase, compiled for both stores. Unlike hybrid, there is no hidden browser inside: React Native drives the phone’s native components directly, and Flutter draws its interface with its own graphics engine. The result: users cannot tell a cross-platform app from a native one — and they never try to.
It is our default choice at OTTOPILOTE. For a business app — accounts, data, forms, payments, notifications — cross-platform delivers the same product as native development for half the budget and half the maintenance.
A website locked inside a native shell, rendered by an invisible browser. It is the cheapest way onto the stores — and also the one you notice: scrolling catches slightly, transitions are not quite the system’s, the app behaves like a website.
Watch the vocabulary. Many agencies sell “hybrid” when they actually mean Flutter or React Native, which are technically unrelated. Always ask exactly which technology will be used: the gap in perceived quality is real, and so is the price gap.
A website that users install on their home screen from the browser. It opens full screen, with no address bar, works offline, and updates itself: you deploy, everyone has the new version. No Apple review, no commission on payments, and content Google can index.
The point few agencies will tell you about iPhone: push notifications have worked since iOS 16.4, but only if the user has themselves added the PWA to their home screen via the Share menu. In practice, almost no one does it spontaneously. If notifications are central to your product and your customers are mostly on iPhone, a PWA is the wrong choice — and it is the only real reason to rule it out.
The shortcut
Answer in thirty seconds — we tell you which approach fits your project, and why.
Your usage is occasional and depends neither on hardware nor on notifications: asking your customers to download an app would add friction for little benefit. A PWA will cost you two to four times less, stay findable on Google, and can evolve into a full app later if usage takes off.
Regular usage, iPhone and Android to cover, a budget to hold: a single codebase in Flutter or React Native gives you the same product as native development, for half the budget and half the maintenance. It is what we recommend to most of our clients.
Your hardware or performance needs go beyond cross-platform’s comfort zone. It costs more, and deliberately so: better to pay for the right tool than to redo the project in a year.
With occasional usage and this budget, a mobile app is unlikely to pay off: it has to be downloaded, kept, reopened. A fast, well-built website will get better results for less. We would rather tell you before the quote.
The question before the question
An app has to be downloaded, kept, then reopened. Three steps, and you lose users at each one. If your service is used two or three times a year, the best-built native app in the world will end up uninstalled — when a fast website would have done the job.
The test is simple: would your customers open this at least once a week? If the answer is no, the right answer is not “native, hybrid or PWA”. It is “no app yet”. We would rather tell you before the quote than after launch.
What we build
Each one answers a specific use. The approach is chosen from that use, not from fashion.
Today’s jobs, before and after photos, the customer’s signature, the job sheet: everything is filled in from the phone, even with no signal. The record reaches the office as soon as the network is back.
Suggested approach: cross-platform
Ordering, paying, tracking an order, booking an appointment: your customers open your app instead of calling you. The notification lands on the phone’s screen, where an email waits in an inbox.
Suggested approach: cross-platform
Your web application or SaaS already has its accounts and data. The mobile app connects to it: approve a request, check a file, get an alert, without opening a computer.
Same accounts, same dataOpen →
Reading an NFC badge, talking to a sensor over Bluetooth, placing an object in augmented reality: when the heart of the app is the phone’s hardware, native is justified. We tell you so from the first conversation.
Suggested approach: native
Booking, checking, ordering a few times a year: a website that installs on the home screen is enough. No store, no commission, and content Google can index.
Suggested approach: PWA
What is included
The choice of approach first, written down and argued. Then everything the app needs to live on both stores.
Method
The typical timeline for a cross-platform app is 8 to 12 weeks, from the first meeting to release on the App Store and Google Play. Here is how they go.
01W1
What the app must do, for whom, on which phones. We decide between native, cross-platform, hybrid and PWA, with the reasons written down. One scope, one capped price.
02W2
The screens and flows drawn and approved together. Fixing a mockup costs a meeting; fixing a coded screen costs days.
03W3 → W8
Back end, accounts, screens, notifications, connections to your tools. A build to install on your phone at every sprint.
04W9
The flows replayed on both platforms, gaps fixed before submission to the stores.
05W10 →
Submission to the App Store and Google Play, release, handover of code and access. Thirty days of fixes, then optional care.
Technologies
The building blocks we use for your apps. Widespread, documented, and something another team can take over if you wish.
Budget
The indicative ranges from the comparison, approach by approach. The quote itself starts from your project.
Native
€40,000 → €80,000
Cross-platform · our default choice
€30,000 → €60,000
Hybrid (WebView)
€20,000 → €40,000
PWA
€10,000 → €25,000
Indicative ranges for a production app, back end included. The full cost breakdown is on our “How much does a mobile app cost” page. Free, capped quote within 24 hours.
At OTTOPILOTE
One codebase, iPhone and Android, half the budget and half the maintenance of native — for a result your users cannot tell from a native app.
Games, augmented reality, advanced hardware, deep system integration. We say so from the first conversation, because it costs more and you should know exactly why.
We say that too. Selling a native app to someone who does not need one means winning a project and losing a client.
The maximum price is known before we start: free, capped, within 24 hours.
Source code, access and documentation handed over at delivery, once the project is paid. You stay free to change provider or to evolve the app in-house.
An honest first read, an order of magnitude and the first risks. No slide deck, just a clear answer.
Frequently asked questions
Another question? Write to us: a human reply within one business day.
A native app is written in each platform's own language: two codebases, the best performance, the highest budget. A hybrid app is a website wrapped in a native shell: one codebase, the lowest budget, noticeably less fluid. A PWA is a website you can install straight from the browser, without going through the stores. In between sits cross-platform (Flutter, React Native): a single codebase with native rendering — the best compromise for most projects.
PWA first, then hybrid, then cross-platform, then native. But the quote is the wrong yardstick: what matters is the cost over three years. A native app costs roughly 30% more up front, and above all twice as much to evolve, since every change has to be made twice.
For occasional use — browsing, booking, ordering — yes, comfortably. For daily use that relies on notifications, background geolocation or specific hardware, no. The limit is not the quality of the PWA, it is what iOS allows it to do.
Yes, since iOS 16.4 — on one condition: the user must have added the PWA to their home screen through Safari's Share menu. As long as it stays an ordinary tab, no notification is possible. In practice very few users do this on their own, and that is the main limitation of PWAs on iPhone.
Both are mature and suit the majority of projects. React Native slots in naturally if your team already works in JavaScript or TypeScript. Flutter gives finer control over the interface and identical rendering on both platforms. The choice depends more on your existing ecosystem than on either being technically superior.
Yes, and it is often the right sequence. The PWA validates real usage at a lower cost. If the numbers follow, moving to cross-platform or native happens on a genuine base of data and a precise understanding of what your users actually do — instead of guessing up front.
Going further
Three reads to decide with the facts: what a mobile app really costs, what a first version should ship, and the full picture of custom development.
Real price ranges, hourly rates, hidden costs and a method to estimate your budget.
SaaS, web or mobile: what ships, what it costs, who owns the code, who maintains it.
Definition, real costs, ROI calculation and the steps of a project that lands.
Start
Describe the project in a few minutes. We come back with an honest first read, a ballpark and the first risks. No PowerPoint, just a clear answer.
OTTOPILOTE