# How to Build a Mobile App with WeWeb: PWA and Responsive Apps

- Tool: WeWeb
- Difficulty: Intermediate
- Time required: 45-60 min
- Compatibility: WeWeb Free plan and above (Essential+ required for custom domain)
- Last updated: March 2026

## TL;DR

WeWeb builds installable Progressive Web Apps (PWAs) from the same project you design in the visual editor. Enable the PWA plugin from More → Mobile App, configure your app manifest, publish, and users can add your app to their home screen on iOS and Android. No app store submission required. For app store distribution, use PWABuilder to wrap your published WeWeb URL.

## Build a Mobile App with WeWeb Using PWA Technology

WeWeb does not generate native iOS or Android code, but it produces fully installable Progressive Web Apps (PWAs) that look and behave like native apps. A PWA is a website that can be added to a device's home screen, cached for offline use, and launched in full-screen mode without a browser bar. WeWeb's built-in PWA plugin handles the hard parts — generating the web manifest and service worker automatically. This tutorial walks you through enabling the plugin, designing a mobile-first UI with app-like navigation patterns, configuring offline behavior, testing on a real device, and optionally submitting to app stores via PWABuilder.

## Before you start

- A WeWeb account (Free plan or above)
- A published WeWeb app with a custom domain (Essential+ plan needed for custom domain, required for PWA install prompt on most browsers)
- Basic familiarity with the WeWeb visual editor and breakpoint switching
- A smartphone for testing the installable experience

## Step-by-step guide

### 1. Enable the PWA Plugin

In the WeWeb editor, click the More icon (three-dot menu or grid icon) in the left navigation bar, then select Mobile App. This opens the PWA configuration panel. Toggle Enable PWA to ON. WeWeb will automatically generate a web app manifest and register a service worker when you next publish your project. The PWA plugin is available on all plan tiers. Note: the install prompt only appears reliably when your app is served over HTTPS on a custom domain — the default WeWeb subdomain (*.weweb.app) works for testing but a custom domain is strongly recommended for production.

**Expected result:** PWA is toggled ON and the manifest/service worker settings panel is visible.

### 2. Configure the App Manifest

In the PWA settings panel (More → Mobile App), fill in the required manifest fields. App Name: your full app name (e.g., 'TaskFlow'). Short Name: displayed under the icon on home screen, max 12 characters (e.g., 'TaskFlow'). Start URL: leave as '/' unless your app starts on a specific page. Display mode: choose Standalone to remove the browser bar. Theme Color: sets the status bar color on Android (enter a hex value matching your brand). Background Color: splash screen background while app loads. Upload an App Icon — minimum 512x512px PNG, no transparency for iOS compatibility. WeWeb uses this to auto-generate all required icon sizes in the manifest.

**Expected result:** Manifest fields are complete. Icon is uploaded and previewed correctly in the panel.

### 3. Design for Mobile-First Using Breakpoints

Switch to the Mobile breakpoint by clicking the device icons in the top editor toolbar (Desktop → Tablet → Mobile). All layout changes made in Mobile view apply only to mobile — they do not affect Desktop. Build your mobile layout with vertical stacking: set containers to flex-direction Column, use full-width (100%) elements, and apply adequate touch targets (minimum 44px height for interactive elements). In the Styling panel, switch units from px to % or vh/vw for fluid sizing. Avoid fixed widths. For cards and list items, set padding to at least 16px on each side for comfortable thumb reach. Remember: deleting an element while in Mobile view deletes it from ALL breakpoints — use display:none binding or Conditional Rendering instead to hide elements on mobile only.

**Expected result:** Your app looks clean and usable in the 375px-wide Mobile preview.

### 4. Add Bottom Navigation for App-Like Feel

In the editor, click the Add panel (+) in the left sidebar, search for 'Bottom Navigation', and drag it onto your page. Place it in a multi-page section so it appears on every page: right-click the Bottom Navigation container → 'Convert to multi-page section' → select all pages where it should display. Configure each nav item with an icon, label, and On Click workflow action set to Navigate to page (select your target page). To show the active state, create a Page-level variable named 'activePage' (Data panel → Variables → New → Text), set it to the current page name On page load, and bind each nav item's active style to a condition: activePage == 'Dashboard'. Bottom Navigation should be position sticky, bottom: 0, with a z-index above content.

```
// Workflow JS action on page load — paste into Custom JavaScript action
// Injection point: On page load workflow → Add action → Custom JavaScript
return { activePage: 'dashboard' };
// Then use 'Change variable value' action to set the activePage variable
```

**Expected result:** Bottom navigation bar appears fixed at the bottom, highlights the active tab, and navigates between pages on tap.

### 5. Configure Offline Caching

The WeWeb PWA service worker handles caching automatically when you publish. By default, it caches your app's shell (HTML, CSS, JS) using a cache-first strategy, so the app loads from cache when offline. Dynamic data from your backend (Supabase, REST API) is NOT cached by default — users see empty collections when offline. For read-heavy apps where some offline access is valuable, store key data in App-level variables after fetching: In your collection fetch success workflow, add a 'Change variable value' action to write the collection data into an App variable (Data panel → Variables → New → Array). On page load, check if the collection is empty and fall back to the cached variable. Note: iOS Safari on versions below 16.4 does not support push notifications from PWAs, and some PWA installation prompts behave differently on iOS compared to Android.

**Expected result:** App loads its shell (navigation, layout) when device is offline. Cached data displays where implemented.

### 6. Test on a Real Device

Publish your WeWeb app: click the Publish button (top-right cloud icon) → Publish to production. On your Android device, open Chrome and navigate to your published URL. Chrome will show an 'Add to Home Screen' banner or you can tap the three-dot menu → Add to Home Screen. On iOS, open Safari, navigate to your URL, tap the Share icon (box with arrow) → Add to Home Screen. After installing, launch from the home screen icon — it should open in standalone mode without browser chrome. Test all navigation, forms, and data loading in the installed context. Check that the splash screen and theme color display correctly. If the install prompt does not appear on Android, verify: HTTPS is enabled, manifest is valid (check via Chrome DevTools → Application → Manifest), and service worker is registered.

**Expected result:** App is installable from the browser, launches from home screen in full-screen standalone mode.

### 7. Submit to App Stores via PWABuilder (Optional)

For Google Play Store and Apple App Store distribution, use PWABuilder (pwabuilder.com — free Microsoft tool). Navigate to pwabuilder.com, enter your published WeWeb app URL, and click Start. PWABuilder analyzes your PWA score and generates native wrappers. For Android: click 'Package for stores' → Google Play → Download package → follow the signing and upload instructions for Google Play Console (requires a $25 one-time developer account fee). For iOS: PWABuilder generates an Xcode project that wraps your PWA in a WKWebView — this requires a Mac with Xcode and an Apple Developer account ($99/year). Note that Apple's review process is stricter for PWA wrappers — ensure your app provides genuine value beyond a website.

**Expected result:** PWABuilder reports a high PWA score and generates platform-specific packages ready for store submission.

## Complete code example

File: `pwa-offline-cache.js`

```javascript
// Injection point: On page load workflow → Custom JavaScript action
// Purpose: Cache key collection data into an App variable for offline fallback
// Run this AFTER your collections have been fetched

// Step 1: In WeWeb, create an App-level variable named 'cachedProducts' (Array type)
// Data panel → Variables → New → Array → name: cachedProducts → scope: App

// Step 2: Add this Custom JavaScript action AFTER your Fetch Collection action
// in any On page load workflow

const products = variables['productsCollection'].data;

if (products && products.length > 0) {
  // Store to localStorage as a backup for offline
  try {
    localStorage.setItem('cachedProducts', JSON.stringify(products));
  } catch (e) {
    // localStorage might be full — fail silently
    console.warn('Could not cache products to localStorage', e);
  }
  return { cached: true, count: products.length };
}

// If collection is empty (offline), try to restore from localStorage
const stored = localStorage.getItem('cachedProducts');
if (stored) {
  try {
    const parsed = JSON.parse(stored);
    // Use 'Change variable value' in next workflow step to set cachedProducts variable
    return { cached: false, fallback: parsed, count: parsed.length };
  } catch (e) {
    return { cached: false, fallback: [], count: 0 };
  }
}

return { cached: false, fallback: [], count: 0 };

// Step 3: Add 'Change variable value' action after this JS action
// Variable: cachedProducts
// Value: bind to the workflow return value → fallback array
```

## Common mistakes

- **Building the layout on Desktop and expecting it to look good on Mobile automatically** — undefined Fix: Switch to Mobile breakpoint early and design mobile layouts explicitly. Desktop styles cascade down, but a complex multi-column desktop layout will overflow on a 375px screen. Always preview in Mobile view before publishing.
- **Using fixed pixel widths (e.g., width: 400px) for containers intended for mobile** — undefined Fix: Use percentage widths (100%) or viewport units (vw) for containers on mobile. In the Styling panel, switch the unit dropdown from px to % when setting widths.
- **Expecting the PWA install prompt to appear on the WeWeb default subdomain during development** — undefined Fix: The browser's A2HS (Add to Home Screen) prompt requires HTTPS and, in practice, a real custom domain. Use your published production URL with a custom domain for accurate install prompt testing.
- **Forgetting that iOS Safari handles PWAs differently from Android Chrome** — undefined Fix: iOS does not show an automatic install banner — users must manually use Share → Add to Home Screen. Push notifications require iOS 16.4+. Test on both platforms. Include onboarding text explaining how to install on iOS.

## Best practices

- Always design and test in Mobile breakpoint first — switch from Desktop to Mobile view at the start of every design session
- Use 44px as the minimum touch target height for all interactive elements (buttons, links, nav items) to comply with Apple HIG and Material Design guidelines
- Add a splash screen instruction tooltip or onboarding modal explaining how to install on iOS, since there is no automatic install prompt on Safari
- Keep your PWA icon simple and recognizable at small sizes — test it at 48x48px to ensure it reads clearly on a home screen grid
- Limit the number of network requests on the initial page load to reduce time-to-interactive on mobile networks — use lazy collection fetching where possible
- Use Conditional Rendering (not CSS display:none) to remove heavy components from the DOM on mobile to improve performance
- Test with Chrome DevTools' device emulation AND a real device — emulation does not accurately simulate touch gestures, install prompts, or iOS-specific behavior

## Frequently asked questions

### Does WeWeb generate a native iOS or Android app?

No. WeWeb generates a Progressive Web App (PWA), which is a web application that can be installed on a device's home screen and run in full-screen mode. It is not a native app. For native app distribution via app stores, you can use PWABuilder to wrap your published WeWeb URL in a native shell, but the underlying technology remains a web app.

### Can WeWeb PWAs receive push notifications?

On Android (Chrome), push notifications are supported if you implement a push notification service (e.g., via Supabase Edge Functions + Web Push API). On iOS, push notifications from PWAs require iOS 16.4 or later. Users must have explicitly added the app to their home screen — push notifications do not work from browser tabs on iOS regardless of version.

### Will my PWA update automatically when I publish changes in WeWeb?

Yes. When you publish an update in WeWeb, the service worker detects the new version and updates the cached files. Users see the new version the next time they launch the app after a full close and reopen. You can add a 'New version available — tap to refresh' banner using a Custom JavaScript action that listens to the service worker's updatefound event.

### Does the WeWeb PWA work without an internet connection?

The app shell (HTML, CSS, JavaScript) is cached and loads offline. However, dynamic data from your backend (Supabase, REST APIs) requires an internet connection to refresh. You can implement a localStorage fallback as shown in this tutorial's complete code example to display the last-fetched data when offline.

---

Source: https://www.rapidevelopers.com/weweb-tutorial/build-mobile-app-weweb
© RapidDev — https://www.rapidevelopers.com/weweb-tutorial/build-mobile-app-weweb