WebView support on mobile devices and integration with Playwright "page" like class/fixture

[froibu]

Problem or motivation

Hi team,

First of all, great work on mobilewright — it’s very exciting to see initiatives bringing a modern, Playwright-like experience into the mobile automation space.
Secondly, please excuse me if this is not the right space to address my concerns / seek for help.

I’m currently at a decision point in my organization and would really appreciate your guidance.
And Mobilewright project came just in time and I hope it will be just the saviour I need.

Context (our current situation)

We are quite a large QA organization with multiple teams.

As of today we handle:

• Desktop automation → Selenium
• Mobile automation → Appium
  Because both rely on WebDriver, we have:
• Shared locator strategies
• Reusable Page Objects / business logic

However:
We are actively exploring Playwright as a replacement for Selenium.
We already see strong benefits (speed, reliability, modern API).
We are also moving towards AI-driven automation, where Playwright seems more aligned.

The challenge
We are trying to unify automation across:

1. Desktop Web
2. Android WebView
3. iOS WebView
4. Native Mobile Screens

What we observed:
Playwright works great for:

• Desktop
• Mobile web
• Android WebView (via experimental _android support)

But:

• No direct support for iOS WebView (e.g. WKWebView)
• No native mobile automation

This leads to a fragmented architecture:

• Playwright → Desktop + Android WebView
• Appium     → iOS WebView + Native

Which introduces:

• Duplication of locators
• Different interaction models
• Increased maintenance cost

As of this exact moment, in our organisation, we've built a strong automation PoC library around Playwright for Desktop Browser automation + Android WebView using the experimental "android" support from Playwright and Appium for native screens.
This basically means that we can reuse the same Page Objects defined for Desktop Browser automation also for WebView rendered screens on Android (where the same POM is rendered via WebView) as we can extract the "page" from the mobile WebView and pass it along to any POM or playwright action relying on "page" / fixture. For the native screens (Android + iOS) we're still relying on Appium.

But as you can see, we're fully missing from the scope of our automation the iOS WebView rendered screens as currently Playwright does not provide a way to extract the "page" on iOS devices and play around with it.
This would eventually force use to rely fully on Appium for iOS automation (native + WebView screens) and would also introduce overhead with locators, shadow-roots etc. Everything basically that playwright excels. 

Therefore I would have a couple of questions for you guys:

1. WebView support (critical for us)
   What is the current real support level for WebView (especially iOS WKWebView) in mobilewright?
   Is there a way that we can reuse the existing playwright POMs + actions that we've defined for Desktop Browser automation using mobilewright?
   Basically, I suppose it resumes to extracting the "page" object/fixture and play around with it as your would normally do it under Playwright.

2. Shadow DOM
   How does Mobilewright handle WebView content using Shadow DOM?
   Especially, does it support deep traversal?

3. Hybrid apps (native + WebView)
   What is your recommended architecture for hybrid apps?
   Native screens + WebView screens mixed

Would you recommend:

1. One unified Mobilewright layer?
2. Or combining Mobilewright with Playwright/Appium?

The framework we choose will be adopted organization-wide, so long-term maintainability and reusability are key concerns.
Any guidance, clarifications, or even high-level direction would be extremely valuable.
Thanks a lot 🙏

Proposed solution

Possibility to extract "page" class/fixture and reuse existing Playwright POMs and actions relying exclusively on "page".

Target platform

Both

Alternatives considered

No response

Additional context

No response

[gmegidish]

Hey @froibu. Thank you for this detailed question, I read it entirely.

1. Mobilewright WILL support WKWebView. I dont have a date at the moment. But the goal is to attend to everything a developer needs to automate or test mobile apps. This is part of it. It's on the roadmap, but I cannot give you the date right now. How urgent is this? (what's your alternative?)
2. You have a DOM within a DOM? with attachShadow()? I think it should work fine as long as there's access from within WKWebView to it. But I will have to check it technically when we get to implement it to give you the right answer.
3. If you could tell me a bit what's in your webview, that'll help. For example, if you just need to click a button inside a webview to continue your testing of native app, maybe there's a workaround right now with a deep-link or an internal webserver or file on disk. If half of the UI is in html, that's a different thing. In general, the best approach would be that mobilewright exposes playwright locators from a specific WKWebView down (you can have multiple views in a single screen, each has a DOM). Exposing "page" from a WKWebView would definitely be the right thing to do.

I hope I touched on some of the questions. Please feel free to ask more or provide more details.

[froibu]

Hi @gmegidish

Thanks for taking your time and replying to my above message.

1. For WKWebView - solid news. Can't wait for this in mobilewright.

As of now, as I was mentioning above, as we plan to fully switch to Playwright, our only option is:

• For Desktop Browser automation + Android WebView Screens we can use Playwright. For WebView screens under Android devices, Playwright exposes an experimental _android module. This helps us to reuse the same PageObjectModels we're using for Desktop Browser Automation also in the Android WebViewScreens without the need of duplicating logic/locators. You have the possibility to extract the "page" class/fixture from the android WebView and pass it to your existing POMs just fine.
• For iOS mobile devices automation (WebView Screens + native screens) + Android native Screens ONLY - we were still looking into Appium as we had no alternative. Because Playwright can't control native screens at all (iOS + Android) and on top of that, Playwright does not export a package where you can extract the "page" class/fixture the same way you're doing for Android and reuse your existing logic for WebView Screens under iOS. And this is the big pain, here. I was looking for a solution where I totally get rid of Appium.
  And now, mobilewright seems to come just in the right time.

What I can't understand as of now is if mobilewright gives the possibility to extract a "page" like object/fixture and at least for WebView rendered screens on mobile devices (both iOS + Android) you're able to reuse your existing POMs which you're using also for Desktop Browser Automation?

e.g.
Saying I have this sample DashboardPage.ts
Let's also assume that the Dashboard Page is displayed using WebView within the mobile apps (iOS + Android). NOT NATIVE.

import { Page, Locator } from '@playwright/test';

export class DashboardPage {
  readonly page: Page;
  readonly header: Locator;
  readonly userGreeting: Locator;
  readonly logoutButton: Locator;
  readonly mainContent: Locator;
  readonly sidebarMenu: Locator;
  readonly accountBalanceWidget: Locator;

  constructor(page: Page) {
    this.page = page;
    this.header = page.locator('header');
    this.userGreeting = page.getByText(/Welcome/);
    this.logoutButton = page.getByRole('button', { name: 'Logout' });
    this.mainContent = page.locator('main');
    this.sidebarMenu = page.locator('nav[aria-label="Main menu"]');
    this.accountBalanceWidget = page.locator('[data-testid="account-balance"]');
  }

  async isLoaded(): Promise<boolean> {
    return this.userGreeting.isVisible();
  }

  async navigateToMenu(menuItem: string): Promise<void> {
    await this.sidebarMenu.getByRole('link', { name: menuItem }).click();
    await this.page.waitForLoadState('networkidle');
  }

  async viewAccountBalance(): Promise<string> {
    const balance = await this.accountBalanceWidget.textContent();
    return balance?.trim() || '';
  }

  async logout(): Promise<void> {
    await this.logoutButton.click();
    await this.page.waitForURL('**/login');
  }
}

I can use this Dashboard.ts POM in both Desktop Browser automation and Android device automation as of now using Playwright, as I can extract the "page" class/fixture and control the actions from the DashboardPage POM.
But I can't reuse this POM when doing iOS automation as I can't extract the "page" as Playhwright does not support iOS. This forces me to reimplement locators and logic for the same DashboardPage but using Appium.

Basically, now with mobilewright in picture what I can resume it to is:

• I can still use Playwright for Desktop Browser automation
• I can ditch Appium and switch to mobilewright
• Open question/doubt: Let's say I ditch appium and switch to mobilewright. But which is the gain when it comes to hybrid apps (which are built around both native and WebView screens)? If I still need to maintain WebView pages for mobile devices separate and can't reuse what I'm already using for Desktop Browser automation.
  For native screens it's clear. That's straightforward! I'm almost sold to mobilewright in this case :)!

Continue below with answers to questions:

2. Basically what we have is an encapsulated DOM tree attached to an element separate from the main document
   The shadow DOM is attached via #shadow-root (open) so that we can interact with durint test automation.

3. I think I touched this under 1. above. Basically what's under my WebView is pretty much the same thing as it its when accessing the same page via Desktop Browser. Same locators, actions. Same Desktop Browser Page, but rendered via WebView.

I hope I made this more clear and it's not overhealming. I wanted to be as concise and straightforward as possible.
I appreciate your time and effort.