App Review and release

Once a build is with testers, the rest is a decision: send it for review, then put it in front of people. Your agent asks for each step and follows it; you approve each one with a tap, on the dashboard or from a notification.

The tools behind these requests: Every MCP tool › App Review and production and Rejections.

Who does what

App Store

1. Submit for App Review

   Your agent picks the build on TestFlight and asks; you approve. The in-app products that are ready go with it. The store page must be complete first: Ploa says what's missing, and so does preflight.

2. App Review decides

   Usually within a day or two. Ploa hears the answer within minutes and tells you on your devices.

3. Release

   With "release when approved", Apple releases it by itself. With "release manually", it waits for you (Pending Developer Release): your agent asks to release it, for everyone or as a phased release.

4. Phased release

   Over 7 days, a growing share of people with automatic updates get it; anyone can still download it from the store. Pause (up to 30 days in all), resume, or release to everyone now.

The release option: automatic once approved, or manual. Ploa keeps it for the app and puts it on every next version before it goes to App Review. Apple takes a change to a version until it approves that version; after that the version goes out as it was set, and the App Review card's switch, now "Next versions", is for the versions after it. Your agent asks to change it (ploa_appstore_release_type), or you change it from the App Review card.

Steps Apple leaves to you

Some App Store Connect forms have no API, and some only the Account Holder or an Admin can fill in. When your agent asks for App Review, when App Review refuses a version, and when Apple refuses a request because of an agreement, Ploa files each such step as a task in your approvals, with numbered steps, the answer it suggests and the link. Your agent lists them (ploa_person_tasks) and walks you through each.

• App Privacy, from the privacy answers (see Privacy).
• The regulated medical device declaration, for Health & Fitness or Medical apps, or apps with frequent medical information, sold in the EU or EEA, the UK or the US.
• EU trader status (the Digital Services Act), once for the account and once for each app.
• The Paid Applications Agreement with its tax and banking forms, when the app sells something (see In-app purchases).
• Age rating questions Apple adds that Ploa doesn't know yet, content rights while Apple has none, export compliance answers or documents still missing, and an updated agreement to accept.

The declarations are yours: your agent suggests an answer and never gives one in your place. Once you've done one, press Did it on its task.

Replace or withdraw

• A newer build while one is in review: one approval withdraws the version, puts the new build on it and submits again. Review starts over.
• Withdraw: takes the version out of review (App Store Connect's Remove from review), editable again, with its build still on TestFlight.
• After a rejection: fix what App Review asked, then submit again, with a new build or the same one. Ploa sends the version back in the submission App Review returned, as App Store Connect's Resubmit to App Review does, so don't do it by hand there. If App Review also rejected something else in it, such as an in-app event, Ploa says so: fix or remove that in App Store Connect first.
• One approval is enough: if Apple is still closing an earlier review submission of the version, Ploa tries again by itself for about 20 minutes under the same approval, and if a restart of Ploa cut a submission off, it runs again by itself. Nobody approves the same step twice.

The app's Versions tab › Release page shows the App Review card: the version, its build and state, the release option, the phased release's day, earlier decisions, and the steps you can take now.

Google Play

1. Promote

   Your agent asks to move a release from internal testing to production, or to closed or open testing; you approve. It keeps the What's New it went out with, and a release that went out without notes takes the ones written since (What's New in both stores).

2. Staged rollout

   Optionally to a share of users first (say 10%), then widen it, halt it, or complete it, each with your approval.

3. Google's review

   Usually a few hours to two days; up to a week before an app's first release is out. Ploa reads the release's review state from Google and tells you the answer, like App Review's.

Managed publishing. With managed publishing on in Play Console, an approved release waits until you publish it there. Google has no API to read or change managed publishing, or to publish what it holds. So Ploa knows it's on once Google has held an approved release, and the Google Play card's Release on Google Play then opens Publishing overview. Turning it on or off is yours, in Play Console › Publishing overview › Managed publishing. On the App Store the same choice is the version's release option (above), which Ploa does change, with your approval.

Changes waiting in Play Console. With managed publishing on, or when Google won't send a change for review by itself, Google Play saves Ploa's changes without sending them for review. Google's API can't send them, so Ploa tells you on your devices and on the Release page, with a button to Publishing overview, where you press "Send changes for review".

A new app's first production release

Google takes an app's first production release only in Play Console. Before it, Play Console's own setup has to be done: the App content forms and the store listing (see Privacy), and for a new personal developer account the closed test and Apply for production (see Testers). Then:

1. Your agent asks to promote to production

   You approve, and Ploa puts the release on Production as a draft, since Google refuses anything else for an app never published.

2. You start the rollout in Play Console

   Production › the draft release › Next (or Edit release) › Save › Start rollout to Production (or Publishing overview › Send for review). The Release page keeps these steps, with the link, until it's done.

3. Google reviews it

   Often in a few days for a new app. After that, Ploa releases every update itself.

Who approves

From an agent or the CLI, every one of these asks for your approval first: submit, withdraw, release, phased release changes, the release option, promote, rollout and halt. Approve on the dashboard's Approvals page or from the notification, and the agent hears the answer. An owner can make an agent autonomous, so these go through at once under its name; see Access and approvals.

Without an agent, the same requests start from the CLI:

ploa release ios --release <id> --submit            # ask to submit for App Review
ploa release ios --release <id> --submit --replace  # a newer build in place of the one in review
ploa release ios --release <id> --withdraw          # ask to take it out of review
ploa release ios --release <id> --app-store         # ask to release the approved version
ploa release ios --release <id> --phased pause      # pause | resume | complete
ploa release android --release <id> --promote production --rollout 10

When a store says no

Ploa gathers everything the stores turned down in one place: the App Store version, builds Apple's processing refused, beta review, in-app products, events, product pages, and Google Play releases. For each, the state, the reasons the stores' APIs give, the link to the full text, and what to do next.

1. Give the message to your agent

   Apple's API doesn't include App Review's message or guideline numbers, and Google's has none for policy rejections. Paste the message into Ploa or give it to your agent, and it's kept with the rejection, in the audit log. Google's reason is in Play Console's Publishing overview and in Google's email.

2. Your agent fixes the cause

   In the code or the store page, then asks to send the version back, with a new build or the same one, for your approval.

3. A reply, only if App Review asked something

   A message that asks for a fix needs no reply: the fixed build is the answer, and it goes back without any text. A message that asks a question or for information (such as Guideline 2.1, Information Needed) needs one, sent before the version goes back, because App Store Connect closes the thread then. Ploa says which it is.

Sending the reply. Apple's API can't post in App Review's thread, so the reply is yours to send. Your agent drafts it in English, short and factual, and shows it to you; it's kept under the version on the Release page with Copy reply, a link to the submission's thread in App Store Connect, and I sent it. Paste it there and press Send. Your agent can also put the reply in the version's App Review Information › Notes with the resubmission (up to 4,000 characters), so App Review reads it there too. To appeal a Google decision, use the link in Google's email.

Before you widen a rollout

Ploa reads stability from the stores themselves. Google Play: crash and ANR rates over 28 days, per version, against Play's bad-behavior thresholds (1.09% crashes, 0.47% ANRs), and the crashes people hit most. App Store: Apple's API has no crash rates, so Ploa gives what Apple offers: Xcode's metrics per version (launch time, hangs, memory, disk writes) with Apple's regressions, and each build's diagnostics. The app's Store tab › Quality shows the same.