The three approaches, in plain terms
Once a business decides it wants an app, the first technical question is usually this one: native, hybrid or PWA? All three can sit on the home screen with your logo, but they are built differently. That affects what the app can do, where it is distributed and how much work it takes to maintain.
"Hybrid" is a confusing word. It used to mean a website wrapped inside an app. Today, when people say hybrid, they almost always mean cross-platform: one codebase that produces real apps for both iPhone and Android.
- Native: an app written in each platform’s official language, Swift for iPhone and Kotlin for Android. That means two separate projects, distributed through the App Store and Google Play.
- Cross-platform: a single codebase built with React Native or Flutter that compiles into an app for each platform. React Native uses the system’s own UI components; Flutter draws its own interface. These apps also ship through the stores.
- PWA (progressive web app): an app built with web technology and installed straight from the browser, no store required. It opens full screen, has a home screen icon and can work offline.
How the user experience differs
Native apps feel the smoothest and follow each platform’s conventions exactly: the back gesture, menus and animations are the ones users already know. That matters for heavy-use apps such as photo editors, games or navigation.
A well-built cross-platform app comes very close. In most business apps, such as ordering, booking or a customer portal, users will not notice the difference. What separates a good app from a bad one in these cases is the care that went into it, not the framework.
PWAs have an advantage people tend to underrate: access starts with a link. Customers open the URL, use the app in the browser right away and install it if they want, with no store account and no large download. On Android, the browser offers an install button. On iPhone, installation happens through the browser’s share menu, so you need a short on-screen hint explaining that step.
Camera, notifications, Bluetooth and other features
This is where many decisions get made. Browsers have gained a lot of capabilities, and several limitations repeated in older articles no longer apply. Others still do. Here is where things stand:
- Camera and photos: work in all three approaches. A PWA can open the camera, take pictures, upload images and scan QR codes.
- Push notifications: work on Android and, on iPhone since 2023, as long as the PWA has been added to the home screen. Native and cross-platform apps get them without that condition.
- Location: a PWA can read location while it is open. Tracking location in the background, as a delivery driver app does, requires a native or cross-platform app.
- Bluetooth and NFC: in the browser they only work in Chrome on Android, and Safari on iPhone does not support them. If your app talks to a scale, a printer or other hardware, go native or cross-platform.
- Background tasks, widgets and integration with Apple Health or Google Health Connect remain the territory of store apps.
Publishing and app store rules
Being on the App Store and Google Play adds credibility and a search channel inside the store. In exchange, you need a paid developer account on each store, every release goes through review and you follow each store’s rules. Apple in particular tends to reject apps that are just a website in a frame with no functionality of their own.
Payments are where most people get surprised. For physical goods and real-world services, like a meal, a haircut or a subscription box shipped to your door, the app can use your own payment provider. For digital content consumed inside the app, like courses, videos or features unlocked by a subscription, the stores generally require their own billing system and take a commission on the sale. These rules have exceptions, vary by country and have changed in recent years, so check your specific case before settling on a pricing model.
A PWA stays outside that system. There is no review, updates go live as soon as they are deployed and payments go through whatever provider you choose. The trade-off is giving up the store as a storefront.
Maintenance, timeline and relative cost
Native is the most expensive and slowest route, because you are building two apps with two codebases. Every new feature is built twice, and so is every fix. It pays off when performance or deep device access justify the investment.
Cross-platform cuts the effort considerably, since the same code serves both platforms. There is still store-specific work: configuration, reviews and operating system updates that require adjustments from time to time.
A PWA is usually the fastest to launch and the simplest to maintain: one codebase, one deployment, and the same system can act as both your website and your app. If you are validating an idea, that means reaching users sooner and spending less before you know what works.
Which one fits each type of business
In practice, the decision follows the use case. These are the ones we see most often:
- Booking (salons, clinics, studios): a PWA works very well. Customers book through a link, get reminder notifications once the app is installed and the business manages everything from a dashboard. Add an email or messaging reminder for customers who did not install it.
- Ordering (restaurants, delivery, cafes): a PWA is the most common choice. The link goes in your bio, on the menu and on the table QR code, and card payments are not tied to app store rules.
- Subscription clubs: it depends on what you sell. Subscriptions to physical products or in-person services work well as a PWA. Subscriptions to digital content inside a store app run into billing rules, which favors a PWA or calls for careful planning of the pricing model.
- Internal team apps: a PWA covers most cases, such as checklists, work orders, field photos and offline work, with no store involved. If operations need background location or Bluetooth hardware, go cross-platform.
- AI products: in most cases the model runs on the server and the app just sends and receives data, so a PWA or web app is enough. Native or cross-platform make sense when the AI must run on the device, process the camera feed in real time or work offline. Whatever the approach, AI API keys stay on the server, never inside the app.
Questions that settle the choice
Before talking technology, answer these questions. They rule out most of the options:
- Does the app need anything the browser cannot do, such as Bluetooth, background location or widgets?
- Does being in the app store matter to your audience, or will customers arrive through your website, social media and messaging?
- Are you selling physical goods, in-person services or digital content?
- Do you need to validate the idea quickly, or do you already have users who rely on the product every day?
- Who will maintain the app after launch, and how often will it change?
How BG Coding recommends a path
There is no approach that fits every project. There is the one that covers the features your app needs, the way customers reach it and the budget you have. Starting with a PWA and moving to a store app once usage justifies it is a common and sensible path.
At BG Coding, the recommendation comes out of the discovery phase. We learn about the business, the audience and the features required, and only then suggest whether the project works best as a PWA, with store publishing as an optional step, or calls for a cross-platform or native app. If you are weighing this decision, we can run that assessment with you.