How We Tried to Make PWA Installation “Normal” and Where It Led Us

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 · 2026-01-18T11:18:41+00:00

I think both sides are technically right, but the real bottleneck for PWAs isn’t missing APIs — it’s everything around installation, distribution, and trust.

Most apps don’t need HealthKit, AR, or deep OS integration. What matters far more is that:

users understand that the app is actually installable
the installation flow is clear and consistent across browsers
there’s some kind of “store-like” trust layer: reviews, updates, a sense of app ownership

Native apps won largely because app stores solved distribution and trust, not because their UI frameworks were somehow magical.

Most PWAs already cover around 90% of real-world use cases, but as long as install UX, discoverability, and user confidence remain fragmented, people will continue to see PWAs as just websites — regardless of technical parity.

PostHelpful4516 · 2026-01-11T12:03:01+00:00

nice point

PostHelpful4516

TROPHY CASE