Add WordPress PWA Pull to Refresh, Wake Lock, and Haptics Without Theme Edits
You installed the PWA. Manifest is fine. Service worker is active. The home-screen tile looks like your brand. Then someone opens the app, pulls down expecting a refresh, and nothing happens. Or they leave a recipe page open while cooking and the screen dims mid-step. Or every tap feels like a silent web page, not a phone app.
That gap is what kills the “this feels installed” promise. Browser chrome is gone. Muscle memory stays. If pull-to-refresh, wake lock, and light haptic feedback are missing, the site still reads as a bookmark with a splash screen.
Progressify is the DaftPlug PWA plugin. This post covers three app-like controls you can turn on without editing the theme: pull to refresh, screen wake lock, and vibrations / haptic feedback on tap. Not push, not offline forms, not store bundles. For the wider app chrome (tab bar, transitions, toasts), keep WordPress PWA app-like UI with tab bar and page transitions nearby.
What Progressify actually ships here
Stay inside the real feature set:
- Pull to refresh: pull-down refresh gesture on the installed (and often browser) PWA surface
- Screen wake lock: prevent the screen from dimming while someone is on a page that needs eyes on it
- Vibrations / haptic feedback: light vibration on tap so interactions feel physical
- Supporting context OK to mention briefly (not the focus): tab bar, dark mode, page transitions, toast, skeleton loaders, idle detection, shake to refresh, fullscreen/splash
The contract is simple. Match the gestures people already expect from native apps. Do it from Progressify settings, not a child-theme pile of JS.
Why these three gestures matter more than another splash screen
A polished splash and icon get you onto the home screen. Retention is what happens after the second open.
Pull to refresh is the default recovery move on phones. Feeds, inboxes, and shop lists train people to yank the top of the viewport when something looks stale. If your PWA ignores that gesture, they hunt for a browser refresh that no longer exists in standalone mode. Frustration looks like “the app is broken.”
Wake lock matters on pages where the screen going dark is the bug. Recipes, workout timers, live score pages, kiosk-style menus, long how-to steps with the phone propped up. Without a wake lock, the OS dims on schedule and the visitor thinks your page died.
Haptics are small but loud. A short vibration on tap confirms “that button registered” when the network is slow or the UI is mid-transition. Native apps do this constantly. Silent taps feel like lag, even when the click already fired.
Together they close the last mile between “installable” and “feels installed.” Theme edits for the same behaviour fight updates, page builders, and caching plugins. Progressify keeps the switches in one place.
How to turn them on in wp-admin
Assume Progressify is installed and the PWA core (manifest + service worker + icons) already works. These gestures sit on top of a real PWA stack. Without that, you are decorating a normal mobile site.
1. Open Progressify app-like / interaction settings
In wp-admin, open Progressify. Find the app-like UI or interaction controls where pull to refresh, screen wake lock, and vibrations / haptic feedback live. You should see clear toggles for each, not a code box.
If the service worker is missing, fix that first. Chrome → DevTools → Application → Manifest and Service Workers. Progressify’s worker should be registered and active before you chase gesture bugs.
2. Enable pull to refresh where lists actually update
Turn pull to refresh on for templates that benefit from a manual reload: blog index, shop archive, search results, member feed, ticket list. Test in standalone mode (home-screen launch), not only in a normal browser tab.
Pull-to-refresh should reload meaningful content, not fight an infinite scroll library that already owns the same gesture. If your theme or a plugin also binds pull-down behaviour, pick one owner. Two handlers on the same gesture feel random.
On long article templates where people rarely need a hard refresh, leaving the gesture quieter (or testing carefully) avoids accidental reloads mid-read. Match the habit to the page type.
3. Turn on screen wake lock for “eyes on screen” pages
Enable wake lock when dimming is the problem: cooking, workouts, presentations, POS-style menus, live dashboards. You do not need it on every URL. A contact page that keeps the screen awake forever is wasteful and drains battery.
After enabling, open the target page on a real phone, wait past your normal auto-lock window, and confirm the screen stays lit while the page is in the foreground. Leave the page or background the app and confirm normal dimming returns. Wake lock should be scoped to the experience that needs it, not a global battery tax.
4. Enable haptic feedback on tap (keep it light)
Turn vibrations / haptic feedback on so primary taps feel confirmed. Good candidates: add to cart, tab bar items, primary CTAs, toast dismiss, key form submits.
Do not vibrate on every hover-equivalent or every scroll event. Phones already punish noisy haptics with user distrust. One short pulse on intentional taps is enough. Test with sound off so you are judging feel, not audio.
5. Smoke-test with the rest of the app-like kit nearby
Pull, wake, and haptics stack with tab bar, dark mode, page transitions, toast, skeleton loaders, idle detection, shake to refresh, and fullscreen/splash. You do not need all of them on day one. Turn on the three in this post first, then add chrome from the related app-like UI guide when the gestures already feel right.
6. Verify on Android and iOS separately
Install paths and gesture support differ by browser and OS. Test Android Chrome (standalone) and iOS Safari / Add to Home Screen. Confirm:
- Pull-down triggers a refresh where you expected it.
- Wake lock holds on the pages you chose.
- Taps pulse once, not in a buzz storm.
- Nothing breaks checkout, forms, or sticky headers.
If a gesture fails only in standalone, you are looking at display-mode behaviour, not a theme CSS bug. That is why Progressify’s switches beat pasting snippets into functions.php.
What good looks like
A finished setup feels boring in the best way:
- Pull-to-refresh works on feed and archive views in the installed PWA.
- Recipe, workout, or kiosk pages stay lit while in use, then dim normally when left.
- Primary taps give a short haptic confirmation without buzzing through entire pages.
- No theme child-file edits, no conflicting pull handlers, no wake lock on every URL.
- Tab bar / transitions / toasts (if enabled later) sit on top of gestures that already feel native.
- Visitors stop asking “how do I refresh this?” because the phone gesture they already know works.
If people still force-close the PWA to “fix” stale content, your pull target is wrong or the page is not actually refreshing useful data. Fix the content refresh path before you blame the gesture.
Pitfalls (the ones that bite)
Theme JS fighting pull-to-refresh. Two libraries owning the same pull-down gesture. Disable one.
Wake lock on every template. Battery complaints follow. Scope it to pages that need eyes on screen.
Haptic spam. Vibrating on scroll, hover, or every list item trains people to turn the feature off (or uninstall).
Testing only in a desktop browser. These behaviours are phone-first. Use real devices in standalone mode.
Skipping the service worker check. App-like gestures on a broken PWA still feel broken.
Expecting identical behaviour on every iOS version. Apple moves the goalposts. Retest after major OS updates.
Confusing shake to refresh with pull to refresh. Nearby feature, different gesture. This post is pull-down. Do not enable both as a substitute for fixing one.
Practical checklist before you call it done
- Confirm manifest + service worker are active.
- Enable pull to refresh and test on archive/feed templates in standalone mode.
- Enable screen wake lock only on pages where dimming is the bug.
- Enable haptic feedback on primary taps; keep pulses short and rare.
- Check for theme or plugin gesture conflicts on pull-down.
- Test Android Chrome and iOS Add to Home Screen separately.
- Confirm wake lock releases when leaving the page.
- Leave tab bar, transitions, toast, and the rest for a second pass if needed.
- Ask one real user to refresh a list and leave a recipe page open. Watch what they try first.
Takeaway
A WordPress PWA that ignores pull-to-refresh, dims mid-task, and stays silent on tap still feels like a website wearing an icon. The fix is not another theme edit. It is three Progressive Web App behaviours people already expect.
Progressify turns on pull to refresh, screen wake lock, and haptic tap feedback from wp-admin, next to the rest of the app-like toolkit when you are ready. Start with the gestures. Add chrome later.
One Pro membership unlocks Progressify plus Lightify, Generatify, Rankify, and Snapshotify. New Pro plugins join existing memberships. Plans differ by site count only. See pricing when you want the installed app to behave like one.
Ship the three toggles. Open the PWA from the home screen. Pull once, leave a long page open, tap a primary button. When those feel native, you closed the last-mile gap.