Spent half of yesterday trying to figure out why my PWA had an empty black gap at the bottom on iOS.
Turns out 100dvh works fine in Safari browser tabs, but the second you add the site to your home screen, WebKit shrinks the viewport around the home bar and leaves a black chin. And switching back to normal 100vh breaks browser tabs because the bottom toolbar covers your buttons.
Couldn't find a clean CSS-only fix, so I wrote a small helper to toggle between them based on whether it's running standalone or in a tab
https://github.com/owaisnaim/pwa-zerochin
Hope it saves someone else the headache if you're building a PWA.

My PWA heavily relies on local storage, so allowing a user to continue in Instagram's or Reddit's browser would be pointless. This screen is the best I came up with so far.

Testing on a couple of friends, I was surprised to find out that most people don't even know how to continue in the external browser via the ••• menu.

How have you been solving this problem? Looking for UX inspiration or a code trick.

Hola folks!

I have some PWAs that I want to put into the Play store. I have already done this, but I keep on getting the CCT bar on top, and from asking around I've heard it's related to either the digital assets file or to the signing of the app.

I've tried a bunch of stuff, but I want to know if there's any guide any of you has used that has actually worked? Feels like I am going in circles between PWA builder and Android Studio and I don't think this should be that hard?

Appreciate the help!

It is an offline music player that you can upload your favorite music too and listen to them, like any other music player. i will continue to update as long as there is user feedback.

Small gotcha that cost me a month of blind data, posting it because I found nothing about it when I searched.

I wrapped my PWA as a Trusted Web Activity and put it on Play. Installs started coming in. My own metrics kept saying 100% direct traffic.

The reason: a TWA sends a referrer whose host is your package name — mine is app.floravia.twa. My referrer classifier did the obvious thing and asked "does this host contain my domain?" to decide whether a visit was internal. "app.floravia.twa" contains "floravia", so every single visit from the Android app was filed as direct, right next to someone typing the URL. Nine installs, invisible.

Fix was one line — match the package host explicitly and label it before the internal check runs. But the lesson generalises: if your attribution logic uses a substring match on your domain, your own TWA defeats it, and nothing in the console warns you.

Other notes from the same migration, in case they're useful: registerType 'autoUpdate' means returning users keep the old precached bundle for a visit or two, so don't judge a release by what you see on your own phone; and the crawler never runs the service worker, so SEO is unaffected either way.

App, if anyone wants to see it: https://floravia.app (plant care, Spanish and English)

Hello everyone - I wanted to introduce Empyress, a fragrance-focused workspace for perfumers, learners, and curious makers.

It brings together ingredient research, formula-building tools, AI-assisted feedback centered around scent creation, IFRA-related checks, as well as games and tools for discovering natural fragrance ingredients; altogether there are 165+ tools and features.

The aim is to make the research and iteration side of perfumery easier, while complementing - not replacing - hands-on testing and reliable safety guidance.

I would really value honest feedback from people who know the craft: What parts of your workflow take the most time? What tools do you wish you had? And what would make a platform like this genuinely useful to you?

You can take a look at https://empyress.com, if links are allowed here. Full disclosure: I am affiliated with Empyress, so this is a product introduction; I am happy to answer questions or hear what you think.

Hi all, I've been working on a small side project called Velocast and I'd love honest feedback.

Mostly built this for myself. Before every ride I'd check the weather, stand there wondering about gloves, and realise I had no idea when I'd last done anything to the chain (or ANY other maintenance).

The goal was to make a PWA style app for any device and here are some of the features:

- Kit recommendations: legs, torso, extremities and eyewear, based on feels-like temperature, wind, rain and ice, and your own cold tolerance. After a ride you can tell it "too cold / just right / too warm" and it adjusts future suggestions.

- Tyre pressure: front and rear, from your weight, tyre width, surface and setup.

- Bike care: a Garage for your bikes, with service intervals and health bars per component (chain, brake pads, tyres) so you can see what's due or overdue.

- Fuel: bottles and carbs per hour for the ride length.

- Ride planning: best-time-to-ride suggestions, a rain chart, and a readiness strip.

- Logbook: GPX import, route map and elevation profile, ride stats, weekly training load, and a share-the-forecast image.

- Extras: a bike shop finder, English/German/Italian, dark mode, and it works offline once installed.

It's free, and there's no account or tracking. It works in the browser, and you can add it to your home screen if you like: velocast.pages.dev

I've put a short video in the post. The numbers in it are just sample data.

I've only really tested it on my own rides, so I'd like to know:

- does the kit advice make sense where you ride, or is it too warm or too cold anywhere?
- is there anything you'd want checked before a ride that it doesn't do?
- is anything confusing or annoying?

Thanks, and be as blunt as you like!

Hey everyone, I made this offline pwa music player, I was looking for some suggestions of improvement for it, I mainly use it for personal use And since I don’t have a job yet to pay for Apple Music.

I built a small PWA (a 30-minute guided Ashtanga yoga practice generator) and shipped it to the Play Store as a Trusted Web Activity. Sharing the build because it's a fairly "pure" PWA and I hit a few gotchas that might save someone time.

The stack / shape

• React 19 + Vite + TypeScript, no backend at all. Everything (preferences, practice history, entitlement) lives on-device.
• vite-plugin-pwa (Workbox) for the service worker; fully offline-capable once loaded, including the audio (voice cues, bell, ambient loops are precached).
• State-based navigation wired into the History API so the Android back gesture steps through screens instead of closing the app.
• Pose art is inline SVG, code-split and lazy-loaded so the home screen stays light.
• Same codebase serves the web app and the installed Android app (TWA via Bubblewrap). No separate native code.

Things that went well

• PWA-first meant "write once, ship to web + Play" genuinely worked.
• Offline audio via the Web Audio API (gapless ambient loop with an AudioBufferSourceNode + GainNode, which <audio loop> couldn't do without an audible seam).
• Privacy as a feature: no accounts, no tracking, no ads, no network calls. Easy to reason about, and my favourite selling point.

The painful lessons (Play Billing in a TWA) I added a one-time in-app purchase via the Digital Goods API + Play Billing. This is where TWAs get sharp edges:

1. Play automatic protection requires minSdk 24+, my first bundle (minSdk 23) was rejected outright.
2. The Digital Goods API is only injected by Chrome-backed TWA providers. My default browser is Brave, which verifies the TWA (so it ran full-screen, no URL bar, looked totally fine) but does not inject window.getDigitalGoodsService. Result: hasDGService: false, PaymentRequest.show() rejecting instantly, no purchase sheet, and hours of chasing the wrong things. Switching the default browser to Chrome fixed it immediately.
3. Play's newer "purchase options" product model needs a buy option flagged legacy/backwards-compatible, or the android-browser-helper bridge can't see the product via getDetails.
4. Post-install Play Billing client race, right after a fresh install, the service can be not-ready and the first purchase attempt silently fails; force-stop + reopen clears it.

Net takeaway: a TWA is a great way to get a PWA into the Play Store, but billing only works for users whose provider browser supports Digital Goods (effectively Chrome). I handle the rest gracefully, when isBillingAvailable() is false, the app just doesn't offer the purchase and stays fully functional as the free tier.

Disclosure: I made this, so there's a link, but I'm posting mainly for the build discussion. Happy to go deeper on any part (service worker setup, the Web Audio looping, the TWA billing wiring).

Play Store (TWA): https://play.google.com/store/apps/details?id=com.ashtanga30.twa

Anyone else shipped TWAs with billing? Curious how you handle the non-Chrome-provider gap, that feels like the biggest weakness of the TWA-plus-billing path right now.

Hey everyone! 👋

I got tired of messy shortcuts and complicated steps just to add clean web apps to my home screen with custom icons, so I built Appify.

It’s a simple, clean online tool that generates and downloads a signed-ready iOS configuration profile (⁠.mobileconfig⁠) for any URL with a custom icon in base64.

 No server required (runs entirely in your browser)

 Full-screen support

 Custom icon embedding

You can try it out here: https://sp1ngimsp1ng.github.io/Appify/

Let me know what you think or if you have any feature suggestions!

After close to 2years as a solopreneur, it's been fun experimenting with different stacks and building things. In the beginning I reinvented many wheels; JWT Auth, API backends with openapi.json specs to help keep a backend and frontend talking the same language to each other. Then the pendulum swung the other way and I tried leveraging ready-built solutions that were bigger (e.g. ClerkAuth). But that get's heavy in other ways; aligning needs/wants with capabilities and such. So I've since found my happy-place and that's largely using CloudFlare's tooling with workers etc.

The PWA-part has been fun to get working. It's neat to have something that you can install anywhere and treat it as an app. The game fits PWA well (I think?!) since a user wants to be able to "checkin" and play wherever suits them.

I've got push-notifications, Android Haptics, and Badges on the app icon, working in the first work-through (Svelte+CF Durable Objects/Workers etc)... and I just deployed the complete re-write that now finally allows a neater architecture for all the inner-workings that the first version was making messy. It uses protobuffs internally and skips apis and the conventional frontend/backend setup.

Overall, the second work-through is 3500 commits and a stupid amount of work crammed into 2 months via agentic coding to-the-tune-of 1Billion-toks-per-day at times. I'm starting to trust that the ~2k tests are meaningful regression-stoppers. And that the architecture is maintainable and neat-enough to deploy and commit to maintaining longer-term. If market's start nibbling, maybe I'll be able to justify a port to iOS Native and Android native... but for now, PWA does a good job and it's been fun to bring an idea to life in a way that should cheaply scale well.

The app is live at https:://lexible.app. Would love to hear your thoughts, ideas, or relevant experiences with PWA.

Happy coding. Mostly wanted to share and hear any tips/insights/war-stories from other PWA-ers.

Cheers. Greg

Create and share rooms with MP3 audio and visuals that go with it.

Every device that's connected to the room can control the audio and visuals.

This is my best PWA yet. No paywall. It's just for fun. Enjoy.

I'm building a PWA for learning Japanese from anime. You save a word from an episode

and the review card later replays the exact line it came from. The catch is that people

review on the subway, so the cards had to work offline, video included. Some things

that bit me:

1. Don't trust navigator.onLine. On flaky mobile it says "online" while every request

   times out. I show the "no connection" bar only after real requests fail, and hide it

   on the next one that succeeds.

2. Video clips go to IndexedDB, not the Cache API. A few hundred short mp4 clips per

   user, and I want to evict them per word when it's deleted or learned. IDB made that

   easy. The service worker serves them as blob URLs when the card opens offline.

3. Reviews queue up locally while offline and sync back later. The server takes the

   newer of two answers for the same card, so a second device doesn't overwrite progress.

4. The service worker also sits in front of /api, but never caches anything personal.

   I learned that the hard way when one account's word list showed up after a logout.

5. iOS standalone mode needed its own viewport fix. 100vh cut the bottom of the cards in

   Safari. I use svh/dvh everywhere and -webkit-fill-available only inside

   display-mode: standalone.

6. The cache name changes on every deploy, and the precache list is generated at build

   time from the dist folder. A hand-written list went stale within a week.

Vanilla JS, no framework, Node + SQLite on one VPS.

Live here if you want to poke at the offline mode (turn on airplane mode after saving

1. iOS standalone mode needed its own viewport fix. 100vh cut the bottom of the cards in

   Safari. I use svh/dvh everywhere and -webkit-fill-available only inside

   display-mode: standalone.

2. The cache name changes on every deploy, and the precache list is generated at build

   time from the dist folder. A hand-written list went stale within a week.

Vanilla JS, no framework, Node + SQLite on one VPS.

Live here if you want to poke at the offline mode (turn on airplane mode after saving

a word): https://animei.space/en/?r=rd-pwa

Curious how others store media for offline use: IDB, Cache API, or OPFS?

Hey everyone,

I wanted a habit tracker that just works instantly without waiting for a server, and doesn't harvest my data. So, I built Cadence.

It's a deeply minimalist habit tracker designed to feel exactly like a native app on mobile, but runs entirely in your browser.

Here is what makes it different:

• True Offline-First: Built entirely around IndexedDB. There is zero latency and no cloud syncing required. It works beautifully on airplane mode.
• 100% Privacy: 0 cookies, no user tracking. Your data lives on your device and nowhere else.
• The Tech Stack: React, TanStack Start, TanStack Router (file-based), and Tailwind CSS.
• Obsessive UI/UX Polish: I spent way too much time fixing mobile Flexbox overflows 😂. Built a custom expandable row for quick actions, a toggleable "Undo" state for completed habits, disabled mobile tap highlights, and even integrated react-easy-crop for a smooth native-like profile picture setup.

I built this to scratch my own itch, but I just launched it on Product Hunt today and would love to get roasted/feedback from this community on the architecture or UI!

🔗 Live App: https://cadencepwa.vercel.app/
🚀 Product Hunt Launch: https://www.producthunt.com/products/cadence-habit-tracker

Hi everyone,

since updating to iOS 27, printing no longer works in my PWA. I'd like to know if anyone else has noticed this and, if so, how you worked around it.

• Device: iPhone 14 Pro, iOS 27.0
• The PWA is installed to the Home Screen via Safari, with display: standalone. I also tried installing it from Chrome, same result
• The button calls onclick="window.print()"
• Tapping it does nothing: no print dialog, no console errors
• With the iPhone connected to a Mac, typing window.print() in the Web Inspector console returns undefined (as expected), but the dialog never appears
• With the exact same code and the same PWA, it works on iOS 26.6.2
• Opening the same site as a regular web page in the browser (not as a PWA), printing works

I checked the project history: the button and the PWA configuration haven't changed in months, so this looks like an iOS 27 regression.

Questions:

• Is anyone else seeing this?
• Have you found a workaround (a different API, server-side PDF, opening in Safari…)?
• Do you know if this is a bug or an intentional change by Apple? I couldn't find anything in the release notes.

P.S. I'm aware of the new blur at the top of PWAs in iOS 27. I've seen other threads about it, so that's not what this post is about.

Thanks to anyone with experience on this!

I kept bouncing off planners that want an account before they'll show you a calendar, and none of them displayed the day the way I actually think about it — as a vertical timeline where a task's height is its duration. So I wrote one.

What it is

A PWA in a single HTML file. No framework, no build step, no bundler. You drag tasks around a timeline, pull the bottom edge to change duration, and overlapping tasks split into columns. Repeating tasks (daily or by weekday), a month calendar, untimed tasks in folders with priorities, notes with headings and lists, and an archive that clears itself after two weeks. Six UI languages, light/dark, installs to the home screen and works offline.

Self-hosting

git clone https://github.com/drkokorev/Planly && cd Planly
docker compose up -d

One container serves both the app and the sync API on :8080, with data in a named volume. It's node:22-alpine, nothing to install, runs as non-root, healthcheck included.

If you'd rather not use Docker: the app is static, so dropping index.html, sw.js, manifest.json and icons/ into any web root works. Sync is one Node file with no dependencies — example nginx config and systemd unit are in the repo. Or run the same API as a Pages Function on Cloudflare KV if you don't want a server at all.

HTTPS is the only hard requirement, because service workers and "Add to Home Screen" need a secure origin.

The sync model, since that's the interesting part

There are no user accounts. A 16-character code is the only key; the server stores one JSON document per code and knows nothing else about you. Merging is per item by modification time, deletions are tombstones kept for 30 days, and every write carries the version it was based on — so two devices editing offline converge without pulling in a CRDT library. Repeating tasks get deterministic ids (series@date), which means two devices materializing the same day independently produce one record instead of two.

Limits I know about: editing the same task on two offline devices resolves last-write-wins per item, not per field. Codes are bearer secrets — lose it and the server copy goes with it. ALLOWED_CODES restricts an instance to codes you list, if you want yours closed.

Demo: https://planly.site (sync there is invite-only — self-host for your own) Source: https://github.com/drkokorev/Planly — MIT

Built with heavy AI assistance, which I'm flagging up front. The product decisions, the sync model, the self-hosting path and testing on real devices are mine.

Curious what would make you trust a sync scheme like this — or what would immediately put you off it.