Goal

Your app is already live in the App Store, on Google Play, or both — and now you’ve made a change you want in your users’ hands. This guide walks you through pushing that update out with the Publish another update button on the Publish Your App page, the same page you used for your first submission, now sitting in its “live” state.

Before you dive in, it helps to know there are two different kinds of “update,” and only one of them actually needs a store submission:

• Content and configuration changes — things like adding listings, editing screens in App Setup, changing colors, or swapping out home-screen content. Most of what you build in MAM lives on your WordPress site and gets served straight to the app, so these changes reach your users with no store re-submission at all. Save in App Setup, and they’re live.
• A new app build — anything baked into the binary itself, like the app icon, the launch/splash screen, iOS permission messages, the app name shown on the store, a MAM feature that needs updated native code, or a version/build-number bump. Changes like these need a fresh build, which means resubmitting through this page and waiting on Apple’s or Google’s review.

This article covers the second kind: submitting a new build for an app that’s already published.

Not sure which kind you’re dealing with? If your change shows up the moment you edit settings in Mobile App Manager → App Setup, it’s content — no re-submission needed. If you changed the icon, splash screen, app name, permission text, or you’re adding a feature that needs a new build, keep reading.

Prerequisites

• Admin access to your WordPress site. The Publish Your App page requires the manage_options capability, so you must be a full administrator.
• An app that’s already live on at least one store. The Publish another update button only appears once a platform has reached the “live” state — see When the button appears below.
• An active MAM Suite subscription and connected account. Publishing is gated on your subscription and required plugins being purchased for your account. The page checks this against WP Mobile App Manager and keeps your account code in sync automatically; if publishing is blocked for a subscription or connection reason you can’t clear in the checklist, contact support.
• Your developer-account connection still in place. The Apple and/or Google connection you set up for the first release carries over; you don’t reconnect for each update.

When the “Publish another update” button appears

Head to Mobile App Manager → Publish Your App. Near the top of the page, the Publish status card shows one row for each platform you can publish to.

For a platform that’s live, the row reads something like:

• App Store — live in the App Store (“Live on the App Store as of date. Share your listing and publish updates anytime.”)
• Google Play — live on Google Play (“Live on Google Play as of date. Share your listing and publish updates anytime.”)

Every live row carries a Publish another update button — that’s your way in to ship the next version.

If a platform’s row says submission in progress or submitted for review instead, a build is already on its way through the pipeline — let it finish before you kick off another for that same platform. (See Track your publish status after submitting for what each stage means.)

iOS and Android run on their own clocks. It’s completely normal to see one platform live with its Publish another update button ready while the other’s still mid-submission — update each one whenever it’s ready, on its own schedule.

Steps

1. Make your changes and review them

Start with whatever change prompted this update — where you make it depends on what it is:

• Icon or splash screen — update them in the App Icon and Launch Screen panels of the Publish Your App page.
• App name or description — edit the App Store Information panel.
• iOS permission messages — edit the iOS Permission Descriptions panel (camera, location, photos, contacts, etc.).
• App content or layout — that’s handled over in App Setup, not here. If your update includes changes like these, make them there first.

If all you changed was content in App Setup, and nothing on the Publish page, you likely don’t need a new build at all — your users already have it.

2. Save your app settings

If you touched anything on the Publish Your App page, scroll down and click Save App Settings before you publish — saving here does more than just store your fields:

• It re-flattens your app icon onto the background color if you changed either, so Apple doesn’t reject the build for a transparent (alpha) icon.
• It regenerates your auto-generated launch screen if your icon or background color changed.

That’s why you should always save before submitting an update — skip it, and the new build can ship with stale generated assets.

Keep an eye on the checklist at the top of the page — after saving, it should still read Setup complete for the platform you’re updating. If saving flags something new (say, a permission message you accidentally cleared), take care of it and save again.

3. Click “Publish another update” for the platform

In the Publish status card, find the live platform you’re updating and click its Publish another update button:

• One button per platform (iOS and Android are separate submissions).
• Clicking it sends a fresh publish request into the MAM build pipeline — the same Fastlane-driven process as your first release.

The row switches right away from “live” to submission in progress, timestamped with when you submitted — that’s your confirmation the update is queued and moving.

If the request can’t go through, you’ll see a Publish request failed notice at the top of the page along with a reason. Double-check your developer-account connection and required-plugin status in the checklist, then try again — and if it keeps failing, reach out to support.

A note on version and build numbers: every store submission needs a higher build number than the one before it. MAM handles this for you — the App Identifiers & Versions panel on the Publish page shows the current numbers read-only, marked as automatically managed by WP Mobile App Manager, so there’s nothing to hand-edit for a routine update. Want a specific version label instead (say, bumping from 1.4 to 2.0 to mark a major release)? Contact support. Whatever the page shows is the source of truth for what’s about to ship.

4. Watch the update move through the stages

Refresh the Publish Your App page anytime to check where your update stands — it moves through the same stages as a first release:

• iOS: submission in progress → uploaded to TestFlight → submitted to Apple for review → live in the App Store.
• Android: submission in progress → pushed to Closed Testing → submitted to Google Play for review → live on Google Play.

The in-progress row also reminds you that builds run Monday–Friday, 6 AM–6 PM Central. So if you submit on a Friday evening or over the weekend, don’t worry when it just sits “in progress” — that’s expected, not stuck, and it’ll pick up in the next business window. Once a build slot does pick it up, the initial build and upload typically wrap up in 20–30 minutes.

Once your update reaches live again, the row flips back to its “live” state and the Publish another update button reappears — ready and waiting for whenever you need the next version.

Things to know about app updates

• Updates go through store review, every time. Apple and Google review each new build on their own timeline (commonly 1–3 days) — same as your first release. MAM’s job is uploading the build; the approval itself happens on the store’s side.
• Your testers see it first. The build usually lands in TestFlight (iOS) and Closed Testing (Android) before it reaches the public store, giving you and your testers a chance to install and check the real update before your users ever see it.
• Update platforms independently. There’s no need to ship iOS and Android together — just click Publish another update for whichever platform’s change is ready.
• Don’t double-submit the same platform. If a platform already shows “submission in progress,” let it finish before starting another update for that same platform.
• Content updates don’t need any of this. Listings, screens, colors, and most App Setup changes reach live apps with no re-submission required — save Publish another update for changes that actually need a new build.

Troubleshooting

• No “Publish another update” button on a platform. That button only shows up once the platform is live. If the row shows “submission in progress” or “submitted for review,” a build’s already in flight — just wait it out. If the row is missing entirely, the platform may not be licensed or connected, so check the Developer accounts items in the checklist.
• “Publish request failed.” Re-check your developer-account connection and make sure your required plugins are still purchased and active (both show up in the checklist below the status card). Try again, and contact support if it keeps happening.
• Stuck “submission in progress” for more than a day (during business hours). The card will surface a contact support link at this point — go ahead and reach out for an update.
• Update went out with the old icon or splash screen. You probably published without saving first. Head back to the Publish page and save (that re-flattens the icon and regenerates the launch screen), then publish the update again.

Related

• Submit your app to the App Store and Google Play — the first-time submission this update flow mirrors.
• Track your publish status after submitting — how to read each stage of the Publish status card.
• Run the App Publishing Wizard end to end — the guided on-ramp that precedes your very first publish.
• Upload your app icon (avoid Apple alpha rejection) — why saving re-flattens your icon before each build.

Last verified against mam-main — includes/publish-app/app-submit.php (build_publish_status_row, publish_state_copy, send_publish_request, maybe_handle_save) and includes/publish-app/mam-app-publishing.php (versioning options mam_ios_version_number / mam_android_version_number / mam_ios_build_number / mam_android_build_number). Re-verify if the “Publish another update” button conditions, the live-state copy, the build hours, or the version/build handling change.