Adding Platforms & Building

Beyond the basic cordova run browser you saw earlier, the CLI has a full family of commands for managing which platforms your project targets and for building those platforms in different ways. This page covers the complete toolkit: managing platforms, the important distinction between building and running, targeting a specific platform, debug versus release builds, emulating without a device, and a quick troubleshooting habit for when builds start behaving strangely.

1. Managing Platforms

Platforms are added, removed, and listed with three straightforward subcommands:

cordova platform add android
cordova platform add ios
cordova platform rm android
cordova platform ls
CommandWhat It Does
cordova platform add <name>Downloads and generates a full native project for that platform inside platforms/, and records it as a dependency in config.xml-adjacent project files
cordova platform rm <name>Deletes that platform's generated project folder entirely
cordova platform lsLists which platforms are currently installed in this project, and which are available to add

2. `cordova build` vs. `cordova run`

These two commands are easy to mix up, but they do meaningfully different amounts of work:

CommandCompiles?Installs to Device/Emulator?Launches App?
cordova buildYesNoNo
cordova runYesYesYes

In short: cordova build produces an installable artifact (an APK for Android, for example) and stops there — useful in CI pipelines or when you plan to install the build manually. cordova run does everything build does and then also deploys the result to a connected device or running emulator and launches it, which is what you want during everyday development.

3. Building for a Specific Platform

If your project has multiple platforms added, you can target just one instead of building everything:

cordova build android

Omitting the platform name builds every platform currently added to the project, which is usually slower and often unnecessary while you're focused on one target.

4. Debug vs. Release Builds

By default, cordova build produces a debug build — signed with a throwaway debug key, suitable only for testing on your own devices and emulators. To produce a release build suitable for distribution, add the --release flag:

cordova build android --release
Note: A release build needs to be signed with your own private signing key before an app store will accept it — this involves generating a keystore and configuring signing properties, which is a big enough topic to get its own full page later in this track (Production Build & Submission). For now, just remember that --release is the flag that switches build modes.

5. Emulating Without a Physical Device

If you don't have a physical device handy, cordova emulate builds the app and launches it directly in a platform emulator/simulator, skipping the step of checking for a connected physical device first:

cordova emulate android

This requires that you've already created at least one Android Virtual Device (AVD) through Android Studio's Device Manager (or a Simulator target on iOS/Xcode).

6. Troubleshooting: When a Build Behaves Strangely

Occasionally, especially after updating the Cordova CLI, a platform SDK, or a plugin version, a project that used to build fine starts failing with confusing native-level errors. The standard first troubleshooting step is to clean cached build artifacts:

cordova clean

If that alone doesn't resolve it, the next most reliable fix is to remove and re-add the affected platform, which forces Cordova to regenerate its native project from scratch against your current config.xml and plugin set:

cordova platform rm android
cordova platform add android

Because platforms/ is disposable generated output (as covered on the Project Structure page), this is always safe — nothing you've hand-written lives in that folder.

Next: With platform management and building covered, move on to The deviceready Event — the single most important concept for writing Cordova apps correctly.