A Device Pool is the set of phones and tablets your Mobile Runs are allowed to use. Every Mobile Test Case uses one, and each Test Project has a default Device Pool so tests work before you configure anything. You create your own when you want to pin Test Cases to particular models, split Android from iOS, or keep a slower device out of everyday runs.

The Device Catalog lists everything available to your organization. Search it by name, and filter by Platform, by Type, and by whether a device is already In pool.

Each device is marked Physical or Emulator. A physical device is real hardware, which is what you want when the behaviour under test depends on the actual phone. An emulator is faster to obtain and is usually enough for flows that only exercise your own Mobile App.

As you select, the Device Catalog previews the change as +n to add and -n to remove, so you can review before selecting Apply changes.

Each Device Pool carries an availability badge, which tells you whether Mobile Runs will start straight away or queue.

If your Mobile Runs queue often, the Device Pool is too small for the parallelism you are asking for. Add devices, or lower the parallelism on the run.

Mark a Device Pool as the Default pool and every Mobile Test Case uses it automatically unless you pick another one. A Test Project has exactly one default.

Device Pools are archived rather than deleted, so nothing referencing one breaks.

Archiving removes the Device Pool from device selection. Test Cases that still point at it fall back to the Default Pool, which the interface states directly: "If the selected pool is archived, the Default Pool will be used instead." Archived Device Pools stay listed behind the Show archived filter, so you can bring one back.

Create one Device Pool per Platform, an Android pool and an iOS pool. A Mobile Run targets one pool, so this keeps each platform's devices and results cleanly separated.

Archive it. Archiving keeps every Test Case that references it working, because they fall back to the Default Pool, and the pool stays available behind the Show archived filter if you want it back. Re-check any Test Case that depended on a specific model, since the devices change.

Look for the Warm badge in the Device picker. A warm pool or device is already running your Mobile App, so the run starts without waiting for a handset to boot. Where no warm option is offered, watch the availability badge instead: Busy means every device in the pool is working, so add devices or lower how many Test Cases you run at once.

Thunders works just as well with both, so pick whichever suits the run. Emulators are quick to get hold of and cost less, which makes them a strong default for flows that exercise your own Mobile App. Physical devices give you the real thing when hardware matters, for camera, biometrics or performance behaviour. Many teams keep a pool of each and use both.

Archived Device Pools are never destroyed. They stay listed behind the Show archived filter with their devices intact, so you can review what a past pool contained or bring it back into use.