Skip to main content
Percher is still being built, but you can try it out with a free account right now!

Publishing to the App Store & Google Play

Use Percher as the backend/web layer for a store app

Can I publish my Percher app to the Apple App Store or Google Play? Not directly — and that's by design. Percher doesn't submit apps to the stores for you. What it does is host your app on the web — and, once you add a web manifest and a service worker, as an installable PWA (Path 0 below), so the simplest option needs no store at all: users add it to their home screen, offline-ready. But you can take a Percher-hosted app into the stores — keep Percher as the web + backend layer and put a thin store app on top. There are three common paths, all built on top of the PWA step.

External facts below (fees, review rules) are moving targets — each is sourced and datestamped; re-check the official link before you rely on it.

Path 0 — Just make it a great PWA (start here, no store needed)

Add a web manifest and a service worker so your Percher-hosted app is installable to the phone home screen and works offline. For many apps this is the whole answer — no developer account, no store review, no fee. Everything below is optional and builds on this.

<!-- link a manifest from your HTML -->
<link rel="manifest" href="/manifest.json">

manifest.json starter:

{
  "name": "My App",
  "short_name": "MyApp",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#2d6a4f",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

Register a service worker so the app is installable and works offline:

if ("serviceWorker" in navigator) {
  navigator.serviceWorker.register("/sw.js");
}

This works on the shared name.percher.run subdomain or a custom domain.

Path A — PWA to Google Play (TWA)

Wrap an installable PWA in a Trusted Web Activity (TWA) to get a real Android app (.aab) you can list on Google Play. It's the cheapest store path — you reuse the PWA from Path 0. Android only: Apple doesn't support TWA.

# generate the Android project, pointed at your manifest
npx @bubblewrap/cli init --manifest https://your-app.percher.run/manifest.json
npx @bubblewrap/cli build

Or use PWABuilder — paste your app URL and it produces the Android package.

A TWA needs Digital Asset Links to verify you own the origin (and to hide the browser URL bar). Serve /.well-known/assetlinks.json on your app's origin:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "app.percher.yourapp",
    "sha256_cert_fingerprints": ["<your signing cert SHA-256>"]
  }
}]

Fill in package_name and the SHA-256 fingerprint after you create and sign the Android app — they don't exist until then. Add the file to your app's own static output.

Path B — Webview wrapper (Capacitor) to both stores

Wrap your web frontend in a native shell that loads your Percher app (or bundles the frontend and calls Percher as an API) and adds native plugins. One codebase, both stores.

Apple Guideline 4.2 (minimum functionality): a bare webview wrapper is frequently rejected. Add genuine native value — push notifications, camera, offline support, native navigation — not just a website in an app shell.
npm install @capacitor/core @capacitor/cli
npx cap init

capacitor.config.ts (point at your Percher app):

import type { CapacitorConfig } from "@capacitor/cli";
const config: CapacitorConfig = {
  appId: "app.percher.yourapp",
  appName: "My App",
  webDir: "dist",
  server: { url: "https://your-app.percher.run", cleartext: false },
};
export default config;

Then add platforms: npx cap add ios and npx cap add android.

Path C — Native frontend, Percher backend

Build a real native app (React Native, Flutter, Swift, or Kotlin) that only talks HTTPS to your Percher app as its API/PocketBase backend. It's the most work but the cleanest path through Apple review — and it's Percher's sweet spot: backend-as-a-service for your store app.

const API_BASE = "https://your-app.percher.run";
// PocketBase apps: use POCKETBASE_PUBLIC_URL from the app's env

Your data model, auth, and file storage stay in PocketBase exactly as on the web. For iOS universal links, serve /.well-known/apple-app-site-association (a JSON file, no extension, served as application/json) on your origin:

{
  "applinks": {
    "apps": [],
    "details": [{ "appID": "TEAMID.app.percher.yourapp", "paths": ["*"] }]
  }
}

Which path?

What you have / wantStart hereWhy
A web app you just want on phonesPath 0 (PWA)installable + offline, no store, no fees
It on Google Play, as cheaply as possiblePath A (TWA)reuse the PWA, one .aab
Both stores with some native featuresPath B (Capacitor)one codebase — mind Guideline 4.2
The cleanest App Store experiencePath C (native)best review path; Percher stays the backend

What stays on Percher

Whichever path you pick, your web frontend, API, PocketBase (database, auth, file storage), env vars, custom domain, and SSL stay on Percher, unchanged. The store app is a thin layer on top; Percher remains the web and backend layer.

Before you start (sourced, checked 2026-06-16)

  • Apple Developer Program: $99/year. developer.apple.com/programs
  • Google Play Console: one-time $25 registration fee. support.google.com
  • Apple App Review Guideline 4.2 (minimum functionality) — bare webview wrappers get rejected; add native value. App Review Guidelines
  • A custom domain is strongly recommended: you own and control the origin for Digital Asset Links and universal links. Run bunx percher domains add (auto-SSL included). The shared name.percher.run subdomain still works.
  • Signing, store listings, and review are your responsibility. Percher hosts the web + backend layer; it does not submit apps to the stores on your behalf.