Building and Publishing

iOS calls it the bundle identifier, Android the application id; both are reverse-DNS strings, and Places uses com.irurueta.places for its production listing on both platforms. Keeping them identical across platforms is a convention rather than a requirement, but it makes deep-link configuration, analytics, and push registration far easier to reason about.

The identifier is the primary key of a store listing. Google Play refuses to publish two apps under one application id and refuses to ever reuse one, even after an app is unpublished; on iOS the bundle identifier is bound to an App ID record in the developer portal and to one App Store Connect app. Picking it carelessly is one of the few genuinely irreversible decisions in a mobile project.

Non-production builds get their own identifier — com.irurueta.places.dev, com.irurueta.places.preview — so that a developer build, a staging build, and the App Store build can all sit on the same phone at once without overwriting each other. On Android this also means three distinct entries in the launcher, which is why the display name gets an environment suffix to match.

The display name is what the launcher and the home screen show; it is short, it is not the same as the store listing title, and on Android it is truncated aggressively. Places ships as Places in production and Places (Dev) / Places (Preview) elsewhere.

Two numbers travel with every build and they do different jobs:

The build number is the single most common cause of a failed upload, and it is exactly the kind of bookkeeping worth handing to a tool: EAS Build’s autoIncrement (below) tracks the last number it used and bumps it, either locally from the project files or — with cli.appVersionSource set to remote — from EAS’s own server-side record, which is what makes the counter correct even when builds are triggered from several machines.

An Expo project’s identity lives in one config object. app.json is the static form and is enough for a project whose identity never varies; app.config.ts is the same object produced by a TypeScript function, and is what a project needs the moment any value depends on which environment is being built. The two can coexist — app.config.ts receives the parsed app.json as config and spreads it — and that is the arrangement Places uses.

That config is not merely metadata. With Expo’s Continuous Native Generation workflow, npx expo prebuild generates the android/ and ios/ directories from it, which means the identity, the icons, the splash screen, and every config-plugin-driven native setting are derived from a single checked-in TypeScript file rather than hand-edited in Info.plist and AndroidManifest.xml. A project that keeps android/ and ios/ in version control instead (the bare workflow, discussed in Tooling: Metro and Project Structure) edits those native files directly and uses the Expo config only for what the JavaScript side reads.

The app icon is a single square source image — 1024x1024 PNG, no transparency, no rounded corners, since both platforms apply their own mask — from which the build generates every size each platform wants. Android additionally wants an adaptive icon: a foreground layer plus a background colour or image, which the launcher composes and animates into whatever shape the device’s theme uses, so anything important must stay inside the central safe zone rather than running to the edges.

Splash screens are configured through the expo-splash-screen config plugin, which writes the native launch screen on both platforms from one declaration: an image, its width, a resize mode, a background colour, and a separate dark-mode variant. At runtime the same package controls when the splash screen goes away — SplashScreen.preventAutoHideAsync() at module scope holds it up, and SplashScreen.hideAsync() dismisses it once fonts are loaded and the first screen is ready to paint, which is what keeps a user from seeing an empty white frame between the launch screen and the app. Producing and sizing the underlying image assets is Images and Icons's subject.

Android requires every APK and App Bundle to be signed, and Google Play splits that into two keys:

The point of the split is recoverability. If the upload keystore is lost or compromised, Google can register a new upload key and the app keeps updating; if a self-managed app signing key were lost, the listing could never be updated again by anyone. Play App Signing is mandatory for new apps, and it is also what makes Play able to generate per-device split APKs from an App Bundle at all, since it has to re-sign them.

The keystore file and its passwords are the project’s most sensitive build-time assets. The keystore never goes into version control, the passwords never go into a file that does, and losing the backup of both is a genuine incident even with Play App Signing in place.

In a bare project, release signing is declared in android/app/build.gradle and the actual secrets are read from Gradle properties or the environment, never written inline:

The four properties are resolved from the environment first, so CI can inject them as masked secrets, and fall back to Gradle properties for a local release build. Those properties belong in the user-level ~/.gradle/gradle.properties, outside the repository:

Building then comes down to one Gradle task:

Both tasks run Metro’s release bundling as part of the build: the JavaScript is compiled to Hermes bytecode and packaged as an asset inside the artifact, so the release app has no dependency on a running Metro server (JavaScript Runtime and Hermes covers that compilation step).

An Android App Bundle (.aab) is not installable; it is a publishing format. Play uses it to generate and sign the exact split APKs each device needs — the right screen density, the right language resources, and the right native ABI — so a device downloads materially less than a universal APK would make it download. Play requires it for new apps and for updates to existing ones. An APK is still the right artifact anywhere Play is not involved: internal side-loading, a preview build handed to a tester, an alternative store, or a device with no Play Services at all.

minifyEnabled true turns on R8, which has replaced ProGuard as the shrinker and obfuscator while keeping ProGuard’s rule syntax and the proguardFiles name. It removes unreachable Java/Kotlin code, shortens names, and — with shrinkResources true — drops unreferenced resources. The failure mode to know about is reflection: anything looked up by name at runtime, which in a React Native app means native modules discovered through their generated registration code and any library relying on reflective instantiation, needs a -keep rule in proguard-rules.pro or it will be stripped and fail only in the release build. React Native ships consumer rules for its own code, and well-behaved libraries ship theirs, but a release build is never verified until it has actually been run — which is what installRelease above is for.

When APKs must be distributed directly and size matters, ABI splits produce one APK per native architecture instead of one fat APK carrying every .so:

Each split APK needs its own increasing versionCode, which is the usual reason this is more trouble than it is worth on Play — where the App Bundle does the same job automatically and correctly.

Google Play stages a release through four tracks, and an artifact can be promoted from one to the next without rebuilding:

Play also enforces a pre-launch report on uploaded builds, running the app on a set of real devices in Google’s lab and reporting crashes, accessibility problems, and security warnings before any user sees it.

iOS release builds turn on three records in the Apple Developer portal, and nearly every "code signing error" is two of them disagreeing. The full native version of this picture, with capabilities and devices included, is the signing figure on Membership, Signing, Capabilities and Info.plist:

Xcode’s Automatically manage signing creates and refreshes these for a team that has portal access, which is the right default for a small project. eas credentials does the same thing from the command line and stores the results server-side so that CI builds do not need a Mac with a populated Keychain; Fastlane’s match solves it a third way, by keeping the certificates and profiles in an encrypted git repository that every machine syncs from.

A local release build is an archive: in Xcode, select Any iOS Device as the destination and run Product > Archive, which builds in the Release configuration, runs Metro’s release bundling, compiles the JavaScript to Hermes bytecode, and produces an .xcarchive in the Organizer. From there, Distribute App signs an .ipa with the distribution certificate and uploads it to App Store Connect. The same thing runs headlessly with xcodebuild archive followed by xcodebuild -exportArchive, which is what Fastlane’s gym wraps; eas build --platform ios --profile production produces the same artifact on a hosted macOS worker.

Since React Native 0.84 the iOS dependency graph ships as precompiled binaries rather than as source, which removes the long C++ compile that used to dominate a clean release build; a release archive on 0.87 is meaningfully faster than it was on 0.76, though it is still the slowest step in the pipeline.

Uploads land in App Store Connect, which runs automated checks — signature validity, bundle id match, entitlements consistent with the profile, required icon sizes present, privacy manifest well-formed — and rejects the build before a human ever sees it if any of those fail.

Once a build finishes processing, TestFlight distributes it to testers:

Builds expire after 90 days, and each one carries release notes that testers see in the TestFlight app. It is the direct counterpart to Play’s internal and closed tracks, and the same discipline applies: no build goes to review that has not first been installed and launched from TestFlight.

App Store review is a human process against the published App Review Guidelines, and the rejections that recur in React Native projects are rarely technical:

Separately, Apple requires a privacy manifest: a PrivacyInfo.xcprivacy file declaring the data the app collects and, critically, the required reason APIs it uses — a short list of platform APIs (file timestamps, disk space, user defaults, system boot time) that can be used for fingerprinting and must be justified with an approved reason code. Third-party SDKs on Apple’s list must ship their own manifest and a signature, and the build aggregates all of them into the privacy report submitted with the app. React Native 0.87 and Expo SDK 57 ship manifests covering their own required-reason API usage, so the work left to a project is declaring its own data collection and checking that every third-party SDK it adds carries a manifest too. App Store Connect rejects an upload whose aggregated manifest is missing entries it can detect.