Send a TestFlight / Play build

This is the moment CapWrapp exists for.

Before you tap the button

• Capacitor is on the default branch (ios/ and/or android/)
• Apple and/or Google show Ready in Settings
• Pipeline is installed on the default branch
• Environment keys that the website needs are filled (or you accept a possible white screen)

If something is missing, Upload for testing explains the blocker and links to the setting.

The modal

1. Select a commit on Overview.
2. Upload for testing.
3. Tick TestFlight, Play Internal, or both — independently, as long as that platform is ready.
4. Optional version number (the user-facing 1.2.0). Leave blank to bump. Build numbers (CFBundleVersion / versionCode) increment automatically so Apple / Google accept every upload.
5. Confirm.

CapWrapp tells GitHub: “run capwrapp-native.yml on this SHA.” You can close the modal and watch Overview or History.

After success

Testers install from:

• iOS: TestFlight app
• Android: Play Console internal testing opt-in link

Send it to the stores

When testers are happy, open Releases in the app’s sidebar. It shows what is on each store and what is in test.

• App Store. Next to the latest TestFlight build, Send to review attaches it to the App Store version with the same number (CapWrapp creates the version if needed, set to release once approved), writes What’s New and submits it to App Review. New version prepares an App Store version ahead of time.
• Google Play. Next to the latest internal release, Send to production promotes it to the production track with your What’s New notes, and Google reviews it. It stays off the public store until Google approves.

Write What’s New once in your main language, then translate it into your other listing languages in the same dialog. Apple doesn’t show What’s New on an app’s first version, so it is skipped there.

Both stores still check the forms CapWrapp doesn’t fill: agreements, privacy, age rating, pricing, Data safety and, for new personal Google Play accounts, the 12-tester closed test. Those are the App Store submission checklist and the Google Play submission checklist.

One run at a time

If a native run is already dispatching or running, a second confirm is refused. Wait or cancel the GitHub Actions run.

Failed run

Open the Actions log from the run card. Typical causes are in Troubleshooting. Fix, push if needed, pick the new SHA, ship again.