By the end of this tutorial you will have a working local MAM Suite development environment: a WordPress site running mam-main, one sibling plugin activated, the WP Mobile App Manager Previewer app pointed at your site, and a confirmed JSON response from the phone-data endpoint — the single mobile API that drives every screen in a MAM app.

This is the loop you will live in as a MAM Suite developer. The mobile apps never talk to your code directly; they make one AJAX call, local_app_get_phone_data, and render whatever JSON comes back. Once you can hit that endpoint and see JSON, you have proven the whole stack end to end, and you are ready to extend it.

Scope. This is a developer environment for working on the plugins, not a customer onboarding guide. It skips real WPMAM enrollment, store credentials, and app publishing. Where those normally apply, this tutorial calls out a local stand-in so you can keep moving.

Prerequisites

Before you start, have these in place:

• A local WordPress install, version 6.3 or later, on PHP 8.1 or later. mam-main hard-checks the PHP version on load and shows an admin notice (and refuses to fully initialize) below 8.1. Local by Flywheel, wp-env, DDEV, or a plain LAMP/MAMP stack all work.
• WP-CLI (optional but recommended) for activating plugins and inspecting options from the terminal.
• curl or a browser, for hitting the endpoint at the end.
• The MAM Suite plugin sources checked out locally. In this repo layout they live side by side under mam-suite/ (mam-main, mam-contact-form, mam-geodirectory, and so on).
• A phone or tablet (iOS or Android) on the same network as your dev machine, if you want to complete the Previewer step. The Previewer is optional for confirming JSON, but it is how you see the app for real.

You do not need: an Apple Developer account, a Firebase project, APNs/FCM credentials, or a signed WPMAM enrollment. Those are required to publish an app, not to develop against the phone-data pipeline.

Steps

1. Stand up WordPress

Create a fresh WordPress site and log in as an admin. Note the site’s base URL (for example http://mam.local) — you will need it for the endpoint call later.

If your dev machine and your phone are on the same LAN, make sure the site is reachable by an address the phone can resolve (a LAN IP like http://192.168.x.x or a tool-provided hostname), not just localhost. localhost only works for the curl check in Step 6, not for the Previewer in Step 5.

2. Install and activate mam-main

mam-main is the kernel of MAM Suite. It owns the mobile API, user/role handling, app settings, notifications, and the admin UI that every sibling plugin hangs off of. Nothing else in the suite functions without it.

Copy or symlink the mam-main directory into wp-content/plugins/, then activate it:

wp plugin activate mam-main

On activation you should see a new top-level Mobile App Mgr menu in wp-admin. If you instead see a notice about PHP 8.1, your stack is on an older PHP and the plugin has bailed out — fix that before continuing.

3. Give the site an account code (local stand-in)

Each MAM site is identified by an account code stored in the option mam-account-code (migrated from the legacy local-app-account_code, which is still read as a fallback). On a real customer site this is set during WPMAM enrollment. On a dev box you have no enrollment, so set a placeholder value yourself so the wizard and the Previewer have something to key on:

wp option update mam-account-code DEV-LOCAL-0001

Use any stable string. This value is not validated for the local JSON path — the phone-data endpoint will return data without it — but the Previewer and parts of the setup wizard reference it, so it is worth setting now. Do not point a dev box at a real customer’s account code.

4. Walk the setup wizard

The first time you load wp-admin after activating mam-main, it redirects you into the Setup Wizard (the onboarding wizard, internal slug mam_main_welcome_onboarding). It is a standalone page rather than a visible submenu item; if you have already passed through it, reopen it at admin.php?page=mam-setup-wizard or from the setup reminder notice. The wizard gives you a guided first pass at the things the app needs to render something: a home screen, navigation, and branding.

The wizard’s steps are:

1. App Setup Wizard (welcome)
2. Home Screen — compose the first screen
3. App Navigation — the tab bar and menu
4. Colors and Branding — theme colors and assets
5. App Previewer — QR codes to load your app on a device
6. Next Steps and Resources

You may only see the Welcome step. The wizard reveals the full step list only when a supported content plugin (currently GeoDirectory) is active; otherwise it shows just the welcome step. That is expected on a bare mam-main install. You do not need the full wizard to confirm the endpoint — Steps 5 and 6 below work regardless. If you want the complete guided flow, install GeoDirectory first (Step 5 covers installing a sibling plugin), then reopen the wizard.

Click through whatever steps are shown, setting at least one home-screen element and a theme color so the JSON has something concrete to carry.

5. Activate a sibling plugin

Sibling plugins are how MAM Suite scales. They never import mam-main‘s classes; instead they hook its pipelines — most importantly the mam_get_phone_data_before_send filter, where each plugin injects its slice of the mobile JSON. Activating one proves that the extension path works in your environment.

Pick a sibling plugin to install — for example mam-contact-form (adds a Contact Us form) or mam-geodirectory (adds listings and unlocks the full setup wizard). Copy it into wp-content/plugins/ and activate it:

wp plugin activate mam-contact-form

Most sibling plugins guard on mam-main being active and silently exit if it is not — so confirm mam-main is active first. After activation, the plugin registers its mam_get_phone_data_before_send subscriber, and its data will appear in the payload you fetch in Step 6.

6. Confirm the phone-data endpoint returns JSON

This is the moment of truth. The mobile API is a single WordPress AJAX action, local_app_get_phone_data (the modern alias mam_get_phone_data resolves to the same handler). It is registered for both authenticated and unauthenticated requests, so an anonymous request works — no login token required for a first smoke test.

Hit it with curl, substituting your site’s base URL:

curl "http://mam.local/wp-admin/admin-ajax.php?action=local_app_get_phone_data&iosversion=1.0.0"

You should get back a JSON object. WordPress wraps AJAX responses with wp_send_json, and the pipeline gzips the body when the server supports it; if you see compressed bytes instead of text, add --compressed to the curl call:

curl --compressed "http://mam.local/wp-admin/admin-ajax.php?action=local_app_get_phone_data&iosversion=1.0.0"

What you are looking at: the assembled output of the phone-data pipeline, which runs seven phases (auth → settings → content → notifications → forms → custom → finalize) and fires mam_get_phone_data_before_send so every active sibling plugin can contribute. The branding and home-screen choices from the wizard, plus the data from the sibling plugin you activated in Step 5, are all in here.

Useful query parameters when you want to go deeper:

If you get a 0 or an empty body instead of JSON, the action did not match — re-check the action value and that mam-main is active. If you get a PHP fatal, check your error log; on a dev box this is usually a missing dependency for a sibling plugin you activated.

7. (Optional) Load your app in the Previewer

To see the JSON rendered as an actual app, install the WP Mobile App Manager Previewer from the App Store or Google Play on your device. In the wizard’s App Previewer step, mam-main generates QR codes built from your account code (the one you set in Step 3) — one to download the Previewer, one to load your site’s content into it.

Scan the content QR code (or enter your account code in the Previewer if your local site is not publicly reachable by the QR’s hosted URL). The Previewer then calls the same local_app_get_phone_data endpoint you just curled and renders the result. Because a local dev URL is often not reachable from a phone over the public internet, you may need a LAN-reachable URL or a tunneling tool (such as ngrok) so the device can reach your machine.

If the device can reach the endpoint, your home screen, navigation, branding, and sibling-plugin content all appear — the same JSON, rendered natively.

What you have now

• WordPress + mam-main running locally, with the Mobile App Mgr admin menu.
• An account-code stand-in so the wizard and Previewer have an identity to key on.
• At least one sibling plugin activated and contributing to the mobile JSON.
• A confirmed, JSON-returning phone-data endpoint — the contract the apps depend on.

That endpoint is the app. Everything you build from here either feeds JSON into it (via mam_get_phone_data_before_send and friends) or changes how the apps render that JSON.

What’s next

• Understand the payload you just fetched — read the phone-data pipeline overview and the mobile JSON shape reference to learn what every key means and which phase produces it.
• Inject your own data — follow the recipe for adding to the mobile JSON via mam_get_phone_data_before_send, including the priority conventions that decide when your subscriber runs.
• Build a real app end to end — the “Build an app end-to-end” recipe walks branding, buttons, the tab bar, forms, push, and the publish handoff once you are ready to go past a dev box.
• Regression-test your changes — mam-main‘s snapshot harness (tests/snapshot/snapshot-phone-data.php) captures the endpoint’s JSON for known fixtures and diffs it, so you can verify a change doesn’t alter the frozen contract.