You probably searched a broad phrase like this because you have a product in mind and you aren’t yet sure what it should run on. That’s a reasonable place to be, and it’s poorly served by what the search returns. Nearly everything written for this term answers a later question: which vendor to hire, what a build costs, whether to staff it in-house or send the work out. Those are fair questions to get to eventually, but the pages asking them have already assumed you decided your product belongs in a browser.

Two of the pages ranking for this search show the pattern. ScienceSoft’s web development page opens with scale: 4,300+ projects and 500+ developers behind ISO 9001 and 27001 certifications. Below that it lists portals, websites, ecommerce, and web applications as one undifferentiated menu, aimed in the same breath at enterprises, mid-market companies across 30+ industries, and startups building an MVP. DEV.co runs the same play with different numbers, leading with over a decade in business, hundreds of websites shipped, a 24-hour response guarantee, and a row of industry name-drops. Neither page helps you work out whether your product belongs in a browser, and neither one could, because the answer turns on facts about your users that a services page has no way to know in advance.

So this is the piece we’d want if we were the ones buying: what the browser buys you, what it costs you, where a Progressive Web App narrows the gap in 2026 and where it still doesn’t, and two products we built that landed on opposite sides of the same question.

The browser’s advantages come down to friction and speed, and they’re bigger in practice than they look on a feature list.

Start with the fact that nobody installs anything. A user clicks a link and they’re working, whether that’s on a laptop their employer issued, a Chromebook in a classroom, a borrowed phone, or a machine they have no permission to install software on. If the people you’re building for are occasional users, or spread across organizations whose devices you don’t control, that one property outweighs everything else in this comparison.

You also ship on your own schedule. Fix something on a Tuesday and every user has the fix on Tuesday, because there’s no queue in front of you, no reviewer, and no slice of your audience sitting on a months-old version because they turned automatic updates off.

Then there’s discovery: someone can go from a search result to using your product in a single click, with no store listing in between, which matters for products people find by searching. And you keep one codebase while you do it, since a single deployment serves Windows, macOS, Android, iOS, and whatever hardware a customer’s IT department standardizes on next year.

This is the part the agency pages skip, so we’ll be specific. Nearly all of the constraints below trace back to one thing: what Apple currently permits a web app to do on iOS. Android is more permissive, so your iPhone users set the ceiling for everybody.

Push notifications are conditional. Web Push has worked on iOS since 16.4, but only after the user adds your app to their home screen, and that’s a step most people never take and you can’t take for them. In the EU it’s harder still, because under DMA rules PWAs open in Safari tabs there and push doesn’t work at all. If notifications are the mechanism your product runs on, the browser is a shaky foundation for it.

Background work is the bigger gap. Background Sync, Periodic Background Sync, and Background Fetch are all unsupported on iOS, with no announced timeline for changing that, so a web app on an iPhone can’t reliably finish an upload after the user closes the tab, refresh its data before the user opens it, or hold a write made offline and send it once the signal comes back. For a product used at a desk on a stable connection, none of that matters much. For one used in a warehouse, a truck, a basement, or a construction site, it’s most of the job.

Offline storage runs into a similar wall. Safari holds a web app’s offline cache to roughly 50MB and clears it after seven days of disuse, against hundreds of megabytes and no comparable expiry on Chrome, so if your product has to keep a working set of data on the device and still have it there when somebody opens the app three weeks later, you’ll reach that ceiling early.

Direct hardware access mostly isn’t available either: Web Bluetooth, Web NFC, and Web USB are unsupported on iOS, and so are the biometric APIs. A product that pairs with a device, taps a card, reads a sensor, or unlocks with a fingerprint needs a native app to do any of that on an iPhone.

There’s a commercial cost as well. An app store is a discovery channel, and staying out of one means giving up the users who look for software by browsing a store instead of searching the web, which may be most of your market or almost none of it depending on who you sell to.

Native buys back every constraint above and charges for them on a different line.

You maintain more codebases, for one. iOS and Android are separate platforms with separate languages and separate release processes, so unless you pick a cross-platform framework and accept its own compromises, you’re funding two builds of every feature indefinitely, plus a web presence anyway.

Every release also goes through a reviewer, which means work that’s finished in your repository reaches nobody until a store approves it, on a schedule set by a company that has no contract with you.

Less obvious is that the platforms change your app whether you asked or not. Apple and Google each ship a major operating-system release every year, and those releases regularly alter the behavior of apps that are already live, retire components those apps depend on, and add requirements with deadlines you didn’t pick. Somebody has to read the release notes, work out which parts touch your product, and get the work scheduled before your users get the update. We wrote that ownership question up in detail in what happens after the App Store approves your app, so the specifics live there.

A Progressive Web App is a web app that installs to a home screen, runs in its own window without browser chrome, and can work offline through a service worker. It’s the middle path, and by 2026 it fits more products than it did a few years ago.

It closes the install and icon problem, since users get a launcher on their home screen the same as any app, and it handles basic offline reading. On iOS it also gets you push notifications, once the app is installed and the user is outside the EU. For a product whose users sit at a desk or carry a phone with decent signal, a well-built PWA can be hard to tell apart from native across most of what those users do in a day.

What it doesn’t close is the list in the previous section. Background sync still doesn’t run on iOS, the offline cache still has a ceiling and an expiration date, and Bluetooth, NFC, USB, and biometrics still aren’t reachable from a web app there. So treat a PWA as a fix for installation and casual offline use, and don’t count on it as a route around the iOS background and hardware limits.

We’ve built both kinds, for clients whose circumstances pointed in opposite directions.

BIP Visualized is web-only, deliberately. It’s a platform where behavior experts build visual behavior intervention plans and then get those plans into the hands of the teachers, staff, and families who have to carry them out. The people on the receiving end are classroom teachers and parents with no technical training, working inside schools and agencies whose devices we don’t control and frequently can’t install software on. Asking them to find a store listing, create an account with a platform, and install an app would have lost a lot of them before they ever opened a plan. We built it on Ruby on Rails and PostgreSQL with Redis and Sidekiq handling background work, launched the MVP in five months, and it now serves thousands of users who have created more than 8,000 visual plans. An expert builds one in under 30 minutes, which is 78% faster than the written plans it replaced, teachers report a 90% increase in confidence implementing the strategies inside them, and none of it required an app store.

Sunscreen went the other way, for reasons that were just as concrete. It’s a quality-assurance system for utility-scale solar construction, built for Swinerton Renewable Energy alongside the agency The Engine is Red, and it replaced a paper process spanning tens of thousands of components per project. The inspections are done by field crews walking a job site with an iPad in hand, while the people who need a live view of progress are office staff at a desk. Those two groups needed different things from a device, so the product is an iPad app for the field and a web interface for the office, both running on one Rails backend and API that we built and still own. The iOS app itself was built by a separate contractor against that API, which turned the API into a contract between two teams.

Six questions, answered honestly about your own product, and the platform usually picks itself.

Who uses it, and where are they standing? Desk workers on a stable connection live comfortably in a browser, while people in a field, a vehicle, a plant, or anywhere the signal drops need more than the browser currently gives them on iOS.

Does it have to work offline, and does it have to write offline? Reading cached data while disconnected is something a PWA handles. Capturing data while disconnected and trusting it to arrive later is where iOS stops cooperating.

Does it need direct hardware access? Bluetooth, NFC, USB, and biometric unlock aren’t reachable from a web app on an iPhone, so a product depending on any of them needs a native app for its iOS users.

Do notifications have to land? If a reminder arriving reliably is how your product works, weigh the home-screen install requirement and the EU gap carefully before you commit to the browser. If notifications are a pleasant extra, don’t let them drive this decision.

How do people find you? Search favors the browser and store browsing favors native, which in practice means most B2B products lean web, while plenty of consumer products are still discovered in a store.

How fast do you need to change it? If you expect to iterate weekly for the next year, a review queue sitting in front of every release is a real tax on that plan.

Work through those and you’ll land in one of three places: clearly browser, clearly native, or the hybrid shape where different users get different front ends over one shared backend.

Before you talk to anybody, write down two things: the single workflow your first release has to handle end to end, and where the people doing that workflow will be standing when they use it. The second one is what settles the platform, so bring it along even if nobody asks you for it.

If the filter points you at the browser, custom web based application development picks up from there and covers what drives the cost, when building is the wrong call, and what to ask a development partner before you sign anything. If it points at native or hybrid, what happens after the App Store approves your app covers what owning a shipped app requires once it’s live.

And if you’d rather talk it through with someone, book an intro call and bring those two sentences with you. We build browser-based products on Ruby on Rails and PostgreSQL, and we’ve built the backends that native apps run on, so we can tell you which side of this your product lands on before anybody writes a proposal.