Will Mobile App development still be a path going forward in Wappler 8? I can't see that path being used often, if at all anymore with Wappler. Would love to see some PWA features added though.
3 Likes
I’m a big PWA fan, I’d like to see more integration with Wappler too.
3 Likes
As PWAs become more central to modern app workflows, there are a few areas where Wappler could really shine even brighter. Things like stronger service‑worker tooling, smarter offline rules, secure local storage, multi‑tenant‑aware caching, and a more integrated PWA build pipeline would make a huge difference, especially for projects where security, Docker, and database‑driven logic all play a major role.
These additions would help streamline development, reduce boilerplate, and make Wappler an even more powerful platform for building robust, installable web apps.
Stop enriching app stores for simply existing — keep your revenue where it belongs: in your app, not their pockets.
Here are some suggestions for the Wappler Team to consider:
-
First‑Class Service Worker Management
A visual editor for common caching strategies, auto‑generated precache, and built‑in debugging. -
Route‑Level Offline Rules
Easily define which pages and APIs work offline, and which forms queue submissions for when you’re back online. -
Background Sync & Task Queue UI
A friendly interface for queued actions, automatic retries, and sync triggers. -
Secure Local Storage Abstractions
Encrypted local storage, schema‑based local DB, and automatic sync — perfect for multi‑tenant apps. -
Multi‑Tenant Aware Caching
Partitioned caches per tenant and automatic invalidation when switching tenants. -
Docker‑Aware PWA Build Pipeline
Tie PWA logic into the new deployment flow, with build‑time asset hashing and environment‑specific rules. -
Push Notifications
Unified interface for managing web push subscriptions and sending tenant‑scoped notifications. -
PWA Installability Dashboard
One place to check manifest, icons, SW status, and installability. -
App Shell Generator
Quickly build a cached shell with tenant‑aware modules and offline fallbacks. -
PWA‑Specific Security Controls
Offline auth, token refresh, and tenant‑scoped security policies.
3 Likes
lol, I have no idea what all of that means but numbers 7 and 8 seem like something I need. 
1 Like
Ben you are the best always. Regards from Mexico
1 Like
For me, in @ben s post above, the points: 2,3,4 and 5 are pretty critical to any PWA, currently Wappler has no easy way to create these. It would be a massive boost if they could be implemented.
Hi Ben, Brad, TMR,
Thanks, all of you. This thread helped us decide what to build first, so let me answer Brad's
question, then take Ben's list with TMR's four priorities, and say what I will post next.
Mobile stays, and it gets simpler. When you create a project in Wappler 8 you choose its kind once: a website or web application, a mobile app, or an API backend. A mobile app is built with the same App Connect you use on the web, with Framework7 or Bootstrap, and ships in a native shell. Capacitor is the runtime; Cordova is deprecated, a Cordova project still opens for editing and can be converted with one reviewed step. In Setup a mobile app gets a Platforms group with Web, Android and iOS as pages: whether the native project exists, the app ID and build number derived from one App page, icons and splash generated from one source image, and the permissions your plugins need listed per platform. Plugins are added like extensions, and when iOS needs a usage text, Setup asks you for it instead of patching native files silently.
Two projects, one solution. In Wappler 7 an app and its backend were two projects that knew nothing of each other. That stays two projects, because they release on different schedules, but Wappler 8 groups them in a solution: one entry in the project list, the backend's URLs derived instead of typed, the CORS origins applied to the backend as a reviewed change, and when you press Run on the app, the backend's dev server starts first and the app on your phone or emulator reaches it at the right address. The new project wizard creates both together when you pick the Mobile app goal. Your existing Wappler 7 projects open as they are, nothing is migrated on open, and Wappler 7 can keep opening them during the beta.
Before you can run. This is new and it matters most for mobile. A project tells you, in one
ordered list, what still has to happen before Run works: what you do (a tool this computer lacks, Android Studio or Xcode included, checked when you ask and installed on demand; a password the project needs) and what Wappler does for you (install the modules, update the assets, create the containers, generate the native project), with who, when and progress. The count sits on the Setup item until the list is done; nothing runs when a project opens and nothing runs silently. A team member who clones a project from your repository sees the same list, starting with the passwords and keys the repository never carried. It replaces Wappler 7's system check and the installs that happened whenever the toolbar refreshed.
PWA: the installable web app. This is the part Brad and TMR asked for. Every website gets an "Installable app" switch; your site stays a site and gains what an installed app needs. A mobile app can optionally publish itself from a URL as well, the same code with web fallbacks for the plugins. We build it in three steps, in this order:
- Installable. The manifest and icons generated from what you already typed, a readiness list that says exactly what is left ("Installable: 1 to finish · HTTPS on Production"), and a check
after publishing. Ben's number 8, without a separate dashboard, and the first half of what Brad needs. - Push notifications. One resource in Setup, one Server Connect module (save subscription, send), one App Connect component (permission, subscribe, the notification), Web Push for the installed web app and Firebase Cloud Messaging for Android and iOS. Ben's number 7, the other half for Brad.
- Offline. Three presets rather than a rule editor: none, app shell (layouts, assets and an offline page cached, pages network-first), or cache what is visited; Server Connect actions are never cached; update on next start or ask the user.
TMR's four, then the rest of Ben's list. TMR is right that there is no easy way to build points 2 to 5 in Wappler today. Here is where each lands:
- Route-level offline rules (2): yes, as include and exclude patterns on top of the presets, so you say which pages and files are cached and which are not. Forms that queue while offline are part of the next point.
- Background sync and a task queue (3): we will not build a UI that promises it. The Background Sync API does not exist on iOS, and a feature that works on half the phones ends up as support tickets. Queueing a form while the app is open and sending it when the connection is back is application logic you can build with the local database below and a flow; once the three steps ship we will look at a "queue when offline" option on the form itself.
- Secure local storage and a schema-based local database (4): yes, as a Local database
resource: SQLite on the device, its schema managed in Data like any database, encrypted at
rest. Automatic sync with the backend: no, which records move when is your application's design; PouchDB replication remains available for that. - Multi-tenant caching (5): no. The service worker sees URLs, not tenants; a tenant in the URL partitions the cache by itself, a tenant in a cookie or token cannot be told apart by the worker.
The rest: a visual service worker editor (1), no, the three presets plus the source view, and the
browsers debug workers better than we could; Docker-aware build pipeline (6), nothing to add, the environment's build plan already covers it; push, tenant-scoped (7), yes, scoping is a filter on the subscriptions table; app shell generator (9), that is the app shell preset; offline auth and token refresh (10), no, an offline app shows its cached pages and says it is offline, sessions belong to the backend.
What I will post next. As we did for Setup, the walkthrough journeys with a picture per step: Setup for mobile apps with the native shells, the new project wizard (with the Mobile app goal creating the app and its backend together), and project readiness. They go to the ambassadors first for a review round, then here, so you can tell us where a step feels wrong before we build it. This is a development preview and none of it is available to try yet. If you want to add to the list, I am opening a separate topic for mobile and PWA wishes so this thread stays readable.
George
4 Likes
Thanks for that very comprehensive rundown @George
it’s great see this process taking shape. What a massive amount of work this is, it’ll definitely be worth it in the end.
Wappler V7 is an excellent bit of kit, but it has grown organically over the years through continuous additions and updates. Now feels like the perfect time for a fresh start, ironing out some of the quirks and rough edges that have naturally appeared along the way.
2 Likes
Couch & Pouch DB will help a lot towards 3 -5
1 Like