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.

The natural assumption is that you have to stop and wait — get both accounts fully
approved — before you can do anything else toward publishing. You don’t. The MAM
App Publishing Wizard is deliberately built so that your developer-account applications
can be in flight while you keep working: purchasing your plan, entering your app’s
store details, and finishing your build. The actual connection to your developer
accounts is verified later, by the MAM team, right before your app is submitted.

This article explains why that’s safe, what “in flight” actually means at each step, and
where the verification really happens — so you don’t sit idle waiting on Apple when you
could be finishing your app.

Why it matters

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

The wizard is designed to remove that dead time. The store applications and your app
preparation run on parallel tracks that only have to meet at the very end. Knowing
this lets you treat “apply for the accounts” as a kick-off-and-keep-going action rather
than a stop-and-wait one.

The three publishing steps, and which ones can overlap

Publishing lives across two surfaces. The App Publishing Wizard (the “How app
publishing works” walkthrough) is education-only — it explains the process, the costs,
and your developer accounts, then hands you off. The Publish page (MAM → 🚀 Publish
App) is your home base: it’s always available and 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 is explicit that you do not need to wait
   for store approval: once you’ve started both accounts, you move on. The team completes
   the connection as it prepares your submission, and the Publish page shows each account
   as 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 this depends on the
   developer accounts being approved — it’s information about your app that you can
   fill in any time.

The key takeaway 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, and finish your prep while Apple and Google process them 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 are all things you do in your own WordPress admin and in the MAM tools. They
  don’t reach out to Apple or Google, so a pending approval doesn’t stop them.

• The MAM team can prepare your submission. Because you invited MAM to both
  developer accounts when you applied, the team can do its preparation work as soon as
  each account becomes active — you don’t have to come back and re-hand-off anything.

• Nothing is submitted prematurely. The build and submission to each store are the
  last thing that happens, and the MAM team handles that side. Your app isn’t pushed
  to a store until the accounts are genuinely ready.

The only thing that genuinely has to be approved before a store submission can happen
is the developer account at that store — and that submission is the MAM team’s step, not
yours. Your part finishes well before then.

Where verification actually happens

There are two distinct checks in play, and it helps to keep 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, when 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 corrects it if they’ve drifted. This guards against a
publish being misrouted to the wrong app identity (for example, 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 — is completed by the MAM team as part of preparing your
submission, once your accounts are active. The Publish page then reflects each store as
connected, and the platform keeps the corresponding publish button disabled until it is.
This is exactly why the wizard can tell you not to wait: the connection step that depends
on your accounts being live is intentionally placed after the work you do, and it’s
owned by the team, not by 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 that 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