The Dashboard
The dashboard · included with the Dev Bundle
Build and ship your own app. Without writing code.
The Dev Bundle ships the full source and this dashboard to drive it. Configure the app,
build it for both stores, submit it, and push updates — from a browser on your own
machine. One command opens it: npm run dashboard
Config · ten cards, one form
Everything the app needs, in one form.
What the app is called, how it looks, where it points, who builds it, both sets of store credentials, push, permissions, and memberships. Each field says which file it writes and carries a ? that explains what it is for and where to find the value. Click a card. Every screenshot opens full size.
App Identity · app.json
What the app is called
Name, slug, URL scheme, version, iOS bundle ID, Android package, user agent. Type the name and the rest is derived — every derived field is locked until you unlock it, so the four names that must agree, do.
- Each field says which file it writes —
app.json,package.json - A one-click copy into the WordPress plugin’s Deep Linking fields, so both halves match
- Version is read-only here; you bump it on the Builds tab before submitting
Branding Assets · assets/images/
Six pictures, dropped in
iOS icon, Android adaptive foreground and background, notification icon, and a light and dark splash. Click any one to replace it; the card shows the size it wants and the size you gave it.
- Adaptive background as a solid colour or an image
- Accent and splash background colours beside the pictures they sit under
- A tick on each asset when it is the right size — no guessing what Apple rejects
Your WordPress Site · eas.json + app.config.ts
Where the app points
Your production URL, an optional staging URL for local development, and the portal slug that drives Android deep links.
npm run dev:stagingpoints a dev build at staging instead of production- Tick “community is at the site root” or enter the slug — both halves of the app follow it
Build Service · app.json
The account that does the building
The dashboard checks the build CLI, its version and whether you are logged in, and offers the fix on the same line. Owner, project ID and the updates URL are read from the service and baked into every native build.
- Log in and update the CLI from the card, not a terminal
- Each project keeps its own login, so a build never goes to the wrong account
OTA Updates · app.json
How updates find their way to phones
Runtime version policy and branch. Over-the-air updates only reach builds on the same app version — bump the version and older installs stop receiving newer updates, which is the safe default.
Apple App Store · eas.json
No Apple password. Ever.
Store access is by API key, not by account login, so nothing asks for a password or a two-factor code. That is what makes it possible to publish for a client whose account you do not hold the password to.
- App ID, key ID, issuer ID, team ID and type; drop the
.p8on the card - A one-time credentials command, generated with your values already in it — paste it and it runs start to finish, no prompts
- Test credentials asks App Store Connect whether the key works now, rather than a build failing an hour later on a permission nobody checked
Google Play · eas.json
Same idea, Google’s way
A track, a release status, and the service-account JSON dropped on the card. Same one-time credentials command for the keystore, same Test credentials button against the Play Developer API.
- Default release status is “upload as draft” — nothing goes live until you release it from Publishing
Push Notifications · Firebase
Push, set up once
Drop in the two Firebase config files. Then the delivery credentials — FCM service account and APNs key — go to the build service once per project and are linked from here, so you never hunt for them again.
- The card says plainly which Google JSON is which; the Play key and the FCM key are easy to mix up
- Your server never holds Apple or Google push credentials
Native Permissions · app.json
Off unless you need them
Microphone, camera, location. The stock app uses none of them; enable one only when a feature on your site needs it, because Apple rejects apps that declare permissions nothing visibly uses. Each change needs a new build, not an update.
In-App Purchases · package.json
Selling, wired up
One switch enables the purchase module. Then a three-step readiness check: Apple’s paid-apps agreement, whether your site is announcing purchases yet, and whether the catalogue has been synced to both stores.
- Sync catalog to stores creates the subscription group and its products from the plans you designed in WordPress
The other five tabs · build, publish, update
Config is where you set it up. These are where you ship it.
Same window, next five tabs. Every one reads live from the build service and the two stores — none of it is a log of what you remember doing.
Builds
Native builds without a Mac
Bump the version — major, minor, patch — and build for iOS and Android. Four files stay in step, so neither store rejects an upload over a number nobody remembered to change.
- Dev, preview, simulator or production, per platform
- Your build-service quota shown before you spend it
- Finished builds list live from the service, each with a download, a route to Publishing and a link to the build itself
Publishing
The store listing, written once
Reads your listings from Apple and Google and writes back to them. Descriptions, keywords, screenshots, the age-rating questionnaire, and the review notes Apple now rejects apps for leaving empty.
- Both stores, one text — their limits differ, and the fields count for you
- Screenshot frames drawn at the exact size each store demands
- One card lists what no API can reach, so you know what is left to do by hand
- Staged, not fired: upload a build as a draft, attach release notes, release when you are ready
- A pre-flight list of things worth checking — a version mismatch, an empty field — before you submit
OTA Updates
Fix something in minutes, not days
A change that touches only JavaScript goes to everyone over the air, with no store review. Anything native still needs a build, and the dashboard tells you which you are looking at before you push.
- Update history with a sanctioned rollback
- An emergency lever back to the build people already have
Updates
Keep the core current
The app core ships as a versioned package. This tab shows which version each project runs, what the latest is, and updates it in place — your branding, config and modules untouched.
- Release notes for each core version before you take it
- Whether the update needs a new native build or can go out over the air
Snapshot
Everything about this app, in one file
A full picture of the project — config, versions, what is on each store, what is in flight — as one file you can attach to a support request or keep before a change.
- Sensitive values hidden with one button, so it is safe to share
All apps · if you look after more than one
Every client app on one screen.
The switcher at the top moves between projects, and each keeps its own build-service login. All apps opens a grid — the version each runs, whether it is ready to build and publish, what is live on each store, and anything in flight — with six actions that run across the fleet. Click one.
All apps
The grid
One row per project: the app and core version each runs, whether it is ready to build and publish, what is live on each store, the modules it carries, and anything in flight. The six buttons above the grid run an action across every app you tick.
- Readiness counts are live — pass / warn / fail for build and for publish
- Each project keeps its own build-service login, so a build always goes to the right account
- One button hides every client name and path before you share a screen
Update core
Every app onto the same core, in one pass
The button shows how many apps are behind the latest core. Run it and each project is updated in turn — branding, config and modules untouched.
- A count on the button, so zero means there is nothing to do
- Apps already current are skipped, not re-run
Apply zip
One change, every project
Drop a zip of files — a module, a patch, a shared asset — and it is applied to each selected app’s working copy. What was written is listed per app before anything is built.
Build
Build them all, one at a time
Pick platforms and a profile, and the dashboard queues a build for each selected app under that app’s own build-service login. One at a time, and a failure on one never stops the rest.
- Your quota shown per account before you spend it
- Each finished build lands in that app’s Recent Builds like any other
OTA push
One fix to every phone, before lunch
A channel, a message, and a checklist of apps with their version and core beside each. Pushes iOS and Android together, from each app’s own working copy.
- Apps not logged in to the build service are skipped and say so
- If the selected apps run different core versions it stops and tells you — the same push means something slightly different on each — and you tick to proceed anyway
Submit latest
Latest production build, to both stores
Takes each app’s newest production build and submits it — App Store Connect and Google Play — as a draft, using the API keys on each app’s Config. Nothing goes live from here.
Release
The full run, across the fleet
Bump, build, submit, and stage release notes for every selected app in one go. Each step reports per app, so a rejected upload on one client is one line in the log, not a halted release for everyone.
Two ways to get it built
The same app either way.
Dev Bundle
The full source and this dashboard. You configure, build, submit and update it yourself, under your own store accounts.
Managed
Not building it yourself? On the Managed tier this dashboard is ours to run. You fill in your details on the plugin’s Managed tab in WordPress, and we build and submit under your own Apple and Google accounts.