Short answer. The question is not “PWA or native” but “which one first”. For a customer, an installable web app: a WhatsApp or SMS link, open in three seconds, added to the Home Screen, offline for the essentials, CIB or Edahabia payment on the same web page, notifications on Android; it is in pilot by week 11. For a field employee who scans, follows a GPS, prints or works without network all day, a native app, Android first. Both share one API, and the web version is published on Play in a shell when a store presence matters: same code, one more listing. The App Store comes when iPhone customers justify it, not before.
This guide is for the founder settled in France who wants “an app like in France”, the wholesaler opening an ordering portal, the practice or hotel that wants bookings, the chain of shops that wants a customer space, and the distributor equipping its pre-sellers. It does not compare frameworks; it compares two ways of reaching the customer’s and the employee’s phone, and says which ships first.
What the figures say
The Algerian phone is an Android, often an old one. According to StatCounter, 89.3 % of phones measured in Algeria in August 2026 run Android and 10.7 % iOS; it is a web-traffic measure, not an installed base, but the order of magnitude does not change month to month. In October 2026 the same observatory splits the measured Androids as follows: 21.3 % on version 16, 17.4 % on 15, 17.7 % on 14, 13.4 % on 13, 8.2 % on 12, 9.8 % on 11, and about 12 % older still: close to 43 % of Androids run version 13 or older, phones from 2022 or before, often with full memory. A recent native app that requires a recent version loses them; a heavy web app does too.
The iPhone has its rules, written by WebKit. Since iOS 16.4, announced on 16 February 2023, a web app added to the Home Screen can receive push notifications and show a badge, provided permission is requested after a user gesture; a site open in Safari cannot. And since 2020, Safari deletes all of a site’s storage, IndexedDB, localStorage and service workers included, after seven days of Safari use without interaction with that site; WebKit states that apps added to the Home Screen have their own counter and are not expected to lose their data. Secondary sources report that iOS 18.4 added declarative push and that iOS 26 opens Home Screen sites as apps by default; we did not verify them against Apple’s notes. What this imposes: on iPhone, a web app that means to keep anything must be installed, and the screen inviting it is part of the product.
The stores have their requirements and their price. An Apple developer account costs 99 dollars a year and a Google Play account 25 dollars once; Google imposes every year a target Android version for new apps and their updates, and a personal Play account must have the app tested by twelve people for fourteen days before publishing, as the guide on what a year of app costs details. None of this is an obstacle; it is a few weeks of delay and a review, which the installable web app does not have. With 51.63 million 4G and 5G subscriptions in the second quarter of 2026 according to the ARPCE, the link that opens in three seconds reaches more customers than a store listing.
Six questions that decide, in this order
The choice is not made on technology but on six questions asked in order, and the first two settle almost everything.
Who opens it, and how often. A customer who orders twice a month, books once a year or checks receipts now and then does not deserve thirty seconds of installation; they deserve a link. An employee who opens the app forty times a day deserves a shortcut, an instant start and an app that survives a day without network. What the phone must do. Taking a photo and giving a one-off position, the web does; following a GPS continuously, talking to a thermal printer over Bluetooth, reading an NFC card, running in the background, working eight hours offline with thousands of lines, that is native. Every “yes” to this question weighs towards the right column. How it is found. If a salesperson, a pre-seller or a receptionist sends the link, discovery is done and the store adds nothing; if the customer searches “hotel booking Oran” in a store, the listing matters.
Notifications. On Android, the installed web app notifies after consent; on iPhone, only once added to the Home Screen, and only after a tap by the customer. For a booking reminder, SMS and WhatsApp do the job with nothing installed; for a product that lives on its notifications, native on iPhone is required. Payment and trust. The CIB or Edahabia payment page is a web page in both cases, as the technical guide on SATIM integration describes; the difference is trust: a store listing with reviews reassures some customers, and that is a valid reason to publish the web version on Play in a shell. The decision is then written in one line, before the specification: installable web first, native for the field, stores when the third or fifth question asks for them.
One product, three faces, one base
Doing both does not mean paying twice: a product reads in five layers, and the two faces share the other three.
The API is the only place where rules, prices, accounts, orders and payments live; neither face knows them other than by asking it. That is what makes the faces interchangeable and what makes a price change happen once. The installable web face serves customers: opened from a link, it offers the Home Screen add at the right moment, after a first successful order rather than on arrival; it keeps the catalogue, basket and last orders offline; it pays on the bank’s web page. Published on Play in a shell, it also becomes a store listing with the same code. The native face serves the field and the hardware: code scanning, continuous GPS, time-stamped photos, Bluetooth printing, a whole day offline with deferred sync; Android first because it is the teams’ phone, iOS if the team has it.
Channels are the part forgotten in the “PWA or native” question: the deep link sent by WhatsApp or SMS opens the right face at the right place, the QR on the counter opens the customer space, the store listing opens the shell, and the AI agent answers in WhatsApp with no app open at all, as the guide on the B2B ordering portal describes. Management reads usage per face and per channel: how many added to the Home Screen, how many open from the Play shell, which Android version crashes; it is what says, in September, whether the App Store is worth its 99 dollars and its review.
«The question is not “PWA or native”, but “which one first”.»
What Algerian phones say
Four figures are enough to frame the decision for 2027, and two of them are not assumptions.
89 % Android means an “iOS first” native app, as one would make for a Parisian audience, speaks to one customer in ten; it also means the Play shell, which costs only a listing, covers almost the whole base. Close to 43 % on Android 13 or older means the app, web or native, must start fast, weigh little and tolerate a full memory; a native app requiring Android 14 for an accessory feature loses four customers in ten, and a web app loading three megabytes of scripts at every open loses them too. Safari’s seven-day rule is not an assumption: an iPhone customer who opens the web app in Safari and does not return for a week finds it empty; the Home Screen invitation exists for them, and that is why it appears after the first order, when they have a reason to say yes.
One base is the consequence of the other three: the installable web app, its Play version in a shell and the customer space are the same code; native is added only for the field screens, which are few and different. What this changes for budget and timeline: the web face is in pilot by week 11, and the decision on native iOS is taken in September with usage figures, not in January with an intuition. The assumptions to check at home: the real share of iPhones among your customers, readable in your current site’s or Facebook page’s statistics, and the share of your field employees who need the phone’s hardware.
Installable web app or native: the matrix
Six criteria, and for each what each option really does in 2027, with no marketing promise on either side.
Installation is the criterion that decides for customers: three seconds and no account on one side, a download of several tens of megabytes and a Google or Apple account on the other, on phones whose memory is full. Notifications and offline decide for iPhone and for the field: the web notifies on Android and, on iPhone, only once installed; it keeps the essentials offline but not a working day. Hardware is the criterion without compromise: continuous GPS, Bluetooth, NFC, printer and background belong to native, and a web app that promises them breaks on pilot day. Payment is identical: the bank’s page is web in both cases, and no store takes a commission on physical goods or services rendered outside the app. Updates explain the shipping order: the web face deploys once with no review; the native face waits for Apple, the year’s Android target and, for a personal account, twelve testers for fourteen days.
The matrix also says what not to do: build in native what an occasional customer opens twice a month, and build in web what an employee uses with the phone’s hardware. Cross-platform frameworks, described in the Flutter guide and the React Native guide, serve the native face when one is needed on both systems; they do not replace the decision.
«Native is not superior to web; it is necessary elsewhere.»
Six products, what gets built first
Six products we often build for Algeria, and for each the face that ships first.
The ordering portal for retailers and booking ship as installable web: the link is sent by the pre-seller or the receptionist, the typical basket and the calendar fit in a page, payment is web; the Play shell comes next for the listing, reorder notifications after the Home Screen add. The customer, owner or patient space too: documents, receipts, reminders by SMS and WhatsApp, and an “add to Home Screen” button after first use; the guide on the flat managed from France and the one on wedding halls describe these spaces.
The pre-seller, the driver and the field agent ship as native Android, for the reasons of the second question: scanning, GPS, photos, a day offline, as the pre-sale guide describes. The till is native or web on a tablet, depending on the scanner and printer, and always offline, as the guide on tills and QR payment describes. The consumer product that grows through the stores is the only case where native on both systems is justified from the start, and it is also the case where the guide on marketplace versus own-brand app asks the prior question. If you sell on Instagram and wonder whether you need an app, the answer is most often no, and this guide says which one when it is yes.
Publishing the web version on the stores without a second code base
A store presence is often justified for trust and discovery, rarely for technology. On Android, an installable web app is published on Play in a shell known as a trusted web activity, which opens the site in the phone’s browser without an address bar; it is the same code, the same instant update, and a store listing with reviews. Google requires the site to be fast and installable, and applies to the shell the same rules as to other apps, Android target included. On iPhone, the shell is a web view inside a minimal native app, which Apple accepts when the app brings more than a site; in practice it is reserved for the moment iPhone customers are numerous enough for native notifications to matter.
Three rules hold it together. The web version stays the reference: the shell contains no logic, and a bug is fixed once. The deep link opens the right face: a customer who installed the shell receives the same WhatsApp link as another, and the phone chooses. Store accounts are in the company’s name, never the vendor’s, as the guide on the app stuck with a vanished developer recalls; a Play shell published from a vendor’s account is an app whose key you do not hold.
The 2027 calendar
The calendar is that of a two-face release: the web face during Ramadan, expected from 8 February to 9 March 2027, the native face afterwards if the second question requires it.
January answers the six questions and writes the decision in one line in the specification, whose dedicated guide gives the nine-page form. Ramadan builds the API and the installable web app, launching nothing. Week 11 puts the web face in pilot with fifty real users, through a WhatsApp link, and measures what matters: how many open, how many add to the Home Screen, how many order, on which phones. Weeks 14 to 22 build the field’s native face if the second question requires it, Android first; otherwise they serve the web’s second version. Weeks 22 to 26 publish the Play shell, then the App Store if the pilot’s figures justify it, counting the account, the testers and the review. Summer is for notifications, the AI agent in WhatsApp and measurement; September decides on native iOS with figures. A native app alone would not be in pilot before week 20; that is the gap the guide on real lead times details by project type. Ramadan dates are forecasts.
What makes the choice fail
The projects we see fail on this question almost always fail for one of these reasons.
- Starting with both stores. Two accounts, two listings, a review, and a customer who will not download thirty megabytes to order once.
- Promising in web what only native does. Continuous GPS, Bluetooth, NFC, printer: the web app falls over on pilot day and the project with it.
- Forgetting the install invitation on iPhone. Without the Home Screen add, Safari wipes everything after seven days and the customer starts from zero.
- Requiring a recent Android. Four phones in ten run Android 13 or older; a target version too high or a heavy start excludes them.
- Putting logic in the shell. The Play shell is only a door; as soon as it decides anything, there are two codes and two bugs.
- Publishing from the vendor’s account. The listing, the reviews and the signing key are theirs; getting them back costs months.
- Deciding native iOS in January. It is decided in September, with the real iPhone share measured during the pilot.
Frequently asked questions
The questions we receive from founders, wholesalers, clinics and chains of shops on this choice.
- Is an installable web app a “real” app?
- For the customer, yes: an icon on the Home Screen, a start without an address bar, the essentials offline, notifications on Android and, once installed, on iPhone. For the developer, it is a fast website with a manifest and a service worker, deployed once, with no review. What it does not do is in the matrix: continuous GPS, Bluetooth, NFC, printer, background.
- Will Algerian customers install a web app?
- They open a link; installation comes afterwards, when it is offered at the right moment, after a first successful order or booking. On Android the prompt is native to the browser; on iPhone it is a screen showing the two taps. The week-11 pilot measures the share that installs, and that figure decides what comes next.
- What if my customers are mostly on iPhone?
- Check it first in your site’s or page’s statistics: in Algeria one measured phone in ten is an iPhone, but some customer bases have far more. If that is your case, the installable web app remains the first face, with the Home Screen invitation, and native iOS is decided in September on the real share and the need for notifications.
- How much does a store presence cost?
- An Apple account at 99 dollars a year, a Google account at 25 dollars once, then time: the Play shell is published in a few days once the site is ready, the App Store requires a review and sometimes a back-and-forth. The stores take no commission on physical goods or services rendered outside the app. The real cost is the delay, not the invoice.
- Do we need Flutter or React Native for the native face?
- When the native face must exist on both systems, either avoids two teams; when it exists only on Android for the field, native Android or Flutter is enough. The framework choice comes after the six questions, not before, and it changes nothing for the web face.
- Can we start in web and go native later?
- Yes, and that is the normal path: the API does not change, the web face keeps serving customers, and the native face is added for the field or for iPhone when the figures ask for it. What cannot be recovered is the opposite: a native app built for customers who do not install it.