CI/CD Pipeline for React Native to TestFlight and Play

WHAT THIS TESTS Whether you can wire automated, repeatable builds that handle the platform split and the signing material safely.

A GOOD ANSWER COVERS The workflow triggers on a version tag or a release branch. It checks out code, sets up Node and the JS dependency cache, installs packages, and restores native caches like CocoaPods and Gradle. iOS must build on a macOS runner: it imports the distribution certificate and provisioning profile, ideally via Fastlane match pulling from a private repo, builds and signs the archive, and uploads to TestFlight with Fastlane pilot or the App Store Connect API. Android builds on a Linux runner: it decodes a base64 keystore from secrets, signs the AAB, and uploads to the Play internal testing track via Fastlane supply or the Play Developer API. All credentials live in encrypted GitHub Actions secrets, never in the repository. You parallelize the two platforms as separate jobs and gate deploy steps behind a successful build and test stage.

COMMON WRONG ANSWERS Storing a keystore or .p12 certificate in the repo. Trying to build iOS on a Linux runner. Hardcoding the App Store Connect API key in the workflow file. Skipping caching, which makes builds painfully slow.

LIKELY FOLLOW-UPS How Fastlane match shares certificates across the team and CI. How to inject a base64-encoded keystore and decode it at runtime. How to bump build numbers automatically and avoid duplicate version uploads.

ONE CONCRETE EXAMPLE Pushing tag v2.3.0 starts two jobs. The macOS job runs match, gym, and pilot to land a build in TestFlight; the Linux job decodes the keystore, runs gradle bundleRelease, and supply uploads the AAB to Play's internal track. Both read keys from encrypted secrets, leaving the repo clean.