What this article covers

Every MAM Suite app gets its content — buttons, menus, forms, images, screens, notifications — from your WordPress site in a single JSON payload: the bundle of data the app downloads each time it talks to your site. Downloading that whole bundle on every launch would be slow and burn through your users’ mobile data, so MAM Suite caches it and sends down only what has actually changed.

Most of the time it just works and you never have to think about it. This article covers the two moments when you do:

• You changed something in Mobile App Manager and want to confirm — or force — the app to pick it up.
• A tester (or a customer) says the app is “stuck on the old version” and you need to understand why and how to fix it.

This is a configuration and troubleshooting guide — no code required. There’s one admin setting involved, Disable Caching, plus a feel for when the app refreshes on its own.

Audience note. If you’re a developer who needs the internals — the cursor option, per-section timestamps, the mam_main_check_cache_for_main_json action, or the object-cache helpers — check the Related articles at the end; they point into the Plugin Reference. This article stays at the admin level.

How MAM Suite caching works (the short version)

Here’s what happens when the app asks your site for content: the request runs through the phone-data pipeline and comes back as a JSON payload. Two layers of caching sit in front of that payload, keeping things fast:

1. The change cursor (app-side refresh). The server keeps a single “cache version” marker — internally called the cursor. Every time the app loads content successfully, it remembers the cursor value it got back, then hands that value back to the server on its next request. If the cursor hasn’t moved, the server doesn’t bother rebuilding the payload — it just answers with a tiny “no new data” response, and the app keeps showing what it already has. If the cursor has moved, the app gets a freshly built payload.

2. Server-side build caches. MAM Suite also caches the expensive-to-build pieces on the server, so assembling the payload stays fast — most notably form definitions (your Gravity Forms-backed forms, transformed into the shape the app expects). These only get rebuilt when the underlying content changes, not on every request.

Here’s the practical takeaway: the app refreshes when the cursor moves. So as an admin, the question that actually matters is “what moves the cursor?”

What moves the cursor (what makes the app refresh)

The cursor moves on its own whenever you change content the app cares about. In the current build, that includes changes such as:

• Saving any post or page (publishing or editing content the app shows)
• Deleting a post
• Adding, editing, or deleting post metadata (custom fields on your content)
• Adding or deleting a user, or changing user metadata
• Creating, editing, or deleting a category or tag (terms)

The same thing happens with app-configuration actions inside Mobile App Manager → App Setup — saving a button, reordering or deleting buttons, saving a layout or content-section settings, changing theme colors, or editing the home-screen stack. Each of these save paths resets the cursor, so every app picks up the change on its next launch.

Here’s the upshot for everyday editing: if you change content in WordPress and save, the app will see it on its next launch or pull-to-refresh. You don’t normally have to do anything special to make that happen.

When does the app actually pick up the change?

The cursor only matters at the moment the app actually talks to the server. So when does that happen? The app checks in:

• On a cold launch — the user fully opens the app.
• On a pull-to-refresh — where a screen supports the gesture.
• When the user navigates to a screen that re-requests data.

So even after the cursor moves on the server, someone who already has the app open on a cached screen won’t see your change until one of those events happens. That’s expected — it’s the trade-off that keeps the app fast and light on data.

Most cached responses are small, but a full rebuild of a content-heavy app’s payload commonly runs tens to a couple hundred KB. That’s exactly why caching exists in the first place — so confirm your changes by relaunching the app, not by hammering refresh.

How to verify a change reached the app

Made an edit and want to confirm it’s live? Here’s how:

1. Make and save your change in WordPress / Mobile App Manager → App Setup.
2. On your test device, fully close the app (swipe it away from the app switcher — backgrounding is not enough).
3. Reopen the app. This cold launch sends its stored cursor back to the server; the server sees the cursor has moved and returns the fresh payload.
4. Confirm the change appears.

If it appears, you’re done. If it doesn’t, jump to Troubleshooting below.

The Disable Caching setting (for testing)

One admin control directly affects this behavior:

Mobile App Manager → App Settings → General → Disable Caching (a Yes/No setting).

When Disable Caching = Yes, MAM Suite forces the cursor to move on every single request. That means the server rebuilds and returns a full, fresh payload every time the app asks — nothing ever comes back stale.

Important. Turn Disable Caching back to No before you publish or hand the app to real users. Leaving it on means every launch downloads the full payload and re-runs the expensive build on the server — slower app starts and more mobile data burned for your users. Think of it as a testing convenience, not something you ship with.

This setting is role-aware in the platform — it’s evaluated per app role rather than globally. For most apps, you’ll simply flip it on while building and off again before launch.

Forms cache: the most common “old version” symptom

If the app keeps showing an old version of a form after you’ve edited it, the usual suspect is the form definition cache, not the cursor. MAM Suite caches each form’s transformed definition on the server so it doesn’t have to re-process the form on every request.

Editing the form’s content usually refreshes this on its own, but if you’ve changed something adjacent — a field-display rule, theme colors, or a form setting that feeds into the cached shape — the cached definition can lag behind. The fix: make a saving change that re-triggers the form’s rebuild (re-saving the form or the relevant App Setup screen both work), then cold-launch the app to confirm. See Form cache and invalidation in the Plugin Reference for the underlying detail.

Troubleshooting: “the app is stuck on the old version”

Work through these in order:

1. Did you actually save? Reopen the screen in Mobile App Manager and confirm your change stuck. An unsaved change never moves the cursor.

2. Did you cold-launch the app? Backgrounding isn’t enough — the app needs to make a fresh request. Swipe it closed and reopen it.

3. Is it just one thing (a form) or everything?

   • One form is stale → almost always the form definition cache. Re-save the form / its App Setup screen and relaunch. See Form cache and invalidation.
   • Everything is stale → that’s the cursor. Continue below.

4. Force a full refresh with Disable Caching. Temporarily set Disable Caching = Yes, cold-launch the app, and confirm the change appears — then set it back to No. If the change only shows up with caching disabled, whatever you edited wasn’t moving the cursor. Note exactly what you changed and report it — that change may need to invalidate the cache, and right now it doesn’t.

5. Confirm you’re testing the right account/role. App content resolves per role and per account/region. If you’re signed in to the app as a different role than the one whose settings you edited, you could be looking at a different payload entirely — correct, just not the one you touched.

6. Still stuck? Capture what you changed, which role/account you tested as, and whether Disable Caching=Yes fixed it. That handful of facts points a developer straight at whether it’s a cursor-invalidation gap or a build cache issue.

Quick reference

Verification

This article was drafted against:

• Setting: Disable Caching — tsl-setting-disable_caching, category general, type yes-no
  (mam-main/includes/app-settings/admin-settings-page.php)
• Cursor mechanism: JSON_Cursor_Manager and its setup_hooks() triggers
  (mam-main/includes/app-connect/json-cursor-manager.php)
• Pipeline cache decision (cursor reset on disable_caching, no_new_data short-circuit)
  (mam-main/includes/phone-data/class-mam-phone-data-pipeline.php, phase_settings())
• Response paths and the post-build cache action mam_main_check_cache_for_main_json
  (mam-main/includes/app-connect/main-json-manager.php)
• Form definition cache — the persistent form_cache post meta that can lag
  (mam-main/includes/forms-manager/mam-gravity-forms-content-class.php, get_data_for_app())

Re-verify whenever the cursor invalidation triggers change, the Disable Caching setting is renamed or moved, the no_new_data short-circuit behavior changes, or the form cache keying changes.

Related articles

• Cursor cache mechanism (Plugin Reference — developer detail on the cursor and per-section behavior)
• Phone data pipeline overview
• Form cache and invalidation
• App Setting: Disable Caching