The two ways to see your app

When you build an app with MAM Suite, “my app” can mean two very different things:

• The Previewer — a generic WP Mobile App Manager app you download from the App Store or Google Play, then point at your site. Once it’s pointed there, it shows your configuration almost instantly.
• The published app — your own branded app, under your own name and icon, that Tiny Screen Labs builds and submits to Apple and Google on your behalf.

They feel like the same thing — after all, both put your content on a phone — but they’re built by completely different mechanisms. Once you see the difference, it makes sense why a color change shows up in the Previewer in seconds, while getting that same change onto your customers’ phones takes a new store submission.

This article assumes you’re already configuring an app under Mobile App Manager in WordPress. Think of it as background reading — for the step-by-step publishing flow, see Recipe: Publish your app to iOS and Android.

Why it matters

The most common mix-up is expecting your published app to behave exactly like the Previewer — updating the moment you save a setting in WordPress. Most of your app does work that way (more on that below), but a handful of things are baked right into the build, and those only change when a new version ships through the stores.

Once you know which is which, you’ll know at a glance whether a change just needs a save in WordPress, or a full store submission.

The Previewer: one app, pointed at your site

The Previewer is a single app that Tiny Screen Labs publishes, and everyone shares it. Whoever installs it gets the exact same binary from the App Store or Google Play — it only becomes your app once you point it at your site.

In the App Setup Wizard, the App Previewer step hands you two QR codes:

1. The first downloads the WP Mobile App Manager Previewer onto your phone or tablet.
2. The second loads your site’s data into that Previewer, keyed to your enrollment account code.

Once the Previewer is pointed at your account, it starts pulling your live configuration and content straight from your WordPress site. Nothing is compiled into the Previewer — it reads your config at runtime — so changes you make in WordPress show up almost immediately. The wizard puts it plainly: “whenever you update content on your website, your app updates automatically. No extra steps needed.”

That’s the whole point of the Previewer: a fast feedback loop for building and testing. It’s your main tool for checking navigation, branding, buttons, forms, and content — before you ever submit anything to a store.

Note: since the Previewer is a generic shell, it won’t carry your app’s name, icon, or splash screen, and it runs alongside everyone else’s apps inside that same shared install. It’s for building and testing, not for handing to customers.

The published app: a separate, branded build

A published app works nothing like that. It’s a compiled, signed, store-listed build that carries your identity:

• Your app name and icon on the home screen
• Your bundle id (iOS) and package name (Android), reserved with Apple and Google
• Your launch screens, theme assets, and permission text
• Its own listing in App Store Connect and Google Play Console

You never touch a compiler yourself. From Mobile App Manager → Publish Your App, MAM Suite gathers up your publishing settings — identity, version and build numbers, permission strings, icons, integration keys — and hands them to the WPMAM build pipeline, which runs Fastlane to produce and sign the iOS and Android builds and route them to the stores.

This submission is intentionally fire-and-forget — send it and walk away. The request goes out, the build runs asynchronously on Tiny Screen Labs’ infrastructure, and if all goes well it shows up in TestFlight (iOS) and Google Play internal testing in roughly 20–30 minutes. Rather than staring at the submit button, you just watch the publish-status panel for the result.

You’ll find the details on identity fields, version/build numbers, and permission strings in Recipe: Publish your app to iOS and Android.

What updates instantly vs. what needs a new build

Here’s the practical split — for edge cases, Recipe: Publish your app to iOS and Android is the authority.

Reflected live — no store submission needed. These get read from your site at runtime, so both the Previewer and an already-published app pick them up with no rebuild required:

• App content (listings, events, posts, deals) sourced from your WordPress site
• App Settings Manager configuration — navigation, buttons, screen layouts, content sections
• Most colors and branding driven by app settings

Baked into the build — requires a new submission. These live inside the compiled binary and in Apple/Google’s store records, so changing any of them means producing and submitting a new build:

• App name and icon as they appear on the device home screen
• Bundle id / package name
• Launch (splash) screens
• iOS permission description strings (the copy Apple shows when requesting camera, location, etc.)
• The app version itself, including bug fixes or new native capabilities in the underlying app code

Not sure which bucket something falls into? Here’s the quick test: if you can change it under App Settings Manager and see it show up in the Previewer, it’s live config. If the only place you can change it is the Publish Your App page, it’s part of the build.

How the two connect

The Previewer and the published app aren’t competing products — they’re two stages of one workflow, sharing a single source of truth: your WordPress configuration, keyed to your account code.

1. Build and configure in WordPress (wizard + App Settings Manager).
2. Preview the result instantly in the Previewer, iterating until it’s right.
3. Publish a branded build through Publish Your App when you’re ready to ship to real users.

Since the published app reads that same live config, you can keep refining content and settings after launch without resubmitting anything — right up until you need to change something baked into the build, and then it’s time for a new version.

Related

• Recipe: Publish your app to iOS and Android
• Recipe: Build an app end-to-end
• Integration: WPMAM publishing pipeline
• Recipe: Customer enrollment and account code