Stores and apps

Ploa works in your own App Store Connect and Play Console accounts. You connect each store once for the whole workspace; after that your agent adds each app, links it to its code and tells you the few steps only you can take in the stores.

Set up this app for the App Store and Google Play with Ploa. What's left before this app can have its first build? Suggest a bundle ID and package name for this app, and register the bundle ID with Apple.

The tools behind these requests: Every MCP tool › Start and setup, and for the steps that wait for you, Steps only you can do.

Who does what

Who	What
Your agent	Runs the setup guide (`ploa_setup_guide`) and shows you the stages; suggests the app's ID when it has none; links the folder to Ploa (`ploa_link`); registers the bundle ID with Apple; asks you the questions only you can answer, all in one message, and keeps working while you're in the stores' consoles.
Ploa	Makes the signing certificate with Apple, sees by itself when Google lets it into Play Console, finds the apps your accounts already have, and ticks each of your steps off once it sees it done in the store.
You	Connect each store (a key and an invite, once), create the app in each store, accept the stores' agreements, and decide the app's languages, countries, price, audience and contacts.

Every step for you comes from the setup guide, with a direct link to the exact page in App Store Connect, Play Console or Ploa. Run it again (or ask your agent what's left) after each step.

Connect the App Store

Ploa reaches App Store Connect with an API key of your team. One key serves every app in the account. It takes the Account Holder or an Admin of the App Store Connect team, and a membership in the Apple Developer Program ($99 a year; Apple checks who you are, often within two days).

Open the keys page
In App Store Connect, Users and Access › Integrations › App Store Connect API › Team Keys. The first time, the Account Holder clicks Request Access once.
Make the key, with Admin access
Press +, name it Ploa, choose Admin and Generate. Admin lets Ploa make the signing certificate and register bundle IDs for you, besides apps, versions, TestFlight, in-app purchases, prices and sales reports. App Manager works for most things, but can't read sales.
Download it
Download the AuthKey .p8 file (Apple offers it once only). The Issuer ID is shown above the list of keys.
Give it to Ploa
On the dashboard, Store connections › App Store: drop the file and paste the Issuer ID. Ploa reads the key's ID from the file's name, checks the key and makes the signing certificate. If the file was renamed, it asks for the Key ID too.

After you drop the file, Ploa keeps it sealed in its vault, encrypted and locked with Ploa's key in Google Cloud HSM, and never shows it again, to anyone. You can delete the .p8 from your computer.

The card shows whether the signing certificate is ready. If Apple refused to make it, the reason is on the card, and Make it now tries again once that's fixed (the next iOS build also tries by itself).

Connect Google Play

Ploa reaches Google Play as an account it makes for your workspace. No Google Cloud on your side, and no key file. You need a Google Play developer account ($25 once; an organization account needs a D-U-N-S number). There are two ways to let Ploa in:

Sign in with Google, when the Google Play card offers it: sign in with the Google account that owns your Play Console, and Ploa adds its own account there with the permissions it works with. Google's sign-in is used once and nothing of it is kept. If Google doesn't say which developer account is yours, the card asks you to paste any Play Console address from the browser's bar.
Invite Ploa's email yourself:

Copy Ploa's email
On the dashboard, Store connections › Google Play › Connect Google Play, and copy the email it shows.
Invite it in Play Console
Play Console › Users and permissions › Invite new users, and paste the email.
Give it permissions
Under Account permissions, tick Admin (all permissions), then Invite user.
Wait for Google
Ploa sees by itself when Google lets it in, usually within minutes (sometimes a few hours), and sends a notification. Until then the card says Waiting for Google. You can leave the page.

What Ploa uses those permissions for: reading apps, tracks, listings, products and crash rates; sending builds to testing tracks; promoting to production and staged rollouts (each still waits for your approval); testers; the store listing and App content; products and subscriptions; orders and refunds; replying to reviews; and reports. Not managing your Play Console's users.

Already have a service account with a JSON key? Store connections › Google Play takes it instead, under its link. The service account needs Admin in Play Console › Users and permissions, and the Google Play Android Developer API turned on in its Cloud project.

Disconnecting stops Ploa working in your Play Console, and its apps move to another Google Play account of the workspace if there is one. Ploa's account stays in Play Console › Users and permissions until you remove it there.

Several accounts, and other stores

Another account for the same store (a second Apple team, a client's Play Console): Connect another account on that store's card. Each app uses one connection per store, chosen in its settings.
Galaxy Store and Microsoft Store: under More stores. Ploa shows where the app stands there (its review or certification, and what's on sale); it doesn't build or submit for them.

When a store says "not allowed"

Ploa asks for the least it needs. When a store refuses something for lack of a permission, Ploa's message names the permission to add and where. For sales reports, the App Store key needs Admin, Finance or Sales, and the Play account needs "View app information and download bulk reports" and "View financial data".

Add an app

Your agent adds the app when it links the folder: Ploa finds it by its bundle ID or package name in the workspace's connections, or adds it. On the dashboard's Apps page you can also:

Pick it from your store accounts: the apps your connections can see are listed; add one in a tap. The same app under another ID in the other store (com.example.ios and com.example.android) is offered to join the one already here.
Add it by its ID: a bundle ID, a package name or both. iOS and Android pair up by their identifier.

A brand-new app

When the app has no bundle ID or package name yet, the setup guide suggests a few. Choose with care: the ID is the app's identity for good. People never see it (the store name is separate and can change any time), it's unique worldwide, and it can't change once the app is in a store (registered at Apple, or the first build on Google Play). A new ID is a new app, without its reviews, ratings or users.

Neither store has an API that creates an app, so this step is yours. Your agent registers the bundle ID with Apple first, so you only pick it:

App Store Connect: Apps › + › New App: platform iOS, the name (no other app on the App Store may have it; if it's taken, add a few words), the primary language, the bundle ID, a SKU, and Full Access.
Play Console: Create app: the app's name, its package name (Play asks for it now, and it's permanent), the default language, App, and Free or paid (a free app can't become paid later). Then tick the two declarations (Developer Program Policies, US export laws): they're your own statement, so your agent never ticks them.

The app's page in Ploa shows these values with copy buttons, and ticks each store off once it has the app.

An app already in the stores

It's brought in as it is. Its versions, testers and store page are read from the stores. An app whose builds come from somewhere else (EAS, Xcode, Fastlane) can stay that way: in App settings › The app, set Where it's built to Elsewhere, and Ploa sees each build in the store and runs the rest (testers, the store page, review and release).

Link it to your code

Your agent does it with ploa_link in the app's folder. Without an agent, run ploa init there. Either way Ploa finds the app by the IDs in the project (an Expo config, a Gradle applicationId, or the Xcode project's bundle ID; Flutter, React Native and Capacitor apps by their native projects) and writes ploa.json: the app's ID in Ploa and the server. It holds no secrets and is fine to commit, so your team and CI share it.

Several connections for a store? Name one: your agent passes it, or ploa init --apple "Team name" --google "Account name".
An app built another way (Unity, .NET MAUI…): ploa init --aab app.aab --ipa app.ipa reads the IDs from what it built.
One repository, several apps: each app's folder gets its own ploa.json; Ploa finds each app in its folder.

The app's settings

Each app has an App settings tab on the dashboard. Its page The app holds:

The app's name in Ploa and in each store, and Where it's built (on Ploa, or elsewhere).
One card per store: the connection it uses, its bundle ID or package name, the iOS signing identity or the Android upload key, and how builds go up (straight from the build machine or through Ploa; see Builds and signing). Another store can be added or one removed here.
The GitHub card: the repository, folder and release branch builds come from (see GitHub).
RevenueCat, if you use it (see In-app purchases).
Removing the app from Ploa. It never deletes anything in the stores.

The tab's other page, Web, holds the app's website or web app (see Web).