Production Build & Submission

Previous Next

Every build you've made so far in this track has almost certainly been a debug build — fast to produce, unsigned, and meant only for your own device or emulator during development. Getting an app in front of real users on Google Play or the App Store is a different process: a release build that's optimized, cryptographically signed, and packaged the way each store expects. This page walks through that release pipeline for Android in detail, gives an honest (Mac-required) overview of iOS, and covers the versioning step you must not skip before any submission.

Debug Build vs. Release Build

	Debug build	Release build
Command	`cordova build android`	`cordova build android --release`
Speed	Fast, minimal optimization	Slower — code shrinking/optimization runs
Signing	Auto-signed with a throwaway debug key	Must be signed with your own keystore
Installable on other devices?	No (or only with debugging enabled)	Yes — this is the artifact you submit to a store

# Development, day to day
cordova build android

# Preparing to ship
cordova build android --release

Important: a release build's output is unsigned by default until you apply your own signing key to it — an unsigned release APK/AAB cannot be installed on most devices or accepted by Google Play at all. Signing is not optional; it's the next step.

Generating and Using an Android Keystore

Android requires every release build to be signed with a private key that proves the app came from you, and that a future update genuinely came from the same developer. You generate this key once, into a file called a keystore, using the keytool utility that ships with the Java JDK:

keytool -genkey -v -keystore my-release-key.keystore -alias my-app-alias -keyalg RSA -keysize 2048 -validity 10000

keytool will prompt for a keystore password, a key password, and some identity details (name, organization, and so on) that get embedded in the certificate. That keystore file and its passwords are then used to sign your release build, either through Android Studio's build dialog or by passing signing properties to the Cordova/Gradle build directly.

Critical — back this up: if you lose your keystore file, or forget its password, there is no recovery process. Google cannot restore it for you. You will permanently lose the ability to publish updates to that same app listing on the Play Store ever again — your only option would be publishing an entirely new listing that existing users can't automatically update to. Store a copy of your keystore file and both passwords somewhere durable and private: a password manager, an encrypted backup, or a secure company vault. Never rely on "it's still on my laptop" as your only copy.

Submitting to Google Play

With a signed release build in hand, publishing to Google Play involves a few concrete requirements beyond just uploading a file:

Requirement	Detail
Android App Bundle (.aab)	Google Play now requires new apps to be submitted as an `.aab` rather than a raw `.apk` — the Bundle format lets Google Play generate and serve optimized APKs per device instead of shipping one bloated universal file
Play Console listing	Created at `play.google.com/console` — this is where you configure your app's store page, pricing, and countries of availability
Screenshots & description	At least a couple of device screenshots, a short and long description, and a feature graphic are required before a listing can go live
Privacy policy URL	Required for essentially every app today, even simple ones — Google will reject a submission that requests any sensitive permission (camera, location, storage) without a linked privacy policy page

# Build the Android App Bundle for release, then sign it before uploading
cordova build android --release -- --packageType=bundle

iOS Signing and Submission (Overview)

iOS follows the same conceptual shape — sign your build, then submit it — but the mechanics are more involved and require tooling that's macOS-only:

Piece	What it's for
Apple Developer account	A paid ($99/year) enrollment required before you can sign or submit any iOS app
Provisioning profile	Ties your signing certificate, your app's identifier, and (for testing) specific device IDs together, authorizing the build to run or be distributed
Xcode	The actual build, archive, and upload-to-App-Store-Connect steps all happen through Xcode, even for a Cordova project — there's no CLI-only path to the App Store

Mac required: there's no way around it — archiving and submitting an iOS build happens inside Xcode, which only runs on macOS. Plan for access to a Mac (owned, borrowed, or a cloud Mac service) before you're ready to ship the iOS side of your app.

App Store Review: Hybrid Apps Get Extra Scrutiny

Apple's App Store Review is generally stricter than Google Play's automated checks, and it's an open secret that hybrid/WebView-based apps sometimes draw extra attention if they feel "too web-like" — slow transitions, obvious browser-style scrolling, UI that doesn't respect iOS conventions. This isn't a rule written down anywhere specific, but it's a pattern developers report often enough to take seriously.

Good news: the polished, native-feeling UI work covered in Using a UI Framework — smooth transitions, platform-appropriate navigation patterns, responsive layouts — directly helps here. An app that behaves like a native citizen, even though it's a WebView underneath, genuinely improves review odds and, just as importantly, makes for happier users.

Version Your App Correctly Before Submitting

Both stores track your app by version, and both will reject a re-submission that doesn't increment it correctly. Cordova apps declare this centrally in config.xml, covered in full in the config.xml Deep Dive lesson:

<widget id="com.example.myapp" version="1.2.0" android-versionCode="7">

Attribute	What it controls
`version`	The human-readable version string shown to users on both stores (e.g. "1.2.0") — bump this for every meaningful release
`android-versionCode`	An internal integer Google Play uses to determine "newer than the last one" — it must strictly increase with every single Play Store upload, even a tiny bug-fix release, or the upload is rejected outright

Before every submission: double-check both the version string and the version code changed from your last published release. Forgetting to bump android-versionCode is a common, easily-avoided reason a Play Console upload gets rejected at the last step.

Up next: A signed, submitted build is only half the story — head to Performance Tips to make sure it actually feels good to use.

Previous Next