Before you sign a mobile app quote, one question is worth more than any technical comparison: what exactly, in your situation, justifies a downloadable app rather than a site your customers can install on their home screen? If the only available answer is that an app looks more serious, the budget deserves a second pass.
Plenty of Moroccan SME owners hear the term PWA for the first time only after collecting two or three proposals above 200,000 MAD. Nobody mentioned it, partly because the option pays the vendor less, partly because it has genuine limits a salesperson would rather not spell out during a tender.
The criteria that actually decide this are few and fairly binary. Here they are, together with the ones that carry no weight despite their prominence in sales decks.
PWA, hybrid app, native app: three objects people mix up
A PWA (progressive web app) is a website. More precisely, an ordinary web application built in React, Vue or anything else, plus a service worker that caches pages and data, and a manifest file telling the phone how to install it. The user opens a URL, taps Add to Home Screen, and from then on an icon launches a full-screen interface with no address bar. Nothing is downloaded from a store. The acronym still rarely appears in Moroccan tender documents, which explains part of the confusion.
A hybrid or cross-platform app is a binary. Flutter and React Native compile one shared codebase into an iOS package and an Android package, with access to system APIs: sensors, secure storage, background tasks. The word hybrid still carries memories of Cordova and sluggish WebViews, but that is not what anyone means in 2026.
Native means Swift on Apple and Kotlin on Google, so two separate builds and often two skill sets. Picking between those last two families is a different discussion, covered in our comparison of native versus Flutter.
The mix-up gets expensive at pricing time, because all three land in the same “mobile app” column of a comparison table while the underlying workloads have almost nothing in common.
What a PWA can really do on iOS and Android in 2026
On Android, an installed PWA behaves close enough to an app. It opens from the home screen, shows up in the task switcher, works offline on cached content, reaches the camera, microphone, location and files, and receives push notifications.
On iOS the scope is narrower, though more usable than most people assume. Since iOS 16.4 Safari accepts web notifications, with one condition that keeps getting forgotten: the user must have added the site to the home screen and then granted permission. A visitor who stays inside the browser receives nothing at all. For sign-in, WebAuthn and passkeys let someone unlock an account with Face ID or a fingerprint instead of an SMS code.
The gaps are clear-cut. No Bluetooth and no NFC under Safari, so no badge reader, no connected scale, no contactless payment from the handset. No background geolocation either, which rules out a courier-tracking app that must report a position every two minutes with the phone in someone’s pocket. Deferred sync stays fragile on iOS, the local storage quota is modest, and the system can purge data after a long stretch of inactivity.
One upside gets consistently underrated: updates. You fix a bug, you deploy, everyone has the fix on next launch. No store review, nobody stuck on last year’s build.
The price gap, and what it actually buys
Rough market figures in Morocco, at comparable scope (catalogue, customer account, ordering, online payment, partial offline browsing): a serious PWA usually lands between 70,000 and 180,000 MAD, a Flutter or React Native app between 180,000 and 400,000 MAD, and native on both platforms above that. The ranges move mostly with integrations. An ERP or a point-of-sale system to connect shifts the total far more than the technology choice does. The line-by-line breakdown sits in our guide to mobile app development pricing in Morocco.
That gap is not inflated margin. It pays for two builds to maintain, two release pipelines, SDKs that change major version every year, testing across a device fleet, signing certificate management, and developer accounts (99 USD per year with Apple, 25 USD once with Google, public prices worth re-checking when you budget). On yearly upkeep, plan a percentage of the original project, not a token retainer.
A PWA does not remove maintenance, it reduces it to web maintenance: a server, a domain, a certificate, fixes and improvements. The same economics as any custom web application.
Push, payment, biometrics: where a PWA stops being enough
Web push does exist, it works, and it regularly disappoints marketing teams. Opt-in rates on Android are decent. On iOS you first have to convince the user to install the page on their home screen, something almost nobody does unless explicitly prompted. If your model depends on daily promotions or delivery alerts, that friction is a real commercial cost, and the downloadable app wins the argument.
Payment cuts the other way. A PWA collects money through your acquiring bank’s payment page without going through Apple or Google in-app purchases, so no platform commission on physical goods or on subscriptions sold outside the app. For e-commerce or B2B order taking, that matters.
Biometrics need splitting into two use cases. Opening a session with Face ID is something a PWA handles through passkeys. Signing a document, storing a key in the secure enclave, authorising an offline operation with a local code, encrypting an embedded database: that needs a binary.
Same reasoning for hardware. Continuous barcode scanning in a warehouse, reading an NFC card, printing to a Bluetooth printer, taking fifty geotagged photos on a site with no network. All of that is native or Flutter territory.
Store or browser: visibility, trust and commission
The “we need to be on the stores” argument deserves to be laid out flat. For a Moroccan SME unknown to the general public, App Store search brings almost no organic traffic. Installs come from your own channels: social media, SMS, in-store signage, word of mouth. You are paying for a shop window you will have to fill yourself.
What the store genuinely provides is a trust signal and an update channel your customers already understand. For a bank, an insurer, or any consumer app that moves money, that counts. For an internal tool used by thirty sales reps, it counts for nothing, and public listing even becomes a drawback.
Then there is process cost. Every release goes through review, with delays and the occasional rejection on grounds nobody anticipated, which we covered in our guide on publishing an app to the App Store and Play Store. Worth noting: a PWA can be wrapped and published on the Play Store through a Trusted Web Activity, giving you an Android listing cheaply. Apple remains far more reluctant to accept an app that is only a wrapped website.
One last point slips past most buyers: a PWA is indexable by Google, a native app is not. If your catalogue needs to turn up in search results, the web is not a fallback, it is the right medium.
Three questions that settle native app or PWA
First question: does your use case depend on a hardware capability? Bluetooth, NFC, background location, heavy scanning, encrypted local storage. One yes and the discussion is over, you need a binary.
Second question: how often does the same person come back? Several times a week, with a concrete benefit from the icon and from notifications, and the app earns its price. Twice a year to settle a bill or book an appointment, and the PWA does the job because nobody will ever install anything else.
Third question: what needs validating first, the technology or the product? When usage is still unproven, committing 300,000 MAD to two binaries before you have a hundred active users is a bet. A PWA delivered in six to ten weeks produces real usage numbers, and those numbers make the next native quote much easier to judge.
A practical detail for this market: read your own analytics before deciding. The iOS and Android split among your visitors, the share of slow connections, how many customers are on prepaid data. A 60 MB download does not carry the same adoption cost with every audience.
Frequently asked questions
Can a PWA send push notifications on iPhone?
Yes, since iOS 16.4, but only if the user added the site to their home screen and then accepted the permission prompt. While they browse in Safari, nothing is delivered. Budget for a real install-invitation flow, otherwise your push channel stays marginal on iPhone.
Can you publish a PWA on the Play Store?
Yes, by wrapping it in a Trusted Web Activity. The Play listing works normally and web content updates ship without a new submission. On Apple’s side, the minimum functionality rules make this considerably riskier, and a plain wrapped site is often rejected.
Does a PWA really work offline?
For reading, yes, on whatever the service worker cached. For writing it is narrower: an order entered without network can be queued, but how reliably it syncs depends on the operating system, particularly on iOS. For genuinely disconnected field work, use an installed app.
If we start with a PWA, do we rebuild everything to go native later?
Not the expensive parts. The API, the database, the business logic, authentication and integrations all carry over. What gets rebuilt is the interface and some client-side plumbing. That holds only if the backend was designed as a service rather than glued to the display layer.
Where to start without overpaying
Pick up the quote on your desk and look for the line that justifies a binary. If it is there (NFC, true offline use, push as a revenue channel, consumer-grade trust), the price is probably fair and the conversation should move to scope. If it is not there, ask for a priced PWA variant in writing, at identical functional scope. A provider comfortable with both options will answer without getting defensive.
At Arrowlancer this choice gets framed during the needs audit, before a line of code is written, and we then build what the analysis points to: a PWA, a Flutter or React Native app, or native where it is genuinely required. What we cover is listed on our services page. If you are holding a quote and doubting the technology behind it, tell us about your project. An hour of framing often prevents a six-figure commitment pointed the wrong way.