A textbook circuit describes logical intent. A hardware backend adds physical facts: which qubits can talk directly, what native gate set exists, what timing or pulse constraints apply, and which qubits currently behave better or worse.

That means “the same circuit” can compile into different gate sequences and different depths depending on the backend. Device choice is not packaging. It changes the workload.

For an IBM backend, transpilation typically decomposes the circuit into the backend’s supported basis gates, inserts routing operations so non-adjacent qubits can interact, and applies optimization passes to reduce cost. In practice, this can add SWAPs, change the order of operations, and reshape the depth substantially.

So yes, if you specify the exact backend, you are effectively asking the compiler to produce a circuit tailored to that device. That is why two hardware runs with the same logical algorithm can behave differently even before any stochastic noise enters.

If you use a local simulator with no backend-specific target, the compiler usually assumes a generic gate model or the simulator’s supported instruction set. There may be no connectivity penalty, no calibration-aware layout choice, and no need to decompose toward a specific chip topology.

That makes simulators excellent for algorithm debugging and logical verification, but poor substitutes for hardware reality unless you deliberately configure them to emulate a backend and noise model. “Runs on simulator” is therefore evidence about logic, not automatic evidence about deployability.

When you pick an IBM device, the circuit is compiled toward that hardware. When you do not, the circuit is compiled for a more generic target. Both are valid, but they answer different questions. Hardware-targeted transpilation tells you what will actually run; simulator-targeted transpilation tells you whether the algorithm is logically coherent in a simplified world.