Goal

You added or edited content in WordPress — a post, a page, an item, a category — but the mobile app still shows the old version, or doesn’t show the new content at all. Here’s a walk-through of the most common causes, in the order they’re worth checking: from “the content was never published” to “the app is holding onto a cached copy.”

In almost every case the fix is one of: finish publishing the content, give it a role the user can see, or clear the app’s content cache.

Before you start

• Know which device or account is seeing stale content. “It’s stale on my phone but fine on a tester’s phone” points at the cache or the signed-in user’s role, not at WordPress.
• Have access to the WordPress admin for the site behind the app.
• It helps to know whether the content you added is gated by role (visible only to certain user groups) or available to everyone.

Why this matters: the app doesn’t re-download everything on every launch. To keep launches fast and save mobile data, MAM Suite only sends sections that have changed since the app’s last successful fetch. That’s the single most common reason “I changed it in WordPress” and “I see it on the phone” drift apart.

Steps

1. Confirm the content is actually published

The app only receives content WordPress treats as live and public.

• Open the post/page/item in WordPress and confirm its status is Published, not Draft, Pending, Scheduled (a future date), or Private.
• If you used Save Draft and then walked away, the content exists but was never published — the app will never see it. Click Publish (or Update, for an already-published item).
• For scheduled content, check the scheduled date hasn’t slipped into the future.

This is the most common cause and the fastest to rule out. Do this first.

2. Confirm the signed-in user is allowed to see it

MAM Suite tailors much of the app — buttons, menus, gated content — to the signed-in user’s role. Content restricted to one user group simply won’t appear for someone outside that group.

• Check whether the content (or the screen/button that links to it) is restricted to a specific role or user group.
• Confirm the account testing the app belongs to that role.
• A quick test: sign in as an admin (or as a user known to be in the right group) on a second device. If the content appears there but not on the original device, the cause is role visibility, not WordPress and not the cache.

If admins see the content but normal users don’t, the gate is doing its job — adjust the content’s role/group assignment in WordPress so the intended audience is included.

3. Force the app to fetch fresh content (clear the cache)

If the content is published and the user is allowed to see it, the app is almost certainly serving a cached copy.

Here’s how the cache works: the app keeps a cursor — a marker of how current its last successful fetch was — and sends it back with every request. If nothing’s changed in WordPress since then, the server replies “no new data” and the app keeps what it already has. Once content changes, that cursor moves forward, and the app pulls the changed sections on its next fetch.

Normal WordPress edits — publishing, updating, or deleting a post, editing a category, changing post meta — bump that cursor automatically, so the app should pick up your changes on its next fetch. When it doesn’t, here’s how to force the issue:

• Fully close and reopen the app. Don’t just background it — close it from the app switcher so it does a cold launch. A cold launch is when the app reconciles its cursor with the server.
• If the app exposes a pull-to-refresh or refresh control on the affected screen, use it.
• If it’s still stale after a cold launch, sign out and sign back in, or remove and reinstall the app to clear its cached payload — the bundle of data the app has downloaded from your site.

Most of the time, a cold relaunch is all it takes.

4. If a specific screen keeps reloading stale (developer/builder settings)

If you build the app and the cache is interfering with testing or with content that legitimately changes often, MAM Suite has settings that trade speed for freshness. These live in the app’s General settings.

• Disable Caching — turns off content caching so screens always fetch fresh data from the server. The trade-off is slower launches and more mobile data for every end user. Use it while testing, then turn it back off for production.
• Force Reload on Open — fully reloads the app’s configuration and content every time the app is opened, instead of using cached data.
• Reload on each home screen action — reloads the home screen’s content each time the user navigates back to it, instead of keeping the previously loaded state. Useful when the home screen surfaces frequently changing content.

Be deliberate with these. They exist to guarantee freshness, but each one removes a layer of caching, so leaving them on in production makes every launch slower and heavier on data. For a one-off “why won’t this update” investigation, prefer the cold-relaunch in Step 3 over flipping a global setting.

5. Rule out the obvious environment issues

If none of the above explains it:

• Confirm the device actually has a working network connection — a cold launch with no connectivity falls back to cached data.
• Confirm you edited content on the same WordPress site the app points at (staging vs. production is a classic trap).
• Confirm you’re testing the right build of the app — a published store build and a local dev build can point at different sites or hold different caches.

Quick checklist

• Is the content Published (not Draft/Scheduled/Private)? → Step 1
• Is the signed-in user allowed to see it by role/group? → Step 2
• Cold-relaunch the app to clear the cursor cache. → Step 3
• Still stale on one screen? Consider Disable Caching / Force Reload on Open for testing. → Step 4
• Right site and right network? → Step 5

Related

• App Setting: Disable Caching
• App Setting: Force Reload on Open
• App Setting: Reload on each home screen action
• Cursor cache mechanism (developer reference — how the cursor and “no new data” response work)

What’s next

If you’ve worked through all five steps and the app still won’t show content you’ve confirmed is published and role-appropriate, gather: the device, the signed-in account and its role, the exact content (post ID or title), and whether a second account on a second device sees it. That’s what an engineer needs to tell a caching hiccup apart from a data-pipeline issue.