The core idea

Think of MAM Suite the way you think of WooCommerce. WooCommerce never asked you to become a programmer to run a store — it took the WordPress site you already knew and turned it into an eCommerce platform, adding products, a cart, and checkout on top of the content you already managed. MAM Suite does the same thing for mobile apps. It’s the WooCommerce of mobile apps: a set of WordPress plugins that turn the content you already manage into a real, native iOS and Android app — no app code to write, and no rebuild every time you change something.

That last part is worth sitting with, because it’s what separates MAM from “export my site to an app” tools. The app you ship isn’t a frozen snapshot of your website — it’s a native shell that reads your live WordPress site every time a customer opens it. Publish a new listing, change a price, fix a typo, add an event, and that change shows up in the app on its own — no resubmission to the app stores, no waiting on a build. The setup wizard says it plainly in its welcome step: “whenever you update content on your website, your app updates automatically. No extra steps needed.”

Here’s what this article covers: why that works, what “feeds the app” actually means, and where the line falls between changes that update instantly and the rarer ones that need a new build.

Three layers: content, configuration, and the native shell

Picture MAM as three layers that meet at runtime.

1. Your content lives in WordPress. Your listings, events, products, pages, reviews, and images are stored and managed exactly where they always were — in your WordPress database, edited through the familiar admin. MAM doesn’t ask you to keep a second copy of anything; the content is the WordPress content. A supported source plugin — GeoDirectory is the current core integration, with WooCommerce and Business Directory also supported — is what organizes that content into listings, products, or directory entries the app can understand.

2. Your app’s shape lives in MAM’s settings. Separately from the content, MAM keeps track of how the app is arranged: which screens exist, what sits in the bottom tab bar, the home-screen layout, your brand colors, which sections show on a listing detail screen, and so on. These choices are saved in MAM’s own settings tables in your WordPress database (kept per user role, so different roles can be shown different apps). The App Setup Wizard is the friendly front door to these settings — it walks you through Home Screen, Navigation, Branding, and previewing — and the App Settings Manager under MAM (Mobile App Manager) is where you fine-tune them afterward. Crucially, this configuration is data, not compiled code: it describes the app rather than being the app.

3. The native shell runs on the phone. What your customer installs from the App Store or Google Play is a native application — genuinely native, not a website in a frame. But that shell arrives mostly empty of anything specific to you. At launch, and as the user navigates, it asks your WordPress site two questions: how should I be arranged? (your configuration) and what should I show? (your content). It builds its screens from the answers. Because both answers come from your live site, the same installed app can look and behave completely differently from one MAM customer to the next — and can change for your own users the moment you change a setting or publish a post.

You can see this model at work in the wizard itself. On its very first step it checks your site for a supported content plugin and counts your published listings — “We found N GeoDirectory listings on your site… those listings will automatically appear in your content feed.” It’s reading your live data to decide what to do, exactly as the finished app will.

What “feeds the app” means in practice

When we say your content and plugins feed the app, here’s what that means concretely: the app pulls a structured description of your site at runtime, instead of baking it in at build time. That has a few consequences worth spelling out, because they shape how you work day to day:

• Editing content is editing the app. Add a GeoDirectory listing and it shows up in the listings screen. Mark a listing featured and it can surface in a featured row. Close out an event and it drops off the events tab. You do this with the WordPress tools you already use — there’s no separate “app content” panel to keep in sync.
• Installing a supported plugin can add a capability to the app. This is the part that feels most like WooCommerce. The Navigation step of the wizard, for example, offers to install MAM Special Offers to get a Deals tab and GeoDirectory Events to get an Events tab. Adding the right plugin is how you light up a feature in the app — much the way adding a WooCommerce extension lights up a payment method or shipping option in a store.
• A bridge plugin connects a source to the app. Source plugins like GeoDirectory weren’t written with MAM in mind, so MAM ships a small integration plugin per source — MAM GeoDirectory for GeoDirectory — that translates that source’s content into the shape the app expects. The wizard installs the bridge for you; you mostly just need to know it’s the connective tissue between “my listings” and “listings in the app.”
• What you see in the Previewer is what your real app will see. The App Previewer step gives you a QR code that loads your live site’s content and configuration into the WP Mobile App Manager Previewer app on your phone. Because the Previewer reads the same live data your published app will, previewing is an honest rehearsal, not a mock-up.

What updates instantly — and what needs a new build

The “no rebuild” promise is broad, but it isn’t absolute — knowing exactly where the line falls keeps your expectations accurate.

Updates instantly (no app-store resubmission):

• Content changes — new, edited, or removed listings, events, products, reviews, prices, text, and images.
• App configuration changes you make in MAM — screen order and names, tab-bar contents, home-screen layout, brand colors, which sections appear on a screen, and similar settings. Because the shell reads these at runtime, adjusting them in your WordPress admin changes the live app for your users.

Needs a new native build (a hand-off to the MAM team and an app-store submission):

• The things baked into the native binary itself — the app’s name and app-store identity, its icon and launch screen, OS-level capabilities (such as push-notification entitlements or certain device permissions), and the underlying app version.

Here’s a useful rule of thumb: if a change is content or how content is arranged and styled, it updates live. If a change alters the identity or native capabilities of the installed binary, it’s a build. Most of what you do day to day falls in the first bucket, which is exactly why MAM feels less like software development and more like running a website.

Why this model matters

This architecture is why MAM can be a no-code product without being a toy. You get a genuinely native app — real performance, real device features, a real App Store and Google Play presence — while keeping the operational simplicity of a website. There’s no release cycle for routine changes, no engineer in the loop to ship a price update, and no second content system to maintain. Your team keeps doing what it already does in WordPress, and the app stays current on its own.

It also explains why onboarding asks for what it does. The wizard can only assemble an app from a foundation that already exists: a reachable WordPress site, a supported content plugin with real content in it, and a plan for publishing. The app reads your live site, so a site that’s offline, firewalled, or empty has nothing to feed the app. Get the foundation right, and the rest is assembly.

How this connects to the rest of the Codex

• To see the assembly happen, walk through the App Setup Wizard in the Getting Started articles — Home Screen, Navigation, Branding, and the App Previewer.
• To understand what you need in place before the wizard can build anything, see What you need before you start (prerequisites checklist).
• To go deeper on shaping the app after setup — tab bars, per-screen sections, layouts, and branding — see the Building Your App articles and the App Settings Manager.
• To understand the rarer build-time path — app name, icon, push, and submitting to the stores — see the app-publishing articles in Building Your App.