What If We Have the PWA Question Backwards? The Future of Web vs. Apps

When you look up Progressive Web Apps, you often see the same list of features.

• They can feel like native apps.
• They can launch from the home screen.
• They can send push notifications.
• They can work offline.
• They can run in standalone mode without the usual browser UI.

None of that is wrong.

And for a long time, the evolution of PWA has been discussed from one particular direction:

How close can the Web get to a native app?

A website that behaves like an app.

A browser-based service that launches from the home screen.

Something that can work without a network connection and even send notifications.

In other words, the native app is treated as the finished form, and the Web keeps moving closer to that experience.

But after spending a lot of time testing PWAs in 2026, I have started looking at the question differently.

Does the Web actually need to become a native app?

Now that PWAs have matured, reversing the question reveals something much more interesting.

Can an app be discovered and used as freely as the Web?

The Web already has strengths that apps do not

When we compare the Web with native apps, we tend to focus on what the Web is missing.

But try reversing that comparison. The Web has several characteristics that native apps do not naturally have.

• Every page can have a URL.
• It can be discovered through search engines.
• A specific page can be shared with a link.
• You can use it before installing anything.
• It works across operating systems.
• Users do not need to manually update it every time the service changes.
• If they no longer need it, there may be nothing to uninstall.

These things are so normal that we barely notice them.

But they are incredibly powerful.

Imagine you need a small utility.

With a native app, the usual flow is to find it in an app store, check its listing, install it, open it, and only then find out whether it is actually useful.

On the Web, you can open a search result and start using the tool immediately.

There is almost no preparation required before use.

And if that page can be added to the home screen as a PWA, you can decide to keep it there after you already know it is useful.

That creates a very different order of events from the traditional native app model.

From “install, then use” to “use, then keep”

A traditional native app experience roughly looks like this:

Discover
↓
Go to the App Store / Google Play
↓
Install
↓
Launch
↓
Try it
↓
Decide whether you need it

In many cases, you have to make the installation decision before you have actually used the product.

The Web works in almost the opposite order.

Search
↓
Open the page
↓
Use it immediately
↓
Decide whether you need it
↓
If you like it, keep it on your home screen

You use it first.

Only at the end do you decide whether it deserves to stay.

I think this distinction is extremely important when thinking about PWAs.

If we define a PWA simply as an “installable website,” we naturally start trying to imitate the native app installation experience.

But if we preserve the natural flow of the Web, a different model appears:

Instead of installing something so you can use it, you use it first and keep it because it proved useful.

That feels much more native to the Web.

This is also why I think the value of a PWA can be much simpler than the usual feature checklist. I explored that idea further in What Are the Benefits of PWA? Why “Being on the Home Screen” Is Enough in 2026.

OJapp Tips — Recommended Reading
What I Learned by Using a Nonexistent URL: iPhone’s Hidden Home Screen Icon Behavior

Could Google Search become an app store?

Take this idea one step further and an interesting future starts to appear.

If you can discover a Web service through search, use it immediately, add it to your home screen if you like it, and then launch it as a standalone app from that point on, there is a question worth asking:

Does app discovery really have to happen inside an app store?

Search engines such as Google already provide a massive discovery system for the world’s Web pages.

If the things appearing in search results are not merely “pages,” but usable tools and services that can later be kept on the home screen, then search itself starts to become a place where people discover apps.

Search = Discovery
Web = App
Home Screen = Library

Discover it through search.

Use it directly on the Web.

Keep only the things you like on your home screen.

That entire flow can happen without an app store ever appearing.

Does that mean the App Store will disappear?

I do not think so.

Native apps have areas where being native is a genuine advantage.

Games, advanced video and audio processing, deep integration with device capabilities, and software handling large amounts of local data are obvious examples.

There is also real value in having a structured system for review, distribution, payments, and software updates.

So I do not expect everything to move to the Web.

Instead, I think the role of app stores may simply become clearer.

Much like Steam for PC games, there is lasting value in being a place to discover, purchase, install, and manage installed software.

But not every service necessarily needs to go through that system.

Does your service really need to be in an app store?

A booking service.

A store membership page.

A small calculator.

A blog or news site.

An online store.

An event page.

A dashboard.

A small Web tool you use every day.

Do all of these really need a native app, an app store review process, and an installation step before users can access them?

For some services, building a native app absolutely makes sense.

But if the only reason is:

“We want people to use our service like an app.”

Then that assumption becomes weaker as PWAs mature.

What users actually need may not be a native app at all. They may simply need an easy way to return to the service.

A PWA does not have to be a substitute for a native app

The way we think about PWA changes once we look at it from this perspective.

The traditional mental model often looks something like this:

Native App
↑
PWA
↑
Web

The native app sits at the top as the final form, while the Web gradually climbs toward it.

But the Web has strengths of its own.

So perhaps PWA should not be seen only as:

“Technology that makes the Web more like a native app.”

It can also be seen as:

“Technology that keeps the strengths of the Web while borrowing the useful parts of apps.”

Do not give up searchability.

Do not give up URLs.

Do not give up direct links.

Do not give up the ability to use something before installing it.

Then add the ability to launch from the home screen.

Add standalone display.

Use Service Workers, push notifications, or other PWA features when they are actually useful.

In other words:

Do not turn the Web into an app. Keep it as the Web, while giving it the useful qualities of an app.

That is where I think PWA becomes much more interesting. It is also why I no longer think of PWA design as a single fixed pattern. 1S1A and 1P1A represent two different ways to decide what should count as one app.

You may not even need to turn the entire site into one app

If we push this Web-first idea further, even the assumption that “one website should become one app” stops being absolute.

The Web has always been discovered page by page.

A Google search does not necessarily send you to a site’s home page.

Search for an article and you land directly on the article.

Search for a product and you land directly on the product page.

Search for a tool and you land directly on the tool.

So if an individual page already has enough meaning on its own:

Why not keep that page itself on the home screen?

I call this design approach 1P1A — One Page. One App.

It is a PWA design philosophy that treats one page as one app.

If the conventional site-wide model is 1S1A — One Site. One App. — then 1P1A creates independent home screen entry points for individual pages. :contentReference[oaicite:0]{index=0}

The important part is not “creating lots of apps.”

It is extending the Web’s existing page-level discoverability all the way to the home screen.

If you want the deeper technical and design explanation, I wrote about it in The PWA Design Philosophy of 1P1A (One Page. One App.).

Find a page through search, then take it home

Imagine finding a useful Web tool through search.

The site might contain 100 different tools.

But perhaps you only want to use one of them every day.

In that case, rather than putting the entire website on your home screen as one app, it may be more natural to keep only that specific tool.

Next time, you tap its icon and launch directly into that tool.

This is an experience that is slightly awkward to reproduce with the traditional native app model.

With native apps, you normally install a large container first and then navigate inside it to find the feature you want.

The Web can take you directly to the destination from the beginning.

And PWA can preserve that destination as a home screen entry point.

Google Search
↓
Discover the page you need
↓
Use it immediately
↓
Decide you like it
↓
Add that page to the home screen
↓
Launch it directly with one tap next time

This does not feel like “the Web getting closer to a native app.”

It feels more like an app experience that is possible precisely because it started on the Web.

A page on the Web, an app on the home screen

When thinking about PWAs, we may no longer need to choose between “Web” and “App” as two separate categories.

When someone arrives from a search engine, it can simply behave like a normal Web page.

When someone shares the URL, it can open as a normal link.

There is no need to demand installation from a first-time visitor.

But when someone finds the page useful enough to add it to their home screen, the next visit can feel like opening an app.

Discovered as a page on the Web. Used as an app from the home screen.

The same content can play different roles depending on where the user chooses to access it.

I think this boundary will continue to become less important.

The Web does not have to catch up with apps. It can take another path.

When we watch PWA evolve, it is tempting to keep asking what feature is still missing before it finally becomes equivalent to a native app.

But perhaps complete equivalence is unnecessary.

The Web has its strengths.

Apps have theirs.

As PWA makes the boundary between them thinner, the best path for the Web may not be to perfectly copy native apps. It may be to push the Web’s existing strengths even further.

For years, the PWA question has been:

How far can the Web become an app?

But now I think we also need to ask the reverse:

Can an app be discovered and used as freely as the Web?

The Web is searchable.

It is linkable.

You can use it before installing anything.

And you can keep only the things you actually need on your home screen.

These are not “Web features that native apps are missing.”

They are strengths the Web has had from the beginning.

PWA may not be technology for abandoning those strengths in order to become an app.

It may be technology for carrying those strengths into territory that once belonged almost entirely to apps.

Conclusion

For a long time, PWA has been discussed through the question of how closely the Web can approach the native app experience.

But now that Web experiences can launch from the home screen, run standalone, and optionally support features such as offline access and notifications, there is another way to look at it.

Instead of pushing the Web toward apps:

Keep it as the Web, and bring the useful parts of apps into it.

Then combine those capabilities with what the Web has always done well: being searchable, instantly usable, and directly linkable.

In that future, search engines could become places where people discover useful apps, while the home screen becomes a personal library of the Web experiences they chose to keep.

Native apps and app stores are not going away.

But not every Web service needs to build a native app and fight for a place in an app store.

Maybe the more useful question is: does this Web service need an app store at all?

I think that question will become increasingly important as PWA continues to evolve.

And one last time:

How far can the Web become an app?

Maybe we have the question backwards.

Can an app be discovered and used as freely as the Web?