Emulator vs Simulator
// Definition
Two terms often used interchangeably but with an important technical distinction: Android uses emulators (which emulate the hardware and run the actual Android OS), while iOS uses simulators (which simulate the OS environment on macOS but do not emulate ARM hardware). The practical consequence is that iOS simulators cannot run compiled ARM binaries and do not expose hardware like Face ID or GPS the same way a real device does. Android emulators run closer to real device behaviour but are still slower than physical hardware and miss OEM-specific customisations. For test planning, both are suitable for functional and regression testing of happy paths. Only real devices expose reliable cellular network behaviour, hardware-specific rendering, and biometric prompts.
// Related terms
Real Device Testing
Executing mobile tests on physical hardware rather than emulators or simulators. Real devices expose OEM-customised operating system behaviour, hardware sensors (camera, NFC, biometrics), accurate memory constraints, and battery draw that emulators cannot replicate. Some bugs — particularly around network transitions, memory pressure, specific display resolutions, and vendor-modified system apps — only appear on real hardware. Cloud device farms (BrowserStack App Automate, Sauce Labs Real Device Cloud, AWS Device Farm) provide access to hundreds of device/OS combinations without requiring physical ownership or lab infrastructure. The pragmatic strategy for most teams: run functional suites on emulators in CI for speed, then run a targeted regression matrix on real devices before each release.
Mobile Testing
The practice of verifying mobile applications — native, hybrid, and mobile web — across devices, OS versions, and screen sizes. Mobile testing encompasses functional testing, gesture interactions, permissions handling, context switching for hybrid apps, and OEM-specific behaviour that emulators may not replicate.
iOS Testing
Testing iOS applications using XCUITest as the underlying automation engine. Appium wraps XCUITest through WebDriverAgent — a signed XCTest agent installed on the target device or Simulator. iOS testing requires macOS and Xcode and uses XCUIElementType accessibility attributes and NSPredicate strings for element location.
Android Testing
Testing Android applications using UIAutomator2 as the underlying automation engine. Appium communicates with UIAutomator2 over ADB (Android Debug Bridge), enabling interaction with any visible element including system dialogs. Elements are located by resource-id, content-desc, or UiSelector queries.