PWA and Telegram Mini Apps: mobile without the app stores
A catalog, a booking flow, or a request form rarely needs an app-store cycle. One codebase can live as a PWA and a Telegram Mini App.
App stores are a product strategy, not a default. For a catalog, a booking flow, or a request form, a native binary is often the expensive way to put an icon on a phone. A Progressive Web App and a Telegram Mini App can share one implementation, sit on the home screen, and take a payment you can name.
This is not a claim that native is dead. It is a claim that most service businesses do not need two codebases and a review queue to take an order.
Why the store is a bad default
A dual native MVP (Swift and Kotlin) is a multi-month programme with two teams and a QA loop that never quite ends. Each OS release reopens certificates, privacy prompts, and store policy. Annual upkeep of two trees routinely eats a large fraction of the original build.
The download funnel is the quieter tax. A person who clicked an ad is asked to open a store, free 150 MB, wait, then pass an SMS gate. Each step sheds a slice of the audience. First purchase from that path is a low-single-digit conversion in a lot of retail and booking work.
SMS as a login and a status channel is a recurring operator bill. Web Push and a messenger thread are not.
Store review is a single point of removal. A listing that took a year to grow can disappear on a policy change the operator did not write. A PWA you host, and a Mini App on your bot, do not have that particular kill switch.
What the two surfaces actually are
| Native (iOS / Android) | Telegram Mini App | PWA | |
|---|---|---|---|
| Stack | Two native trees | One web stack (e.g. TypeScript) | Same web stack |
| Distribution | App Store, Google Play | Inside the messenger | Safari, Chrome, Edge |
| Install | 100–250 MB download | One tap, no extra binary | “Add to Home Screen” (a few MB) |
| Removal risk | Reviewer decision | Your bot, your server | Your origin |
| Auth | SMS / store account | Telegram identity | WebAuthn, passkeys, magic link |
| Payments | Store cut 15–30% on digital | Stripe, cards, Stars where they fit | Stripe, cards |
| Push | APNs / FCM | Bot messages | Web Push (iOS 16.4+ once installed) |
A Telegram Mini App is a full web app inside the chat window. The official WebApp SDK hands over a profile (name, id, language) without a registration form, drives the native MainButton and theme, and can take a haptic tap. Payments are Stripe, cards, or Telegram Stars where the product is actually a digital good in that channel — not a local instant-payment brand pasted on for show.
A PWA is the same site, promoted. From the home screen it opens standalone: no browser chrome. A service worker caches the shell and the catalog. On a weak 3G or a brief drop, the last useful screen is still there.
WhatsApp remains a capture and notify channel (official Business API) even when the interactive surface is Telegram plus PWA. The two messengers are complements, not a religious choice.
Web Push on iPhone
The old native argument was “Safari cannot push.” From iOS 16.4, Web Push is available to sites installed as a PWA. Delivery, booking reminders, a bonus credit, an abandoned-cart nudge can sit on the lock screen and on an Apple Watch without an SMS tariff.
The constraint belongs in the brief: the visitor must have added the icon. A random Safari tab does not get the same privilege. Telegram bot messages cover the people who will never install anything.
One backend, two doors
The useful architecture is not two sites. It is one API and one inventory:
- Opened inside Telegram: WebApp SDK,
initDatachecked cryptographically, Telegram type and colour. - Opened in Safari or Chrome: service worker,
manifest.json, a quiet offer to add the icon.
Catalog, stock, pricing, promo codes, and the CRM hook stay singular. A delivery rule changes once.
ERP and inventory are named in the brief. A disconnected demo with a fake warehouse is not a Mini App.
Where it fits
Local delivery and small retail. A tap from a channel post or a QR on the pack. Filters, modifiers, address and phone filled from the profile, pay with Stripe or a card, a bot message with the order number and a window.
Clinics, workshops, studios. No-show is a revenue hole. An interactive calendar in the Mini App; reminders at 24 hours and at 2 hours with confirm / move / cancel; a cancel returns the slot before the chair goes empty.
B2B and dealer cabinets. A foreman on a site does not open a laptop. Wholesale prices for that account, live stock, a camera on a barcode, “raise an invoice.” The accounting system reserves and bills. The PWA is the field client.
When native is still the tool
Honesty about the edge:
- Heavy 3D (Unreal, Unity) wants Metal or Vulkan, not a web canvas pretending.
- All-day background GPS with the screen off (drivers, couriers on an eight-hour shift). Browsers throttle background work on purpose.
- Sleep-mode Bluetooth to a holter, a band, or a sensor that must keep a packet stream while the phone is in a pocket.
If the job is to sell, book, run loyalty, take a card, or take a request — PWA and Mini Apps are the shorter path, on one codebase, without an app-store cycle.
A first channel, then the second on the same code, is how the work is scoped. Request a scope with the inventory system and the payment rails named.
- Is the job a catalog, a booking, or a request — or a 3D game, all-day GPS, or sleep-mode Bluetooth?
- Do PWA and Mini App share one backend, one inventory, one price list?
- Are payments named (Stripe, cards, Telegram Stars) without a store cut as the default?
- Is Web Push available on iOS only after the PWA is on the home screen — and is that in the brief?