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
| Command | What 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 ls | Lists 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:
| Command | Compiles? | Installs to Device/Emulator? | Launches App? |
|---|---|---|---|
cordova build | Yes | No | No |
cordova run | Yes | Yes | Yes |
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
--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.