🏗️ Framework Architecture (SOLID + POM)

Framework Architecture (SOLID + POM): Appium's Java client EXTENDS Selenium's WebDriver interface — which is why every piece you have written up to this tab (AppiumBy locators, A

Appium's Java client EXTENDS Selenium's WebDriver interface — which is why every piece you have written up to this tab (AppiumBy locators, AppiumFluentWait, @Test methods) faces the SAME architectural problem as Selenium: without a DriverManager, every test creates its own driver, and threads collide under parallel execution. But there is a SECOND layer here that does NOT exist in Selenium at all: the same "Login Screen" scenario has COMPLETELY different locators on Android (`resource-id`) versus iOS (`accessibility id`) — the code implements the same business rule (login) while facing TWO different technical realities on TWO platforms. Second analogy: like an international company selling the same product in different countries — the product (the scenario) is THE SAME ("log in"), but the packaging/language/plug type (locators, native SDK) CHANGES by country (platform); the sales team (the test) says "sell the product", and a logistics layer (POM) decides which packaging to use. But since Android tests already work, why not just add if/else instead of writing a SEPARATE class for iOS? Because the number of platforms can exceed two (Android + iOS + tablet variants), and modifying the existing class for every new platform risks breaking the other platforms' tests — exactly the problem OCP solves. Java comparison: this is the SAME motivation as a `PaymentGateway` interface implemented separately by `StripeGateway`/`PaypalGateway`. QA context: without cross-platform abstraction, news that "the login flow changed" breaks BOTH Android AND iOS test files separately; with the right abstraction, the ONE interface contract stays fixed, only the platform-specific implementation is updated.

Build Your Appium Framework Step by Step

The 4 pieces below are the BIG PICTURE of the architecture you are about to build piece by piece in this tab. They all start locked — the first time you correctly finish that step's "Try It Yourself" practice, that piece flips from locked to BUILT.

🧭 Step 1 — The Big Picture: The Cross-Platform Framework Mindmap

The same architecture is shown here from five angles: first the main flow (who calls whom while a test runs), then the setup flow (from capabilities to the driver), then "device parallelism" (IN ADDITION to Selenium's thread parallelism, there is also a device/emulator dimension here), then the data-sharing scope (device matrix / capabilities), and finally a "does / does not" list for every class.

3️⃣ Device Parallelism — IN ADDITION TO Selenium's Thread Parallelism

Thread-1 → Pixel 7 (Android 14)

Thread-2 → iPhone 15 (iOS 17)

Thread-3 → Samsung S23 (Android 13)

In Selenium, ThreadLocal only solved "which thread owns which browser tab". In Appium, the SAME ThreadLocal pattern applies, but one more dimension is added: each thread's driver can connect to a DIFFERENT PHYSICAL device or emulator — the CapabilitiesFactory determines which device/OS version combination each thread receives. On a device farm (e.g. BrowserStack App Automate), this lets the SAME test scenario run on 20 different real devices SIMULTANEOUSLY — without ThreadLocal, those 20 devices would MIX UP each other's commands.

4️⃣ Data-Sharing Scope — Where Does Test Data Come From?

LoginScreen interface

5️⃣ Who Does What? — Class Responsibilities

LoginScreen (interface)