Goal
Prepare store credentials and understand which metadata fields are pushed by API versus tracked as Play Console manual gates.Prerequisites
- The app already exists in Google Play Console or App Store Connect
- A clean mobile release has been uploaded to StackShift
- mobile_submit is enabled on the plan
Workflow
1
Create a Google service account, enable the Play Developer API, invite the service account to Play Console, and paste its JSON under Store credentials.
2
Create an App Store Connect API key with app-management permissions, copy issuer ID, key ID, ASC app ID, bundle ID, and the .p8 key.
3
Save and verify credentials before creating a submission.
4
Submit an AAB/APK to a Play track or an IPA to TestFlight/App Store review from an existing mobile release.
5
Edit listing text, privacy, rating, pricing, availability, and media metadata, then push it from the Store tab.
Google Play prerequisites
- Enable the Google Play Developer API on the Google Cloud project that owns the service account.
- Invite the service-account email in Play Console and grant release-management access to the target app.
- Use the exact package name from Play Console; StackShift validates it against release metadata.
App Store Connect prerequisites
- Create an App Store Connect API key and keep the .p8 private key available for the Store credentials form.
- Copy issuer ID, key ID, ASC app ID, bundle ID, and team ID from App Store Connect.
- Install and configure the dedicated submit-worker image with APPLE_TRANSPORTER_PATH for IPA delivery.
Play manual gates
Google Play does not expose every listing and compliance surface through the public API. StackShift stores those canonical values, validates them, and creates required manual gates with console links for Data Safety, content rating, pricing, and availability.Expected result
Store credentials verify, submissions are tracked through terminal states, and Play-only console tasks appear as explicit manual gates.