Permission Dialog
// Definition
The OS-level prompt asking a user to grant an app access to a protected resource — camera, location, contacts, notifications. Permission dialogs are system UI (not your app's), so they behave differently per OS and version, and the app must handle every outcome: granted, denied, "ask every time", and permanently-denied (where the only fix is Settings).
// Why it matters
Permission flows are a top crash and abandonment source — an app that assumes "granted" and dereferences a null camera handle crashes; one that handles denial badly traps the user. QA matters because each state (grant/deny/deny-forever) is a distinct path, and the dialog is OS UI that automation must reach outside the app's own DOM.
// How to test
// Handle the OS permission prompt (not in-app UI) and test each outcome
await driver.$('~enable-camera').click()
// system dialog — Appium reaches it via the OS automation context
await driver.$('~com.android.permissioncontroller:id/permission_allow_button').click()
expect(await driver.$('~camera-preview').isDisplayed()).to.be.true
// deny path must degrade gracefully, not crash
// (re-run with the deny button; assert a fallback message, app still alive)// Common mistakes
- Testing only the "allow" path, never deny or permanently-denied
- Assuming the dialog is in-app UI (it's OS UI — needs the right automation context)
- Not re-testing after OS upgrades (permission UX changes between versions)
// Related terms
Native App
A mobile application built with platform-specific languages and SDKs — Swift or Objective-C for iOS, Kotlin or Java for Android. Native apps have full access to device hardware (camera, NFC, biometrics, GPS), run with the best performance characteristics, and follow each platform's UI conventions. For testers, native apps require platform-specific automation frameworks: XCUITest for iOS or Espresso for Android at the unit/integration layer, and Appium's UIAutomator2/XCUITest drivers at the end-to-end layer. Native apps are the gold standard for user experience but the most expensive to build and test across both platforms.
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.
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.