How to Build Progressive Web Apps in Joget (2026)
Date
Aug 22, 26
Reading Time
13 Minutes
Category
Joget Development

Your warehouse supervisor needs to log a stock discrepancy from the floor, where the signal drops. Your field technician closes out a job in a basement. Your insurance assessor photographs damage in a village with one bar of coverage.
Give any of them a normal web app and the submission fails. Give them a native app, and you're funding two codebases plus an app store review cycle every time you change a dropdown.
A Progressive Web App solves that middle case. It runs in the browser, installs on the home screen, works offline, and updates without anyone needing to download anything.
Joget builds these by default. Publish a Joget DX app over HTTPS, and you get the manifest and the service worker without writing either. Your job is to configure the pieces Joget can't guess, then test the parts that break.
I'll cover the setup, the layout, offline behavior, testing, publishing, and where PWAs still fall short. That last part matters more than most guides admit.
A Progressive Web App in Joget is a Joget DX application that behaves like an installed mobile app. Joget generates the web app manifest and service worker when you publish over HTTPS, so users can add the app to their home screen, open it in standalone mode, view cached pages offline, and receive push notifications.
Nothing gets coded. You toggle settings in the Userview builder and configure the manifest fields Joget pulls from your app metadata.
What Makes an App a PWA?
Five capabilities separate a PWA from a mobile-friendly website.
Installable. The web app manifest lets users add the app to their home screen or applications menu, then launch it full screen without browser chrome.
Works offline. A service worker caches the app shell and data, so screens still load even without a connection.
Fast. PWAs load from cache and respond without the lag of a round trip to the server on every tap.
Push notifications. With user permission, the app can alert someone to a pending approval even when it is closed. Joget handles this through its notification plugins.
Responsive. Joget's UI components adapt across phone, tablet, and desktop, so one build covers all three.
The Technical Minimum
Four things must be true for a browser to treat your app as installable:
Served over HTTPS, not HTTP and not a bare IP address
A valid web app manifest with name, icons, start URL, and display mode
A registered service worker
Icons at the sizes browsers expect, including a 512x512 PNG
Joget generates items two and three for you. You supply the HTTPS and the icon.
Setting Up Joget Before You Build
Get the version and the environment right first.
Version. Use Joget DX 7 or later. DX 9 is the current release and has the most complete PWA and offline configuration.
Cloud or self-hosted. Joget Cloud gives you an HTTPS URL from the first minute, making it the fastest path for a first PWA, since you can test installability without configuring certificates. Self-hosting gives you control over data residency and custom plugins, and you'll need a database (MySQL or PostgreSQL), a servlet container like Tomcat, and a supported JDK for your DX release.
Check the release notes for the JDK version before provisioning. The supported Java version changed across DX releases, and guessing here costs you an afternoon.
Mobile view. Joget's Universal Theme handles responsive layout for forms and pages, so your app renders on a phone without custom CSS. Confirm your chosen theme is one of the DX themes that supports offline caching, because an unsupported theme breaks offline behavior even when every other setting is right.
For the install walkthrough itself, our Joget development guide covers the environment build step by step.
Designing the PWA Layout in Joget
Design for a thumb on a phone in bad light, not a mouse on a 27-inch monitor.
Building the UI
Joget's Form Builder handles data entry with drag-and-drop fields. The Userview and Page Builder handle navigation and structure. Datalist gives you searchable, filterable tables when someone needs to find a record rather than create one.
Four things I'd hold to:
- One purpose per screen. A form that captures a job completion shouldn't also show last month's metrics.
- Short labels and clear icons. Long field labels wrap badly at phone width and push your submit button below the fold.
- Form rules to show and hide fields. A 40 field form that reveals eight fields at a time feels like an eight field form.
- Access control per role. A technician and a supervisor open the same app and should see different menus.
Where Joget Won't Help You
Joget doesn't wire up camera, GPS, or biometrics for you. File and image upload fields work out of the box, and a file input on a phone opens the camera, which covers most photo-capture needs. Anything past that means a custom plugin or a JavaScript integration.
That's a real boundary. If your app depends on continuous background location or Bluetooth hardware, a PWA is the wrong shape and you want a native build or a wrapped container.
Enabling PWA Features in Joget
Joget DX turns PWA support on by default. In the Userview builder, you'll find toggles for Disable PWA and Disable Push Notifications, which tells you where the defaults sit.
The Manifest
Joget generates the manifest from your app metadata. Four fields deserve your attention:
App name and description. These appear in the install prompt. "Field Service" reads better on a home screen than "app\_fs\_v2\_prod."
Icon. Upload a square PNG with a minimum size of 512x512. Joget applies it across the manifest and the device home screen.
Theme and background colors. Joget derives these from your UI theme. Override them to match the brand if the defaults look off.
Start URL. Joget sets this to your app homepage. Open the installed app and confirm it lands where you expect it to, because an incorrect start URL sends every user to a blank menu.
Splash Screen
Joget displays your app icon against a background that matches the theme color. For most apps that's enough. A fully custom splash screen means editing the manifest or adding a plugin, and I'd skip it on a first build.
Push Notifications
Push is what makes an approval workflow feel live instead of something people check twice a day.
The client side comes free, since Joget's service worker handles incoming push messages. On the server side, you configure the Default User Notification plugin or a dedicated push plugin under Properties and Export in App Center. Then you add a notification step in Process Builder so that an alert fires when a task is assigned or an approval is cleared.
One constraint worth planning around: iOS supports web push starting with iOS 16.4, and only after the user adds the app to their home screen. A Safari user who never installs the app gets no push at all. If your users are on iPhones, your install prompt is a prerequisite, not a nice-to-have.
Our post on building workflows with Process Builder in Joget covers configuring the notification step within the process itself.
How Do You Add Offline Support to a Joget PWA?
Enable offline support in the Performance and Offline settings of your Joget app, then pick a DX theme that supports offline caching. Joget caches the app shell and list data for reading, queues form submissions in IndexedDB when the network drops, and syncs them to the server through Background Sync once the connection returns.
Here's what each piece does and what Joget handles for you.
| Offline capability What it does How Joget handles it | ||
|---|---|---|
| App shell caching | Screens and UI load with no connection | Caches dashboard, forms, and lists on first visit |
| Data caching | Previously loaded lists and records stay viewable | Caches page and list data as read-only |
| Offline submission | Users complete forms with no signal | Queues submissions in IndexedDB, syncs when online |
| Background sync | Actions survive a mid-process network drop | Processes queued items once connectivity returns |
| User feedback | People know their input was saved, not lost | Built-in offline messaging on submission |
| Configuration | Usually a manual service worker build | A checkbox in Performance and Offline settings, plus optional URL cache config |
Read-only is the important caveat in row two. Cached list data reflects what loaded last time someone was online. A technician looking at a cached job list at 4pm may be looking at the 8am version, so design around that rather than assuming freshness.
A Worked Example: Field Service
Four stages, one technician, one day:
Morning, on wifi. She opens the app. Joget caches the shell, her assigned jobs, and the completion forms.
Midday, in a basement with no signal. She fills out the job completion form and submits. Joget writes it to IndexedDB and shows a confirmation instead of an error.
Afternoon, back on cellular. Background Sync pushes the queued submission to the server. She does nothing.
Server side. The Joget process marks the job complete and notifies her supervisor.
The technician never learns what IndexedDB is. That's the measure of whether you configured it right.
How Do You Test a Joget PWA?
Test installability in Chrome or Edge over HTTPS; verify that cached pages load with the network disabled; submit a form offline and confirm it syncs on reconnect; repeat on Android and iOS; then run a Lighthouse audit to catch unmet install criteria.
Skip any of those, and you'll find the gap in production.
| Desktop Mobile DevTools | ||
|---|---|---|
| Open in Chrome or Edge over HTTPS | Open in Chrome on Android, Safari on iOS | Application tab, check manifest fields |
| Confirm the install option appears in the address bar | Add to Home Screen | Confirm the service worker is active |
| Verify app name and icon in the prompt | Launch in standalone mode | Inspect Cache Storage contents |
| Walk navigation and submit a form | Test forms, file upload, push permission | Check IndexedDB for queued submissions |
| Switch to offline, confirm cached pages load | Airplane mode, submit offline, then reconnect | Run a Lighthouse PWA audit |
Test iOS separately and early. Safari's PWA support differs from Chrome's in ways that surface late: push needs 16.4 and a home screen install, and storage eviction rules are stricter. Finding that a week before launch is a bad week.
Publishing Your Joget PWA
Publishing means a stable HTTPS URL and users who know how to install it.
Hosting. Use your Joget Cloud URL or point a domain at your self-hosted server. Publish the app from the console so it's reachable outside your network.
HTTPS. This is non-negotiable, since service workers won't register over HTTP or on a bare IP. Get a certificate (Let's Encrypt is free), then terminate SSL at Nginx, Apache, or Tomcat. Joget doesn't manage certificates itself. Load the app and confirm there are no mixed-content warnings, because a single HTTP asset on an HTTPS page breaks the service worker.
Integrations. Confirm your process connections to CRM, ERP, or accounting systems point at production endpoints, not the staging ones you tested against.
Getting Users to Install It
Most users won't know what a PWA is, and some will ask whether it's an app or a website. Answer plainly: it's a web app they can install, use offline, and never update manually.
Chrome shows an install prompt on its own after a few visits. You can also add a page inside the app explaining the manual route, something like "tap the menu, then Add to Home Screen." That help page does more work than a custom install button in my experience, and it costs ten minutes.
Lead with the benefit rather than the mechanism. Offline access, one-tap launch, and push alerts land better than "installable web application."
Updates propagate on their own. Joget's service worker refreshes the cache when you publish a new version, so users get the current build on next launch with no store review and no download.
If you later need app store presence, you can wrap the PWA in Cordova or Capacitor. Treat that as a distribution decision, not a technical requirement.
Troubleshooting Common Joget PWA Problems
Five issues cover most failures.
| Problem Usual cause Fix | ||
|---|---|---|
| Offline mode does nothing | Offline support disabled, unsupported theme, or serving over HTTP or an IP | Enable offline in Performance and Offline settings, switch to a supported DX theme, confirm HTTPS with a real domain |
| App won't install | Manifest missing name, icons, or start URL, or HTTPS not active | Open DevTools, Application, Manifest to read the specific error, then run Lighthouse for unmet criteria |
| Offline submissions never sync | Device never regained a route to the server, or sync failed without a retry | Check IndexedDB in DevTools for stranded records, add a manual sync or refresh fallback in the UI |
| Push notifications don't arrive | Permission denied, plugin misconfigured, or iOS below 16.4 or not installed to home screen | Check browser and OS permissions, test-fire from the notification plugin, confirm the iOS user installed the app |
| Manifest or service worker errors | A custom manifest edit broke validity, or a stale worker is cached | Read the DevTools console and Application panel, clear site data to reset, reload twice |
Real Joget PWA Deployments
Two documented deployments, described as their sources describe them.
SSI Securities: CRM Support and Mobile Onboarding
SSI Securities Corporation, a financial services firm, worked with Joget partner International Distribution Corporation (IDB) to replace legacy CRM systems that only ran on desktops and made customer request forms slow to create and change.
The Joget build centralized data from multiple sources and added permission control over access. SSI reported an 80% reduction in time spent searching for information, and staff stopped toggling between applications to resolve a single customer ticket. PWA capability let them run the client onboarding process from mobile devices.
Worth noting what that 80% measures. It's search time for information, not approval speed or reporting delay. The gain came from centralizing fragmented data, with the PWA layer making it reachable on a phone.
Malaysia Airlines: Government Travel Workflow
Malaysia Airlines built a no-code workflow system on Joget to handle government official travel. It manages travel requests, approvals, agent assignment, and e-ticket printing, and integrates with their SAP instance, a Global Distribution System, and government accounting systems. The system matches warrants against tickets for reconciliation and billing, with reporting on top.
I'm including this as a Joget workflow deployment rather than a PWA case, because the published material describes the workflow and integration layer without documenting PWA delivery. The integration pattern is the transferable part: a Joget process sitting between a public-sector approval chain and two enterprise systems that were never designed to communicate with each other.
Bottom Line
A Joget PWA is the right call when your users work on phones, sometimes without signal, and you don't want to fund a native app to get there. Field service, warehouse floors, claims assessment, inspections, approvals on the move.
It's the wrong call when you need deep hardware access, continuous background location, or app store discoverability as an acquisition channel. And iOS remains the weak spot, with push gated behind 16.4 and a home screen install, and tighter storage eviction than Android.
Know those limits going in, and a PWA saves you a second codebase. Ignore them, and you'll rebuild native in a year.
Start with one app. Enable offline mode, test on a real iPhone and a real Android device before you show anyone, and ship it to a small group first.
Working with a Certified Joget Partner
Relinns builds Joget applications as a certified DX 9 partner, with enterprise deployments across the UAE, EU, and US.
What our clients see:
- 90% of workflows we build need zero coding from your team
- 40% faster deployment than traditional development
- 75% fewer process errors after automated validation and structured testing
- Integrations with 95% of the enterprise systems we've encountered
- 60% quicker iteration cycles, so changes ship in days
Get a free Joget consultation, and we'll tell you on the call whether a PWA fits your use case or whether you need something else.
Frequently Asked Questions
How is a Progressive Web App different from a native mobile app?
A PWA runs in the browser and installs from a URL, so there's no app store submission, no review cycle, and one codebase for iOS, Android, and desktop. Native apps get deeper hardware access and greater visibility into storage. PWAs update automatically, since users receive the latest build at the next launch.
Can a Joget PWA securely handle enterprise workloads?
Yes. Joget provides role-based access control, audit trails, and encrypted data handling, and self-hosted deployments let you control data residency for GDPR, HIPAA, or UAE PDPL obligations. Performance at scale depends on database tuning and infrastructure sizing rather than on PWA configuration.
Do Joget PWAs work across all browsers and devices?
Joget's responsive themes adapt across phones, tablets, and desktops, and Chrome, Edge, and Safari all support installation. Safari lags on push notifications, which need iOS 16.4 or later plus a home screen install, and it applies stricter cache eviction rules than Chrome on Android.
Which industries get the most from Joget PWAs?
Field services, logistics, healthcare, banking, and insurance see the strongest fit, because their staff works away from desks and often without reliable connectivity. Common builds include job completion forms, inspection checklists, claims intake, stock counts, and mobile approvals.
How does a PWA compare on cost to native development?
A PWA removes app store fees, separate iOS and Android codebases, and release cycles tied to store review. Joget's low-code builder further reduces build time, since you configure forms and processes instead of writing them. Total cost sits below native for most internal business applications.
Can a Joget PWA integrate with a CRM or ERP?
Yes. Joget's API Builder and plugin ecosystem connect to Salesforce, SAP, HRMS platforms, and internal databases. The Malaysia Airlines travel system, for example, integrates a Joget workflow with SAP, a Global Distribution System, and government accounting systems.
Does offline mode work for reading data as well as submitting forms?
Both, with a caveat. Joget caches list and page data for offline reading, but that cache is read-only and reflects the last online load. Form submissions queue in IndexedDB and sync once connectivity returns, so writes are reliable while reads may be stale.



