Lesson 1 of 11 ·10 min read ·Reviewed 5 August 2026

1. The core distinction

A web app runs in the browser. You host it on a server, users reach it through a URL, and you control everything about how it deploys and updates. This site, endpoint51.com, is exactly this model.

A mobile app (the kind on Google Play or Apple's App Store) is installed on the user's device. It is packaged, signed, reviewed by the store, and updated on the user's schedule, not yours. The industry word for this kind of installed app is a native app; you will meet that term everywhere in mobile development, and this lesson uses it from here on.

One distinction matters from the start: installed does not automatically mean platform-native. An app you install from a store might be written directly for that platform (Swift, Kotlin), built with a cross-platform framework (Flutter, React Native), or built largely from web code inside a native container. The user installs all three the same way and cannot tell them apart from the icon.

And from the server's perspective, every one of them is an API client. A web app, an iPhone app, and an Android app can authenticate against the same backend and request the same resources. What changes between them is distribution, device access, storage, and release cycle, not the API behind them. That idea runs through this whole course.

2. Key differences at a glance

3. The middle ground: PWAs and wrappers

Web apps and native apps are not the only options. Several approaches let you reuse web technology while adding installation, app-store distribution, or deeper access to device features.

4. What fast food takeaways use, and why

Big chains (McDonald's, Burger King, Domino's, KFC) almost all run native store-distributed apps, usually built with a cross-platform framework, plus a web ordering site alongside. The reasoning maps directly onto the table above:

• Push notifications are the business model. "20% off today only" and loyalty nudges need reliable native push. This alone justifies the native app.
• Loyalty and habit. The home-screen icon, saved usual order, and points balance drive reorder frequency in a way a browser bookmark never will.
• The store tax does not hit them. Food is a physical good, so the 15–30% store cut on digital purchases does not apply. They process payments with their own provider (Stripe, Adyen) inside a store-distributed app and pay normal card rates. They get store distribution without the store tax.
• Location features. Store finders, geofenced offers, and order-ready timing all benefit from native location access.
• Their marketing links open the app. Offer emails and discount links use Android App Links / iOS Universal Links: ordinary https links that open the installed app directly at the offer, and fall back to the website when the app is not there. One link serves both halves of the funnel.
• The web version catches everyone else. First-time and low-commitment customers order in the browser with nothing to install; regulars get funnelled into the app where the loyalty flywheel lives.

Small independent takeaways

They typically build nothing themselves. Two common routes:

• Marketplace apps: list on Just Eat, Uber Eats, or Deliveroo. Zero build cost, but commissions run roughly 14–30% per order and the platform owns the customer relationship.
• White-label platforms: services like Flipdish (Irish), Storekit, or Slerp generate a branded app and ordering website for a monthly fee plus a small per-order cut. The takeaway keeps the customer data and pays far less per order than marketplace commission.

Many independents use both: marketplaces for discovery, their own white-label channel for repeat customers, often with a "order direct and save" incentive to shift regulars off the commission-heavy marketplaces.

5. What web-first software companies use, and why

Flip the example: Figma, Canva, Linear, and Basecamp all built their products web-first, and for desktop use most of them are web-only or close to it. Their reasoning reads like the same table with the weights reversed:

• Every user is on today's version. A fix or feature deploys to the server and reaches everyone on the next page load. No review queue, no waiting for users to update, no old client versions to keep supporting.
• A URL is the onboarding. Sharing a design or a project means sending a link; the recipient clicks and is inside the full product in seconds, with nothing to install. For collaboration software, that loop is the growth engine.
• The store tax would hit them. These are digital subscriptions, exactly the category the 15–30% cut applies to. Selling seats through their own web checkout at ~3% is the same margin calculus as the decision table below, made at company scale.
• The browser ceiling is higher than it looks. Figma runs a C++ rendering engine compiled to WebAssembly on a GPU-accelerated canvas, in a tab. Most dashboard-and-documents products never get near the sandbox's limits.

The desktop app that is secretly the web app

When these companies do ship a "desktop app" (Slack, VS Code, Figma), it is usually the same web code inside an Electron shell (or a lighter equivalent like Tauri): a native window, system tray, and global keyboard shortcuts around a product that stays one codebase. It is the wrapper move from section 3, pointed at the desktop instead of the app stores.

6. How to decide for your own product

7. Quick glossary

Reviewed 5 August 2026.