The idea

When you set up an app for the Apple App Store and Google Play, you have to apply for
two developer accounts — an Apple Developer account and a Google Play Developer account.
Those applications are not instant. Apple in particular can take days to approve a
Company/Organization account, and the timing is entirely on Apple’s and Google’s side,
not on MAM’s.

It’s natural to assume you have to stop and wait — get both accounts fully approved —
before you can move on with publishing. You don’t. The MAM App Publishing Wizard is
built on purpose so your developer-account applications can sit in flight while you
keep working: purchasing your plan, entering your app’s store details, and finishing your
build. The MAM team verifies the actual connection to your developer accounts later,
right before your app is submitted.

Here’s why that’s safe, what “in flight” really means at each step, and where the
verification actually happens — so you’re not stuck waiting on Apple when you could be
finishing your app instead.

Why it matters

Publishing is the one stage in the MAM lifecycle that depends on outside parties — Apple,
Google, and the MAM team — instead of just you and your WordPress admin. That’s exactly
what makes it feel blocked. Assume each step has to fully wrap up before the next one
can start, and you end up with dead time: your build is ready, your plan is paid for, and
you’re refreshing your email waiting on an Apple approval that has nothing to do with the
rest of your prep.

The wizard exists to remove that dead time. Your store applications and your app
preparation run on parallel tracks that only have to meet at the very end. Once you
see that, “apply for the accounts” becomes a kick-off-and-keep-going action instead of
a stop-and-wait one.

The three publishing steps, and which ones can overlap

Publishing plays out across two surfaces. The App Publishing Wizard (the “How app
publishing works” walkthrough) is education-only — it walks you through the process, the
costs, and your developer accounts, then hands you off. The Publish page (MAM → 🚀
Publish App) is where you actually live: it’s always available, and it carries a
checklist that tracks every step until your app is live. That checklist has three items,
and they don’t have to happen in strict order:

1. Purchase your publishing plan. Publishing is the paid part of the lifecycle, so
   the Publish page checks your account’s subscription before it will submit a build.
   Once your plan is active, the page recognizes it and unlocks the submit controls.

2. Set up your developer accounts. Here you create the two developer accounts
   using the linked tutorials, and invite the MAM team to each so they can build and
   submit your app on your behalf. The wizard says plainly that you don’t need to wait
   for store approval here: once you’ve started both accounts, move on. The team finishes
   the connection while it prepares your submission, and the Publish page marks each
   account connected once it’s ready.

3. Enter your app’s store details. This is the content-heavy step: your app
   name, version and build numbers, the permission messages users see for camera/GPS/
   contacts, your app icon, and your splash screen. None of it depends on the developer
   accounts being approved — it’s information about your app, and you can fill it in
   any time.

What matters most here is the relationship between steps 2 and 3. Applying for
accounts (step 2) does not block entering your app details (step 3). You launch the
applications, move straight on to step 3, and finish your prep while Apple and Google
process the applications in the background.

What “in flight” actually means

“In flight” means an application has been submitted to the store but not yet approved
by the store. During that window:

• You can keep working. Purchasing the plan, entering app details, and refining your
  build all happen in your own WordPress admin and in the MAM tools. None of it reaches
  out to Apple or Google, so a pending approval can’t stop it.

• The MAM team can prepare your submission. Because you already invited MAM to both
  developer accounts when you applied, the team can start its prep work the moment each
  account goes active — you won’t need to come back and hand anything off again.

• Nothing gets submitted early. The build and submission to each store are the last
  thing that happens, and the MAM team owns that part. Your app doesn’t reach a store
  until the accounts are genuinely ready.

Only one thing truly has to be approved before a store submission can happen: the
developer account at that store. And that submission itself is the MAM team’s step, not
yours — your part is done well before it comes up.

Where verification actually happens

Two distinct checks are in play here, and it’s worth keeping them separate.

The subscription / entitlement check confirms your account is on a publishing plan.
The Publish page runs it before it will submit a build — it’s about your plan, not
your store accounts.

The account-code verification also runs on the Publish page, the moment you open it.
MAM confirms that the account code stored on your site matches what the MAM platform has
on record for your site’s URL, and fixes it if the two have drifted. This guards against
a publish getting misrouted to the wrong app identity (say, after a site move or a
staging copy). It’s a safety guard, not the developer-account connection itself.

The actual developer-account connection — linking your live Apple and Google accounts
so the team can build and submit — gets completed by the MAM team as part of preparing
your submission, once your accounts are active. The Publish page then shows each store as
connected, and the platform keeps the corresponding publish button disabled until it is.
That’s exactly why the wizard can tell you not to wait: the one connection step that
depends on your accounts being live sits after the work you do, and the team owns it —
not you.

How this connects to the rest of publishing

• This is a detail inside the publish stage of the MAM app lifecycle. If you’re not
  sure where publishing sits relative to building and branding your app, start with the
  lifecycle overview, then come back here.
• The two developer-account applications have their own walkthroughs — the Apple
  Developer Account and Google Play Developer Account tutorials linked from the wizard.
  Those cover how to apply and how to invite the MAM team.
• The app details you enter in step 3 (name, versions, permission messages, icon, splash
  screen) are the publishing settings; see the Publish Your App reference for what each
  field controls and which ones are frozen against existing customer submissions.

The practical rule to remember: apply for your developer accounts early, then keep
going. Treat the store approvals as a background task the MAM team will finish
connecting and verifying for you — never as a wall you have to wait at.

Related

• The MAM app lifecycle: enroll, build, brand, preview, publish, maintain — where the publish stage fits
• Recipe: Using the App Publishing Wizard
• Tutorial: Setting up your Apple Developer account
• Tutorial: Setting up your Google Play Developer account
• Reference: Publish Your App settings