The idea
A MAM app is built the same way a WooCommerce store is built: you do not write any
native code, you configure WordPress, and the app assembles itself from your site’s
content and settings. Because of that, the “journey” of building a MAM app is really a
sequence of stages, and each stage is owned by a specific MAM tool. If you know
which stage you are in, you know which tool to open and what the next move is.
This article is the map. It names the six stages in order — enroll, build, brand,
preview, publish, maintain — explains what each one accomplishes, points to the tool
that owns it, and shows how the stages hand off to one another. It is a concept article,
not a step-by-step guide: each stage links out to the recipe or tutorial that walks you
through the actual clicks.
The single most important thing to understand is that these stages are not a one-way
pipeline you run once and finish. Enrollment happens once and silently. The build,
brand, and preview stages are a loop you return to every time you change your app. Publish
happens when you are ready to go to the stores. And maintain is the steady state your app
lives in forever after — including the fact that 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.
For a new admin this can feel like a wall of menus with no obvious starting point.
The lifecycle reframes that wall as a path. Most of the confusion admins hit (“where do I
set X?”, “why did my change not appear?”, “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 that flows from your
website is the maintain stage doing its job. Once you can place a task on the map, the
right tool is 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, automatically. There is no screen for this and nothing for you
to fill in. On the first admin page load after MAM Main is active, MAM Main calls home to
the MAM enrollment service, receives an account code, and stores it. Every later stage
quietly reuses that code — the previewer QR codes, the Publish page’s entitlement
check, and the content feed all key off it.
What you should know:
- Enrollment is a one-time event. After it succeeds, MAM Main does nothing on subsequent
loads except a single cheap check. - If you later move your site to a new URL, MAM Main notices and shows an admin notice
asking you to confirm the move. It never re-registers silently — you click to approve,
and your account code follows you to the new URL. This protects you from a staging copy
or a domain change accidentally creating a second app identity. - You do not “do” the enroll stage. You just need to know it happened, because it is 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 the structural decisions in order: it confirms the
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 tap.
The build stage is also where the lifecycle’s “WooCommerce of mobile apps” promise shows
up: your app automatically pulls content from your WordPress site and the plugins you
already use. You are not re-entering listings, events, or products into the app — you are
choosing which of your existing content appears and how it is arranged.
What you should know:
- The wizard gives you a sane first version fast. The App Settings Manager is where you go
back to refine — enabling advanced features (GeoFilters, reviews, events, and the like)
that the wizard intentionally leaves out of the first pass. - Build is the stage you revisit most often. Adding a tab, changing a layout, or turning on
a feature is 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 deliberately simple: 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
immediately. The App Settings Manager then exposes the complete palette — every header,
button, and accent color — plus icons and layout details, for when you want to fine-tune
beyond the two starter colors.
What you should know:
- Brand sits on top of build. You generally choose your structure first, then color it.
The wizard enforces this order; the previewer reflects both together. - Like build, brand is a loop you return to, not a one-shot. You can adjust colors and
design at 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. The
second, scanned from inside the Previewer (or your camera), loads your site’s data into it
— so you are looking at your own app, with your structure, your branding, and 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 is the cheapest way to catch a layout or color decision that looked fine in the
admin but feels wrong on a phone. - Nothing in the preview stage is public. No store, no review, no commitment — it is a
private rehearsal of the app you are assembling.
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 that explains how publishing works, what it costs, and the two
developer accounts you will need. It runs no remote calls and gates nothing. The Publish
page is the permanent home base where the actual work — and the gating — happens. It is
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 have not 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, and invite MAM (the checklist keeps the
invite one click away) so the team can submit on your behalf. You do not have to wait for
store approval to move forward; each account is tracked until it is connected. - Enter your app’s store details — name, version, the permission messages for things
like camera/GPS/contacts, app icon, and splash screen — in the Publish page form.
From there, the MAM team handles the native build and the actual submission to each store.
What you should know:
- Publish is the deliberate, one-direction step in the lifecycle. You preview as much as you
want first; publishing is the point where the app becomes public. - Unlike enroll/build/brand/preview, publish involves people and money: a subscription, two
store developer accounts, and the MAM team. Budget time for the developer-account setup,
which depends on Apple and Google, not on 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 — they appear in the app automatically, with no rebuild and no resubmission,
because the app reads your site’s content feed live. The maintain stage is largely the app
doing its job while you run 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 via the App Settings Manager, and
preview again. Structural and visual changes flow out the same content channel; only changes
that alter the native app shell (new permissions, new store metadata, a new app version)
return you 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 re-walk that setup whenever you need a refresher.
How the stages connect
The clean way to hold all six in your head:
- Enroll happens once, invisibly, and underpins everything via your account code.
- Build → brand → preview is a loop. You cycle it during initial setup and every time you
change your app afterward. The setup wizard runs them in that order the first time; App
Settings + the Previewer let you re-run any part of the loop on demand. - Publish is the gated, deliberate crossing from private to public. It is the only stage
that requires a subscription, store accounts, and the MAM team. - Maintain is where a live app lives. Content keeps itself current automatically; app
changes route back into the loop, and only shell-level changes return to publish.
A useful mental test when you are unsure 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)? The answer names 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.
