The idea
A MAM app is built the same way a WooCommerce store is built: you don’t write any
native code, you configure WordPress, and the app assembles itself from your site’s
content and settings. That’s why the “journey” of building a MAM app really comes down
to a sequence of stages, each owned by its own MAM tool. Once you know which stage
you’re in, you know which tool to open and what to do next.
This article is the map. It walks through the six stages in order — enroll, build,
brand, preview, publish, maintain — explains what each one accomplishes, points you to
the tool that owns it, and shows how each stage hands off to the next. Think of it as a
concept article rather than a step-by-step guide: each stage links out to the recipe or
tutorial that walks you through the actual clicks.
Here’s the one thing worth holding onto: these stages are not a one-way pipeline you
run once and finish. Enrollment happens once, quietly, in the background. Build, brand,
and preview are a loop you’ll return to every time you change your app. Publish happens
when you’re ready to go live in the stores. And maintain is the steady state your app
settles into afterward — including the part where your app keeps reflecting your website
with no extra work from you.
Why a “lifecycle” framing matters
MAM exposes a lot of surface area: a setup wizard, an App Settings Manager, a publishing
wizard, branding controls, a previewer app, and the underlying WordPress content itself.
If you’re new to it, that can feel like a wall of menus with no obvious place to start.
The lifecycle turns that wall into a path. Most of the confusion admins run into —
“where do I set X?”, “why didn’t my change show up?”, “what do I do after the wizard?” —
is really a stage question in disguise. Colors live in the brand stage. Tab bar items
live in the build stage. Store submission lives in the publish stage. Content flowing in
from your website is just the maintain stage doing its job. Once you can place a task on
the map, the right tool becomes obvious.
The six stages
1. Enroll — your site gets an identity
What it accomplishes: registers this WordPress site with the MAM platform and gives it
an account code — the identifier that ties your site, your app, your previewer, and
your eventual store submission together.
Who owns it: MAM Main handles this automatically — there’s no screen for it and
nothing for you to fill in. The first time you load an admin page after activating MAM
Main, it calls home to the MAM enrollment service, gets back an account code, and stores
it. Every stage after this one quietly reuses that code: the previewer’s QR codes, the
Publish page’s entitlement check, and the content feed all key off it.
What you should know:
- Enrollment happens once. After it succeeds, MAM Main does nothing on later page loads
beyond a single cheap check. - If you later move your site to a new URL, MAM Main notices and shows you an admin
notice asking you to confirm the move — it never re-registers itself silently. Click to
approve, and your account code follows you to the new URL. That one click is what keeps
a staging copy or a domain change from accidentally spinning up a second app identity. - There’s no “doing” the enroll stage yourself. You just need to know it happened — it’s
the thread every other stage is sewn onto.
2. Build — the app’s structure and content
What it accomplishes: decides what your app is — its home screen, its navigation, and
the content that fills it.
Who owns it: the App Setup Wizard (MAM Main’s onboarding wizard) for the first pass,
and the App Settings Manager for everything after.
The App Setup Wizard walks you through these structural decisions in order. It confirms
your content source is in place (for example, that GeoDirectory and the MAM GeoDirectory
bridge are installed, so your listings can flow into the app), lets you pick a home
screen layout from a small set of pre-built designs, and lets you lay out your app
navigation — the tab bar and menu items your users will tap.
This is also where the lifecycle’s “WooCommerce of mobile apps” promise plays out: your
app pulls its content automatically from your WordPress site and the plugins you already
use. You’re not re-entering listings, events, or products into the app — you’re choosing
which of your existing content shows up, and how it’s arranged.
What you should know:
- The wizard gets you a solid first version fast. The App Settings Manager is where you
come back to refine it — turning on advanced features (GeoFilters, reviews, events, and
the like) that the wizard leaves out on purpose the first time through. - Build is the stage you’ll come back to most. Adding a tab, changing a layout, turning on
a feature — it’s all build work, whether you do it in the wizard or directly in App
Settings.
3. Brand — how the app looks
What it accomplishes: applies your visual identity — colors first, then the finer design
details — on top of the structure you built.
Who owns it: the Colors and Branding step of the App Setup Wizard for the quick
version, and the App Settings Manager’s branding and design controls for the full set.
The wizard keeps this simple on purpose: pick a light color and a dark color, and it shows
you a live, recolored preview of your chosen home-screen layout so you can see the effect
right away. The App Settings Manager then opens up the complete palette — every header,
button, and accent color — plus icons and layout details, for when you want to fine-tune
beyond those two starter colors.
What you should know:
- Brand sits on top of build — you choose your structure first, then color it. The
wizard enforces that order, and the previewer always reflects both together. - Like build, brand is a loop, not a one-shot. You can adjust colors and design any time,
without redoing anything else.
4. Preview — see it on a real device before anyone else does
What it accomplishes: shows your real, current app on a real phone or tablet — pulling
your live content and your latest settings — without publishing anything to the stores.
Who owns it: the WP Mobile App Manager Previewer, a free companion app on the App
Store and Google Play, paired with the App Previewer step of the setup wizard.
The wizard hands you two QR codes. The first downloads the Previewer app to your device.
Scan the second one from inside the Previewer (or with your camera), and it loads your
site’s data — so you’re looking at your own app, your structure, your branding, your real
content, on a device in your hand.
What you should know:
- Preview is your feedback loop: build a little, brand a little, preview, adjust, preview
again. It’s the cheapest way to catch a layout or color choice that looked fine in
wp-admin but feels wrong in your hand. - Nothing here is public. No store, no review, no commitment — this is a private rehearsal
of the app you’re putting together.
5. Publish — go live in the App Store and Google Play
What it accomplishes: turns your previewed app into a real, installable app in the Apple
App Store and Google Play.
Who owns it: two surfaces work together here — the App Publishing Wizard (a separate
MAM Main wizard from the onboarding one) and the Publish page (MAM → Publish App) — plus
the MAM team on the technical side.
The two surfaces have distinct jobs. The App Publishing Wizard is education-only — a
once-through walkthrough explaining how publishing works, what it costs, and the two
developer accounts you’ll need. It makes no remote calls and gates nothing. The Publish
page is the permanent home base, where the actual work — and the actual gating — happens.
It’s always available, checks your account’s publishing entitlement, and shows a
checklist that tracks each step until your app is live, because publishing is the paid,
hands-on part of the lifecycle.
The Publish page’s checklist covers three things:
- Purchase the publishing suite, if you haven’t already. The exact total is calculated
from the features your app actually uses, and nothing is charged until you check out on
wpmobileappmanager.com. - Set up your store developer accounts — an Apple Developer account and a Google Play
Developer account — using the linked tutorials, then invite MAM (the checklist keeps that
invite one click away) so the team can submit on your behalf. You don’t have to wait on
store approval to keep moving — each account is tracked until it’s connected. - Enter your app’s store details — name, version, permission messages for things like
camera/GPS/contacts, app icon, and splash screen — right in the Publish page form.
From there, the MAM team takes over: the native build and the actual submission to each
store are theirs to handle.
What you should know:
- Publish is the deliberate, one-direction step in the lifecycle. Preview as much as you
like beforehand — publishing is the moment the app actually goes public. - Unlike enroll, build, brand, and preview, publish involves people and money: a
subscription, two store developer accounts, and the MAM team. Leave room in your
schedule for the developer-account setup — that timeline is up to Apple and Google, not
MAM.
6. Maintain — the steady state
What it accomplishes: keeps a published app current — both its content and its
configuration — over its whole life.
Who owns it: mostly nothing you have to touch, plus the App Settings Manager and the
MAM Suite’s update mechanism when you do.
This is the stage that surprises people, in a good way. Once your app is live, updating
your website updates your app. New listings, edited events, changed products, fresh
content — it all shows up in the app automatically, no rebuild and no resubmission
required, because the app reads your site’s content feed live. Maintain is mostly the app
doing its job while you go on running your website as usual.
When you do want to change the app itself — adjust branding, add a feature, restructure
navigation — you drop back into the build and brand stages through the App Settings
Manager, then preview again. Structural and visual changes flow out through that same
content channel; only changes that touch the native app shell (new permissions, new store
metadata, a new app version) send you back to the publish stage for a fresh store
submission.
What you should know:
- Content changes: automatic, no action needed.
- Configuration and feature changes: build/brand in App Settings, then preview.
- Native-shell changes (rare): back through publish.
- MAM also surfaces on-demand “guides” from the Software page that re-launch a specific
wizard flow from step one, so you can walk through that setup again whenever you want a
refresher.
How the stages connect
Here’s the clean way to hold all six in your head:
- Enroll happens once, invisibly, and underpins everything through your account code.
- Build → brand → preview is a loop. You’ll cycle through it during initial setup, and
again every time you change your app afterward. The setup wizard runs them in that order
the first time; App Settings and the Previewer let you re-run any part of the loop
whenever you need to. - Publish is the gated, deliberate crossing from private to public — the only stage
that requires a subscription, store accounts, and the MAM team. - Maintain is where a live app lives out its life. Content keeps itself current
automatically; app changes route back into the loop, and only shell-level changes send
you back to publish.
A useful test for whenever you’re not sure where you are: Is this about what the app is
(build), how it looks (brand), checking it (preview), making it public (publish), or
keeping a live one current (maintain)? Answer that, and you’ve named the stage — and the
stage names the tool.
Where this fits in the Codex
- Build stage: the App Setup Wizard walkthrough, and the App Settings Manager / app-setting
reference for the features the wizard leaves out. - Brand stage: the Colors and Branding recipe and the branding/design settings reference.
- Preview stage: the App Previewer setup guide.
- Publish stage: the App Publishing Wizard recipe, plus the Apple and Google developer-account
setup tutorials. - Maintain stage: plugin reference articles for the content sources (for example, MAM
GeoDirectory) whose live feeds keep your app current.
