Hey r/pwa!
I’ve been exploring a concept I call UDA (User-Defined Apps), which leverages dynamic web app manifests to differentiate PWAs from native apps.
Instead of building a single monolithic app, this approach lets users define their own custom "app instances" right from the URL query parameters.

How it works in this Timer Demo:
• Users set duration, count direction, and icon color on the page.
• The URL parameters update dynamically (e.g. ⁠?time=5&mode=down&icon=red⁠).
• The Web App Manifest dynamically updates its ⁠name⁠ and ⁠icon⁠ based on these parameters.
• When added to the Home Screen, it creates a dedicated shortcut (e.g., "5m↓ Timer" with a red icon).

Note on OS Behavior:
• iOS (Safari): Works perfectly! Treats each unique URL query as an independent homescreen app.
• Android (Chrome): Currently limited because WebAPK binds to the manifest ⁠scope⁠. Query variations overwrite the existing installed PWA instead of creating separate instances.

You can literally fill an iOS homescreen folder with customized, single-purpose timers—all powered by a single PWA source.
I’d love to hear your thoughts on this paradigm and how we might overcome the scope limitations on Android!
Try the demo here:
https://ojach.github.io/PWA-1P1A/timer-en/?time=3&mode=down&seconds=on&icon=purple

This is a free directory I created to help small and medium-sized PWAs gain more visibility online. You can list a PWA for free or—with a paid plan—have it listed more quickly.

Started as a joke with a friend, ended up as my most polished PWA. Next.js 16 + TypeScript, hand-written service worker (cache-first), Zustand persist, Web Audio API for the sounds (zero audio files).

Things that hurt:

- iOS has no beforeinstallprompt → manual "Add to Home Screen" flow

- 100vh broken in standalone → dvh

- Safari updates the SW on its own schedule, users got stuck on old versions → added version check + update toast

Live: https://fart-counter-lake.vercel.app

Source: https://github.com/agent-slon-lab/fart-counter

Happy to share details on any of the quirks 🙂

I created this directory to give smaller PWAs some visibility or free links, and for my part, I'm trying to make a little money from the directory with the paid plans. for those coming from Reddit, send me your PWAs and I'll post them directly in the thread on the directory.

I wanted a set up so a group of people could play games together - each with their mobile phone - no install, minimum trust.

I did the initial.games as PWA's and they went fine (obvs) but multi player was a challenge... A challenge that as a pure PWA beat me :(.

So I ended up with a small apk, that runs on one phone it can download the pea games from GitHub, and creates it's own cloud and lets other people join and - it then serves the games (it cached from GitHub) and acts as games master.

Not being privileged (Https or local host) there are some limitations (tilting the screen doesnt work, so you never to touch the screen).

The games have different multiplayer modes - same game individually but symaltaniously, for highest score, or shared pitch multi player etc.

Anyway here it is so far...

https://github.com/idltd/digi-pocketeers

I've been experimenting with a PWA architecture I haven't seen used very often.

The web app isn't the main application.

The user's desktop application is the host, and the PWA installed on their phone becomes a companion to it.

I'm building an open-source framework around the idea called Crosslink.

The user experience I'm aiming for is:

1. Open desktop app
2. Scan its QR code
3. Pair the phone
4. Add the companion to the home screen
5. From then on, just tap the icon

No repeated pairing.

The interesting PWA problem starts at step 5.

The desktop computer might be asleep or Crosslink might not currently be running.

If the installed PWA simply points back to the host, iOS will eventually give the user a browser-level connection error.

So Crosslink installs a small service-worker-backed bootstrap shell on the phone.

That means launching the app can work more like:

tap icon

↓

cached bootstrap loads locally

↓

attempt to find/reconnect to trusted desktop

↓

host online: silently authenticate and enter developer's app

or

host offline: show an actual offline state and continue retrying

↓

host comes back

↓

automatically reconnect

The trust relationship is independent from simply possessing the URL, so the desktop can revoke a phone and the installed PWA becomes useless until it's paired again.

The developer still owns the actual PWA UI. Crosslink is just providing pairing, trusted-device state, connectivity, RPC, reconnect and the bootstrap/install layer.

The bigger goal is letting desktop developers ship useful phone companions without having to maintain native iOS + Android apps.

I'm especially curious about the PWA side rather than the networking side:

If you were designing this, what iOS/PWA lifecycle edge case would you be most worried about?

GitHub: github.com/jacobpowaza/crosslink
Docs: crosslink.mintlify.site

Hello guys so i had a app project in mind for a long time but before i start this big project i tried building something else to test my limits and see how creating something like this goes.

As a gym goer and the gym community growing rapidly i landed on this gym app idea like those gamified apps like Liftoff but without the absurd subscriptions and predatory monetization.So i created my own tracker that also functions as chat and has levels,ranks, and comunity posts.

I wpuld really like if someone can look at it and give me some review or advice.The calculator for the ranks needs some improvements and the app itself some tweaks but forn now it should be functioning just good.

Ps: this is my first try at doing something like that so any advice is welcomed 🙏🏼
Ref link
Track workouts, level up ranks, and train with me on ThorTrace. https://thortrace.app/?ref=10345b43-dd0c-41bc-9787-0b1ead82e834

And normal link https://thortrace.app

Fast, zero-dependency DOM snapshot & screenshot library for Browser & SSR (Next.js, SvelteKit).

• ⚡ < 4 kB gzipped
• 🔍 Retina & 4K ready (2x / 3x)
• 🖼️ PNG, JPEG, WebP
• 🛡️ 100% TypeScript
• 📦 npm i sharedom

Demo & GitHub: https://github.com/Erickgiber/sharedom

Gift me 1 star ⭐️ if you liked it 🚀

I used TabTrader for years mostly for charts and alerts and was pretty annoyed when it shut down last week, so I started building my own replacement just for myself. It ended up turning into a much bigger project than I planned, so I decided to share it. It's called TabMira and I built it as a PWA so it works across desktop and mobile without having to maintain completely separate apps. I've mostly been focused on making the realtime market data and alerts as fast as possible. Still building and changing a lot. This is my first PWA!!

tabmira.com

I’ve been building Level Up, a completely free fitness PWA designed primarily for hypertrophy training.

Rather than simply recording workouts and calories, Level Up uses your results and feedback to help plan what comes next.

Features include:

• Adaptive coaching based on performance, recovery and workout feedback
• Progressive-overload recommendations for upcoming sessions
• Automatic calorie adjustments based on weight trends and goals
• Personalized calorie and macro planning
• Workout planning, building and logging
• Recovery feedback and deload guidance
• Exercise form guides
• Weight, volume and strength-progress tracking
• Pre-built workout templates
• Offline support and browser installation
• Cross-device backup and syncing

I chose a PWA so people could access it immediately without paying a subscription or downloading a large native app. Level Up is completely free to use, and current users will also retain free access to any future native version.

I’d appreciate feedback from other PWA developers, particularly around performance, offline behaviour, installation and whether the experience feels like a polished native app.

Try it here:

https://leveluphypertrophy.com

I’m the independent developer behind it, so honest feedback is genuinely useful. What would you improve first?

This PWA plays your own audio files and has these features:

• Join the "room" with a QR code
• Synchronized multi-device audio playback
• Synchronized Milkdrop visualizations, including in VR

I grew up with Winamp and I loved its built-in Milkdrop visualizer, so I built this PWA that implements it.

Built a map-based species-logging app (users pin locations where they spot insects) and made a hard call early: PWA only, no native app, no App Store listing.

The reasoning: my actual users are parents who click a link from a group chat or blog post. Every extra step (App Store search, install, open) loses people. With a PWA, the flow is link → "Add to Home Screen" → done, no account required to even browse.

The tradeoff that actually bit us: zero app store discoverability. No App Store/Play Store search surface means all discovery has to be link-driven — social posts, blog content, word of mouth. That's a real cost, and I underestimated how much store search traffic I was giving up before launch.

On the plus side: one codebase, no review cycle, ships instantly, and install friction for the actual target audience (non-technical parents) turned out lower than expected once they saw the "Add to Home Screen" prompt.

Live version: https://spotthe.world — curious if others here who went PWA-first hit the same discoverability wall, and what (if anything) helped.

I created this service to publish PWA's with an AI coding agent like Claude Code.

This article explains how I used it to publish https://fun.pwanow.com, for example:

https://www.linkedin.com/pulse/how-i-published-httpsfunpwanowcom-russell-vandermey-9eqpc/

After testing with a few people from here, the Waves App Store is now accepting public submissions.

Big thanks to everyone who helped me get the basics working. The feedback from this community made a real difference.

Check it out and submit your PWA:

Store: https://findborg.com/waves/
Submit: https://findborg.com/submit/wave/

Drop your URL and we'll do the rest. Happy to answer questions in the comments.

I’ve been building SoraFiles, a privacy-first web app for working with PDFs and images directly in the browser.
Today I submitted it to Uneed and used their Fast-track option. The launch is now confirmed and should be scheduled within the next couple of weeks.

The main idea behind SoraFiles is that supported file operations happen locally on the user’s device instead of uploading the files to a processing server.

I’m currently spending most of my time improving the existing product rather than just adding more features, especially mobile UX, reliability, output quality and privacy.

I’m curious to see whether launching on a platform like Uneed brings useful feedback or early users.

Site: sorafiles.com

I’ll probably share the results after the Uneed launch too.

I'm comparing ToolJet, Appsmith, Superblocks, and Mendix, and I'm trying to understand their actual mobile app support.

For each one, is it:

1. Just a responsive web app that works on mobile browsers?
2. A mobile app that requires the platform's own app to run?
3. A standalone Android/iOS app that we can build with our own branding and publish to Google Play / App Store?

I'm mainly interested in whether they can build real standalone mobile apps, not just mobile-friendly web apps.

Would appreciate answers from anyone who has actually used these platforms.

Three months ago I just wanted a Bible app that didn’t feel like a social network. No streaks, no notifications, no accounts, no clutter. Just a calm place to read and dig into the text when I felt like it.

That side project turned into Focused Word. It’s an open-source installable PWA that runs completely offline.

https://focusedword.com

Full disclosure up front: this whole thing was vibe-coded. I used AI heavily for almost everything — architecture, features, the parsers, the scrapers, the two backend services, debugging, all of it. I stayed in the loop and iterated a lot, but very little of the code was written the old-fashioned way.

What I aimed for

• Completely offline (Strong’s, cross-refs, word classes, everything)
• No accounts or tracking
• Installable on phone and desktop
• No build step — just native ES modules
• Chapter changes that feel instant

How it’s put together

I skipped frameworks and bundlers on purpose. Everything is plain modern JS.

The main glue is a simple Bridge (mediator + service registry). Modules register themselves on startup and talk to each other through direct calls or events. Kept things decoupled without dragging in a big state library.

Storage is split in two:

• Scripture, Strong’s, morphology, cross-references, etc. live in SQLite WASM (sql.js) on top of OPFS / Cache API
• User stuff (notes, highlights, bookmarks, reading progress) sits in IndexedDB

That split worked out well. The big reference data stays out of IndexedDB and queries stay fast.

For rendering I don’t store pre-made HTML. Chapters come back as token streams. A renderer builds a DocumentFragment in one pass (bionic reading, red letter, poetry layout, footnotes, the works) and drops it in. The extra study layers (word coloring, Clear Reading, Strong’s underlines) load in right after so the text shows up on the first frame.

The part that took longer than expected

A big chunk of the work wasn’t even the client. I ended up writing a bunch of parsers and scrapers to build the actual SQLite databases — Bible text, lexicon data, morphology, cross-references, word classes, summaries, all of it. Cleaning and normalizing that data properly took a lot more time than I thought it would.

I also built two smaller supporting projects:

1. A sync server that handles the private multi-device sync. You just get a 3-word passphrase generated from a Bible wordlist. No accounts, no email, no passwords.
2. A repo server that serves extra translation packages and study databases so people can download them on demand (with SHA-256 checks).

PWA side

Pretty standard service worker + manifest. Critical assets (fonts, the WASM binary, BSB data, lexicon) are cached hard so it actually works offline.

Stuff that surprised me

• You can get surprisingly far in 2026 with zero build tooling if you just stick to native ES modules
• OPFS + SQLite WASM is solid for this kind of reference data
• Making the first paint of a chapter feel instant meant I had to carefully cancel background study work when the user navigates away quickly
• The data pipelines and the two little servers ended up being a bigger part of the project than the frontend
• Vibe-coding a project this size actually worked better than I expected, as long as I kept directing it hard

It’s all MIT. Happy to answer questions about the architecture, the SQLite setup, the sync approach, or the general experience of building something like this mostly with AI.

What have other people run into with offline-first PWAs or SQLite WASM in production?