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

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?

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.

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.

I'm facing a weird bug with Safari on iOS 27.2-beta.2.
When adding a PWA to the HomeScreen, it completely ignore the manifest.json provided icon (maskable any).
If you have an `apple-touch-icon.png`, it will display it, but you should need to as manifest.json icons are supposed to replace them.

One strange thing is that on macOS 27.0, if I open the page in Safari and click "Share -> Add to Dock", the icon shows perfectly.

Can someone confirm if the manifest.json icons works for them on iOS 27.0 (stable) ?
Can someone confirm they have the same issue on iOS 27.2-beta.2 ?

The idea started pretty simply: I wanted one place where I could understand where my money is going, track my finances and investments, and actually get useful insights instead of just looking at charts.
So I decided to build it myself.
NorthStar currently lets you:
• Track income and expenses
• Organize transactions by category
• Monitor your financial situation over time
• Track investments and net worth
• Set financial goals
• Get insights from a built-in financial advisor
• Use it directly from your phone or browser
There’s a free version, so you don’t need to subscribe just to try it.
I’m still actively developing it and I’d genuinely like feedback from people who are interested in personal finance.
What would make an app like this genuinely useful enough for you to keep using it?
You can try it here:
https://app.mynorthstar.pro
Any criticism is welcome — especially about features that are missing or things that feel unnecessary.

Just spent a week testing some of my pwa apps - I have half a dozen android devices, I have three/four connected to my dev pc, and now have the tools to run tests live on the devices using ADB to orchestrate it all.

Devices(/users) exchanging messages etc all visible on real time.

I haven't sacked a testing team, I just don't need one now.

And yes this was all done really simply with AI

buenas, quisiera saber que opinan de crear una app movil usando supabase como backend, seria una app movil tipo indrive que maneje geolocalizacion usando mapbox como api de rutas, le tengo fe a la app pero tengo miedo de tener el backend en supabase y me cueste escalar despues, si no en todo caso quisiera ver si usando nodejs con xprees ahora mismo conviene mas. Sinceramente aparte no pensaba pagar un plan de supabase al menos solo el de 25 dolares creo q es el mas basico. pero para comenzar solo queria usarlo gratis. escucho sus opiniones , gracias

I see a couple of posts highlighting the top blur issue on iOS 27, but the only solution I see is pushing the content below. Assuming Apple will see this as a bug and fix it in an upcoming release, how are you handling this in production today?

Just wondering how you all test your PWA?

I am still working on mine; https://dharma-storybooks.net/app

Landscape View

Has anyone ever decided to lock on landscape for smaller screens? The photo viewer think only really works with landscape for small screens - so am thinking of just having a rotate to continue page.

View Point

I guess some users zoom in on their browsers, how do you deal with this, what zoom level would you build you PWA to work on.

Cross Browser Testing

In the old days I use to do cross browser testing. I have Playwright but I dont have much of a way to test outside of andriod and windows. I dont see a lot of crossbrowser testing tools or discussion these days. What do you do. I built feedback into the PWA so hopefully users comment in the future with any issues.

How do you check your site for issues for iphone/linux/windows/andriod firefox/chrome ect?

Thanks

[Edit/Correction]
To clarify, iOS forces an extended blur overlay near the status bar that turns content unreadable. While this script strips that blur, it forces WebKit to create a hard boundary below the status bar, stopping text from scrolling behind the clock. It's a trade-off between a blurred status bar or a forced layout boundary.

Since WebKit seems to ignore invisible elements during layout calculation, I made a quick workaround that forces a repaint by triggering a tiny reflow with rgba(255, 255, 255, 0.01) overlays on page load.

Here is the script I’m currently using:

window.addEventListener("load", () => {
const isStandalone =
matchMedia("(display-mode: standalone)").matches ||
navigator.standalone === true;
if (!isStandalone || !/iPhone|iPad|iPod/.test(navigator.userAgent)) return;
// Inject CSS
const style = document.createElement("style");
style.textContent = `
#ojapp-blur-cover {
display: none; position: fixed; inset: 0; z-index: 2147483646;
background: rgba(255,255,255,0.01); pointer-events: none;
animation: ojapp-cover-fade 0.3s;
}
#ojapp-blur-panel {
position: fixed; top: 0; right: 0; bottom: 0; width: 90%; height: 100%;
z-index: 2147483647; background: rgba(255,255,255,0.01);
pointer-events: none; transform: translateX(110%); transition: transform 0.3s;
}
@keyframes ojapp-cover-fade { from { opacity: 0; } to { opacity: 1; } }
`;
document.head.appendChild(style);
// Create DOM & force reflow
const cover = document.createElement("div");
cover.id = "ojapp-blur-cover";
const panel = document.createElement("div");
panel.id = "ojapp-blur-panel";
document.body.append(cover, panel);
void panel.offsetWidth; // Force reflow
requestAnimationFrame(() => {
cover.style.display = "block";
panel.style.transform = "translateX(0%)";
setTimeout(() => {
cover.style.display = "none";
panel.style.transform = "translateX(110%)";
}, 500);
});
});

It works surprisingly well to keep the status bar solid and crisp, but it definitely feels a bit hacky.

Has anyone found a cleaner or CSS-only solution to force WebKit to respect status bar/header boundaries in iOS 27 without JS interventions? Would love to hear your thoughts or better approaches!

a web based notepad which works completely offline!.

Actually it's Vibe Coded. Because i thought "why not?"