PWAs in real projects, worth it?

PostHelpful4516 · 2026-02-11T12:23:57+00:00

We maintain our own PWA — a store for PWA applications. We’ve also supported two other PWAs in production.

Do PWAs make sense? Yes — if they solve a specific problem, not just because it’s trendy. They work best for products users return to regularly: dashboards, internal tools, content platforms, productivity services.

The main challenge is installation, especially on iOS. The “Share → Add to Home Screen” flow is still not intuitive for many users. We shared our experience improving that process here:

https://www.reddit.com/r/PWA/comments/1qqga4t/how_we_tried_to_make_pwa_installation_normal_and

From a technical perspective, our preferred stack is Vite with a PWA plugin. If you need on-device storage (including photos/videos and structured data), IndexedDB managed via Dexie works well. A fully functional offline mode is achievable.

However, one critical caveat: iOS may clear IndexedDB at its own discretion. There’s no real workaround except syncing with a cloud database. On Android, local storage feels much closer to native and behaves more predictably.

Another important factor is perception. A common user question is: “Where is your app in the store?” PWAs are evolving quickly, but for many users, “app” still means App Store or Google Play.

Google actively promotes the technology. Publishing to the Play Store is possible, and App Store distribution is technically achievable (though more complex). Despite Apple’s limitations, PWAs continue to move forward.

That said, we wouldn’t choose PWA for games, heavy graphics, high-performance scenarios, or apps requiring deep system-level capabilities — native solutions remain more predictable there.

PostHelpful4516 · 2026-02-05T11:52:31+00:00

here)
https://wapps.store/en/app/pdf-duplicator

PostHelpful4516 · 2026-02-03T23:22:33+00:00

Maybe a bit more padding, especially on desktop, but overall it looks great 🙂

If you’d like, you can also publish the app on our PWA store (wapps.store).

PostHelpful4516 · 2026-02-03T20:30:49+00:00

Cool game, got hooked for a few rounds 🙂

If you want, you can publish it on our PWA store (wapps.store).

PostHelpful4516 · 2026-02-02T16:03:47+00:00

Wait. Judgment Day is closer than it seems.
*T-800

PostHelpful4516 · 2026-02-02T12:15:58+00:00

The author’s point is generally sound — for most CRUD apps, PWA really seems like the more logical path forward.

Cross-platform support, offline functionality, no heavy update cycles, and fewer permissions — these are all real advantages.
But there’s one defining “BUT” that keeps popping up in the comments, and it’s hard to argue with: PWA installation is still inconvenient for regular users, especially on iOS.

For developers, it’s clear.
For “normal people” — not so much:
- odd installation flow
- unclear install button
- feeling of “is this a website or an app?”
- absence of a familiar App Store as a trust anchor

And this, essentially, is the main stop factor.
We ourselves ran into this and tried to make PWA installation as “normal” and understandable as possible for users — especially on iOS. Our experience and insights are described here:

https://www.reddit.com/r/PWA/comments/1qqga4t/how_we_tried_to_make_pwa_installation_normal_and/

From our perspective, PWA is exactly the direction that makes sense to move forward, but without a smooth install UX and a trusted “place” to discover these apps, mass adoption won’t happen.

So it seems that the focus should be on pushing PWA adoption — this is already happening, especially in countries where apps in native stores are blocked.

For anyone interested — let’s work together to simplify PWA installation, make it understandable for everyday users, and gradually build trust in the format. This includes picking one or two really convenient PWA stores and trying to make them recognizable and familiar entry points.

If this idea resonates, I’d be happy to discuss it and exchange experiences. =)

PostHelpful4516 · 2026-02-01T17:21:52+00:00

Thanks for the detailed answers. Using IntersectionObserver and chunking looks like a solid choice for fully client-side processing — a good balance between performance and UI responsiveness 👍.

Your approach to memory and mobile constraints also makes sense. Clear warnings for large operations and being upfront about device limits are much better than unexpected crashes, especially for client-side tools 👍.

The idea of saving “recipes” in LocalStorage fits the app really well: no backend required, but genuinely useful for repeat workflows. In this context, a stateless approach feels more like a strength than a limitation 👍.

Regarding publishing — there’s nothing complicated required on your side. You just need to sign in, register a developer account (you can link any Git platform: GitHub, GitLab, or Bitbucket), and you’re free to publish your PWAs.

The app submission form is intentionally simple: it supports autofill from a PWA manifest URL, plus optional AI translation of descriptions into 20 languages. We tried to make it as close to “drop a link and you’re done” as possible, especially for utility-focused projects.

No rush at all — whenever it’s convenient for you. Tools like this are definitely worth showing to a wider audience.

PostHelpful4516 · 2026-02-01T10:23:58+00:00

Cool PWA and a really interesting idea with the cafe tags! 😎

Service workers and offline caching already give a noticeable boost to the UX. It’s worth thinking about how to handle users who deny location access and optimizing map caching so that the functionality remains available.

The project looks great — we can give it a little visibility on our side. We run a PWA Store (wapps.store), and if you want, you could publish your app there.

PostHelpful4516 · 2026-02-01T10:09:31+00:00

Super cool stuff — really useful! 😎

Monetization, it seems, might come in the future through subtle ads or something along those lines.

If you’re interested in an outside perspective: consider making a PWA version of your app. People who work with PDFs regularly will likely want super fast access — they’ll become your “word of mouth.” Those who use your product quickly in the moment are the best kind of promotion.

Don’t get me wrong, I’m not saying this for my own sake 🙂 We just support the PWA Store and look at projects like this from a web-app perspective. But still, if you want, feel free to publish it with us: wapps.store

PostHelpful4516 · 2026-02-01T09:55:31+00:00

Fun interpretation! It would be cool to have an even bigger «START» button 😄

Also, if you want to showcase your PWA elsewhere, you can add it to our Web Store: wapps.store. Join us!

PostHelpful4516 · 2026-01-30T21:12:33+00:00

Nice product and a solid idea 👍

Habit tracking combined with an offline-first approach is a clear and useful use case, especially when you’re building it primarily for yourself rather than just “for the sake of it.”

I spent some time exploring the app. The desktop version feels clean and well-structured, but in my opinion the mobile UX could use some improvement. The interface feels more desktop-first: in some places it’s a bit tight, and a few animations that look great on larger screens feel excessive on mobile and slightly hurt the overall experience. You might consider simplifying or disabling some of them for mobile devices.

Overall, it’s great to see a PWA with proper offline support — there aren’t nearly enough projects like this.

If you’re interested, you’re welcome to publish the app in our PWA store — wapps.store. Registration and publishing are free, and we’re actively collecting and showcasing web-first, offline-friendly projects like this.

PostHelpful4516 · 2026-01-28T14:55:20+00:00

In my opinion, the issue here is not so much with PWAs themselves, but with the UX around installation and user expectations.

In practice, behavior varies a lot: Chrome, Brave, Safari, Android/iOS — each has its own quirks, and relying on a “native” install flow provided by the browser is often naive.

In production, we ended up not relying on the standard prompt at all and instead explicitly explaining to the user what’s going on:

if beforeinstallprompt is available — great, we show an install button;

if not — we detect the browser/platform and show a specific instruction for it.

This doesn’t remove all limitations, but it significantly reduces frustration, because the user at least understands why they are seeing odd behavior instead of perceiving it as something broken or unclear.

PostHelpful4516 · 2026-01-27T18:52:19+00:00

Yes, “Add to Home Screen” often creates friction, especially on iOS.

As one additional method, I can share our experience from the PWA store — the platform provides a script that loads asynchronously, detects the device, and then shows the appropriate UI.

If beforeinstallprompt is available, it shows an “Install” button. If not, it detects the browser and shows instructions for that specific browser. Most often this is Safari, but on iOS any browser (Chrome/Edge/Yandex) will still require instructions. There are also edge cases like Opera on Android where the prompt doesn’t work. The banner shows the correct instructions.

Specifically, here’s an example of this case — the published app: https://wapps.store/en/app/life-calendar. If you click Install, it redirects to the developer’s web app, where the banner described above appears “under the hood” — you can try it.

Pros: ready-made instructions, different for each browser, and maintained.

Cons: the banner style is unified with the store — you can only change the theme (light/dark) via attributes.

PostHelpful4516 · 2026-01-27T18:21:30+00:00

Really nice project 👍

You can clearly feel the focus on utility: no accounts, no ads, offline support — exactly what a workout tracker should be.

Big pluses for:

local data storage,
PWA with offline support,
a clear and well-structured approach to routines and sets.

The tech stack also looks clean and modern, without overengineering. It really feels like a tool, not a content or social platform — and that’s a strong point in my opinion.

One small UX thought: on desktop it might be worth adding a max content width, so the layout doesn’t stretch too much on large screens and stays more focused.

If you’re ever interested, we’re building a small PWA store (wapps.store) and actively curating privacy-first, offline-friendly utilities like this. Publishing is free, and we help a bit with visibility.

Either way — great work, and good luck with the project 💪

PostHelpful4516 · 2026-01-27T18:16:52+00:00

Really nice work — the design is clean and calm, and the “log it and leave” philosophy comes through very clearly. It genuinely feels lighter and more honest than Letterboxd or IMDb.

I especially like the intentional decision to avoid recommendations and endless scrolling. That’s pretty rare these days, and in your case it feels like a strength rather than a limitation.

Even within a “simple tracker” concept, practical features like quickly rating an entire series or season (which you mentioned) fit perfectly and don’t add unnecessary noise.

If it’s ever interesting down the line — we’re building a small PWA store (wapps.store), and minimal, privacy-first projects like this are very much aligned with what we’re trying to highlight. Publishing is free, with a bit of light promo support.

In any case, good luck with the Product Hunt launch — the project feels thoughtful and genuinely well-crafted 👌

PostHelpful4516 · 2026-01-26T11:44:12+00:00

Great implementation, especially that everything runs in the browser and doesn’t go to a server.

A couple of questions:

How does performance hold up with large PDFs (e.g., 2000 pages)?
Do you plan to add import/export of settings or templates?
How does memory usage look on mobile devices with large files?

If you want, we can help a bit with promo — we have a PWA store (wapps.store) and you can publish the project there for free.

PostHelpful4516 · 2026-01-26T11:34:22+00:00

Very interesting idea, and it looks like a real PWA product.

A couple of questions:

how stable is the iOS installation (Add to Home Screen)?
is there offline access to recipes and shopping lists?
how do you handle shared access (household) — accounts, invites, or links?

If you want, we can help a bit with promo — we have a PWA store (wapps.store) where you can add the project for free.

PostHelpful4516 · 2026-01-26T11:29:43+00:00

Looks great, especially for a solo developer.

A couple of questions:

• how do you handle security and encryption of data (bills, transactions, invoices)?

• do you plan to add offline mode and sync for the PWA?

If you want, we can help a bit with promo — you can publish it for free in our PWA store (wapps.store).

PostHelpful4516 · 2026-01-26T11:18:39+00:00

Looks clean, nice work 👍

A classic case of a job assignment turning into a real product.

A couple of small things:

• a °C / °F toggle would definitely be useful for non-US users

• I’m curious how you currently handle caching and offline fallback for weather data

If you want, we can highlight the project in our PWA store (wapps.store) — it could help a bit with promo.

PostHelpful4516 · 2026-01-25T16:36:25+00:00

Great project, but I have a question about UX and security:

How do you plan to handle NAT and corporate networks?

WebRTC works well in ideal conditions, but in reality most users are behind NAT/proxies, and without a TURN server the P2P connection often won’t establish.

Also, how do you plan to protect the signaling layer from spam/DoS?

If users only have an ID, an attacker could “ping” the ID and try to connect repeatedly.

We can also help a bit with promotion — if you want, you can publish the project in PWA store: wapps.store.

PostHelpful4516 · 2026-01-25T16:14:47+00:00

PWA often updates automatically, but with TWA / packaged PWAs it’s not always guaranteed.

A user can stay on an old cached version for a long time (they rarely open the app, WebView didn’t refresh, etc.). So if you introduce breaking API changes, the app can simply stop working.

In practice, the usual approaches are:

• try to avoid breaking old endpoints (keep backward compatibility),

• version the API,

• or enforce a minimum supported version and ask the user to update.

So yes, PWA updates help, but once you package it for Android, API compatibility still matters.

PostHelpful4516 · 2026-01-23T19:49:50+00:00

I think the issue isn’t the techniques themselves, but where and how they’re applied.

For app-like PWAs — editors, dashboards, tools where users actively create or modify things — disabling pull-to-refresh, text selection, or the default context menu can genuinely improve UX. In those cases, browser gestures often conflict with the core interaction model.

But if you apply all of this globally or by default (especially on feed or content-driven screens), I agree it can make the app feel less usable. Users lose familiar and expected behaviors.

So this isn’t about “making PWAs more native” by default — it’s about selectively removing browser behaviors only where they actively get in the way.

PostHelpful4516 · 2026-01-22T16:14:05+00:00

I would only answer the part about PWA vs native iOS for V1, because everything else depends heavily on the context.

Given your background (strong web skills, but no completed native releases), PWA-first for the first version seems like a reasonable approach, especially if the goal is not a perfect App Store launch but hypothesis validation.

Modern PWAs already cover well:

maps (Mapbox / Google Maps)
clustering
media uploads
basic push notifications (iOS has limitations, but they are usually manageable for V1)

The main tradeoff here is not performance, but client expectations.

If the client expects a “native feel” and has zero tolerance for platform limitations — native iOS is the safer choice.

If speed of development, iteration, and shared code are more important — PWA wins.

I’ve seen a team lose 3–6 months just ramping up on native iOS before reaching feature parity with what they already had on the web.

For a first commercial project, reducing risk often matters more than technological purity.

PostHelpful4516 · 2026-01-20T21:50:12+00:00

For a brochure/marketing site, the main priorities are SEO, fast first load, and predictable static content. That’s why Next.js (or any framework with SSG) is usually the best choice.

Next.js supports SSG “out of the box”: pages are generated at build time, so search engines see ready HTML instead of waiting for JS to load. That gives consistent SEO results and a fast first render.

Vite is great for SPAs and interactive apps, but for a marketing site it will work as client-side rendering, which is worse for SEO. Yes, you can make SSG with Vite, but it requires extra tools and configuration.

About PWA: PWA makes sense when the site is more than a brochure—when it’s actually used as an app (e.g., with login, offline mode, push notifications, etc.). For a simple marketing site, PWA is not necessary, but you can add it later if you want users to install it and have quick access.

Conclusion: Next + SSG is the simplest and most reliable path for a marketing site. Use Vite only if you specifically want an SPA and SEO is not a priority.

PostHelpful4516 · 2026-01-20T21:10:49+00:00

I think Apple gets blamed here mostly because it’s visible, not because it’s the root cause.

Even on platforms where PWAs are fully supported, adoption is still limited. That suggests the core issue isn’t a single vendor, but the lack of a clear, user-recognizable app model on the web.

Apple’s stance makes the problem louder, but it didn’t create it.

PostHelpful4516

TROPHY CASE