Submit an Expo Fitness App to the App Store

Local development runs your app. A store release has a different job: it must identify your app, produce a signed binary, pass through a platform's upload flow, and include accurate store and privacy information. An Expo Go preview is useful for checking the app on a device, but it does not create the App Store or Google Play release for you.

This guide follows the current Expo, Apple, and Google documentation checked on 15 October 2026. The practical route is: configure the app identity, prepare signing credentials, build the production binary, upload it to the right store track, complete the listing, and satisfy the store's review or testing requirements.

1. Set the app identity before buildingCopy Anchor Link

A store build needs stable identifiers. In the Expo app config, set the iOS bundle identifier and Android package name to the identifiers you intend to keep. For Android, Expo's current EAS Submit guide also requires the package name in app config. Treat these values as part of your release identity, not as labels to change casually after setup.

Keep build profiles explicit in eas.json, and inspect each profile's actual distribution and platform settings before invoking it. EAS Build creates native binaries; it does not decide whether your app identity, privacy disclosures, content, or listing are ready.

For example, the OTF Fitness Kit's current documentation describes an Expo SDK 54 app with development, preview, and production profiles. That is an example configuration to inspect and adapt, not a promise that your own app is ready to ship unchanged.

2. Decide who manages signing credentialsCopy Anchor Link

Apple and Android require signed store builds. EAS Build can create and manage signing credentials, or a team can provide credentials it manages itself. Make the choice deliberately and document who can rotate or recover each credential. Do not commit private keys, passwords, or service-account files to the application repository.

For iOS, you need an Apple Developer account with permission to create or use the required app-signing credentials, and a bundle identifier in your app config. For Google Play, the EAS Submit setup includes a Play developer account, an app record in Play Console, the Android package name, and a Google service-account key assigned for submissions. The service-account key authorizes the upload flow; it is separate from the Android key used to sign the app.

For CI, configure the documented credentials before enabling a non-interactive job; it cannot answer prompts that an interactive command can.

3. Build a production binaryCopy Anchor Link

Use a production build profile for the store artifact and review the profile settings before starting. Typical commands are:

eas build --platform ios --profile production
eas build --platform android --profile production

EAS Build runs the native build and returns a signed artifact when its credentials and configuration are ready. An Android store upload uses an Android App Bundle (.aab); Expo's Android submission guide says its default production profile creates one. An .apk profile is useful for device installation but is not the Play Store upload artifact described in that guide.

Record the build with its source commit. If it fails, fix the specific configuration, credential, or native dependency shown in the EAS log; rerunning cannot repair a wrong identifier or unassigned key.

4. Treat upload and release as separate stepsCopy Anchor Link

eas submit uploads a binary. It does not complete your store listing or guarantee publication.

On Apple platforms, EAS Submit uploads the .ipa to App Store Connect. Once Apple processes it, it can appear in TestFlight. To distribute it through the App Store, complete the app's metadata and screenshots in App Store Connect, select the build, and submit it for App Review. A TestFlight upload is a testing step, not an automatic public release.

On Google Play, EAS Submit uploads the .aab to a Play Console track. Expo documents that a first submission creates an internal-testing release by default; the release can remain in draft until the required listing and setup tasks are complete. Choose the intended track and release status in eas.json, then verify the result in Play Console before telling testers or users that the app is available.

5. Make store and privacy information match the appCopy Anchor Link

Before review, prepare the listing, screenshots, support details, ratings, and any reviewer instructions needed to reach account-based features. Apple asks for information App Review needs, such as a demo account when sign-in is required.

Apple requires App Store Connect privacy information for new apps and updates. Describe the data collected or shared by your app and its third-party partners, based on the version you are submitting. Apple also requires a privacy policy URL for iOS apps. Some commonly used third-party SDKs have privacy-manifest requirements; check Apple's current list and validate the manifests that apply to the SDKs actually included in your binary.

Google Play's Data safety form is a separate declaration. Review what your app and its SDKs collect and share, and keep the form accurate as those practices change. Google says the form and a privacy-policy link are needed even when an app does not collect user data, with an exception for apps active only on internal testing tracks. Do not copy an answer from an iOS privacy form: the stores use different questions and categories.

For a fitness app, inspect the exact build and its SDK behavior; sample screens and schemas do not determine your privacy answers.

6. Test the path the store will actually receiveCopy Anchor Link

Test a signed release candidate on real devices: sign-in, recovery, network failures, permissions, any purchase flow, and data export or deletion. Confirm the app identifier and backend environment match the planned upload.

TestFlight, Play Console tracks, Expo Go, and EAS internal distribution are distinct routes. TestFlight uses an iOS build uploaded to App Store Connect; Play internal and closed tests use Play Console tracks.

There is an additional Google Play requirement for some new accounts: personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access. This requirement is account-specific, so check your account's Play Console status and the current Google help page before you plan a launch date.

An over-the-air JavaScript update also has a boundary. Expo Updates can deliver compatible JavaScript and asset changes, but a change that needs new native code must be included in a new store build. Use the store submission route when native modules, permissions, entitlements, or other binary-level configuration changes.

A practical preflight checklistCopy Anchor Link

Before you submit, confirm that:

• The bundle identifier and Android package name are the intended long-term identifiers.
• The production profiles create store-suitable, signed artifacts.
• Each platform's credentials are assigned and available to the people or CI jobs that need them.
• The Apple build is in App Store Connect and the Android build is on the intended Play Console track.
• Store screenshots, metadata, privacy declarations, and review access match the actual binary.
• The app has been tested using the same build type and environment you intend to release.
• You know what still requires a manual store action after upload.

Where the Fitness Kit fitsCopy Anchor Link

As checked on 15 October 2026, OTF lists the editable Expo and React Native Fitness Kit at $99. Its docs describe development, preview, and production EAS profiles, with native builds and submission to TestFlight and Play internal testing. You still configure your identifiers, accounts, credentials, listings, privacy answers, and review process; the kit does not submit or certify your app for you.

If you want to inspect that codebase, see the Fitness Kit and its current setup documentation. Or start here to choose a template for your project.

SourcesCopy Anchor Link

• Expo, EAS Build — checked 15 October 2026.
• Expo, Submit to the Apple App Store with EAS Submit — updated 12 October 2026; checked 15 October 2026.
• Expo, Submit to the Google Play Store with EAS Submit — updated 9 October 2026; checked 15 October 2026.
• Expo, Submit to app stores — updated 12 October 2026; checked 15 October 2026.
• Expo, Distribute an iOS app with TestFlight — checked 15 October 2026.
• Expo, EAS Update — checked 15 October 2026.
• Apple, Submitting apps for review — checked 15 October 2026.
• Apple, Manage app privacy in App Store Connect — checked 15 October 2026.
• Apple, Privacy manifests for apps and third-party SDKs — checked 15 October 2026.
• Google Play, App testing requirements for new personal developer accounts — checked 15 October 2026.
• Google Play, Data safety section requirements — checked 15 October 2026.
• OTF, Fitness Kit product page and setup documentation — checked 15 October 2026.