Emulators and simulators are fast, scriptable and essential for the development loop. They are also uniformly well-behaved, well-resourced and running recent software, which is exactly what your users' devices are not. A test suite that passes only on emulators is testing the code, not the product.
The problems that only appear on real hardware are consistent: performance on older processors, camera and sensor behaviour, memory pressure causing the operating system to kill the app in the background, manufacturer power management, and network behaviour on a real mobile connection rather than a simulated one.
A small physical device lab is more affordable than it sounds and more useful than a large one. Three or four devices chosen to represent the range your analytics show — a current mid-range handset, a two or three-year-old budget device, one iOS device a couple of generations back — cover most of what matters. Buying the newest flagship tests the case least likely to break.
Cloud device farms fill the gaps. Services from BrowserStack, LambdaTest and the cloud providers give access to a wide range of real devices for manual and automated testing, priced per minute or per parallel session. They are the right answer for breadth and for running an automated suite across many device models.
Reserve the physical devices for the things a farm handles poorly: prolonged battery behaviour, real network conditions, camera quality, and the informal testing that happens when someone carries the app around for a day. That last one finds problems no scripted suite is looking for.
Test under constrained conditions deliberately. Fill the storage, throttle the network, enable the manufacturer's battery saver, and leave the app in the background for an hour. These are ordinary conditions for a large share of users and unusual ones for a test device kept clean and charged.
