Skip to main content
Treat release configuration as code. Review app identity, environment selection, EAS profiles, native service files, and verification results for every release candidate.

​
Configuration sources

app.config.js reads EXPO_PUBLIC_APP_ENV. Production uses the base bundle ID and scheme, preview adds .preview and -preview, and development adds .dev and -dev.

​
EAS profiles

The checked-in EAS configuration defines:
  • dev and preview internal-distribution builds
  • dev-store and preview-store store builds and matching submit profiles
  • production internal-distribution builds
  • production-store store builds and submission
Root scripts such as bun run build:preview and bun run submit:preview call Nx targets. Inspect the corresponding target and EAS profile before running it; similarly named build and submit commands do not always use the same distribution profile.

​
Native services and secrets

The app selects environment-specific Android and iOS Google service files and changes OneSignal mode for store environments. Confirm the expected service files and EAS environment variables exist before building. Never commit API keys or signing credentials. Application code should consume validated configuration through @amisi-mobile-starter/config rather than reading process.env directly.

​
Release checklist

  1. Replace starter app name, bundle ID, scheme, owner, slug, domains, and EAS project identifiers.
  2. Confirm icon, adaptive icon, splash, and favicon assets.
  3. Verify the selected build profile, channel, environment, and distribution type.
  4. Confirm Firebase, OneSignal, authentication, subscription, and update configuration for that environment.
  5. Test universal links, custom schemes, permissions, sign-in, notifications, purchases, and app lock on a native build.
  6. Run Expo diagnostics:
  1. Run the canonical repository gate:
  1. Submit with the platform-specific command when you do not intend to submit both stores:
Native dependency, plugin, permission, identity, icon, and splash changes require a new native build. Use over-the-air updates only for changes compatible with the installed runtime version.