Skip to content
OpenPWA

Platform in Platforms

PWAs on HarmonyOS NEXT and ArkWeb

Published By Carey Gill · Editorial process

Huawei’s HarmonyOS NEXT application-planning page identifies ArkWeb as the kit that provides Web components for displaying web content in applications. OpenHarmony documentation supports the same embedded-site route, but these sources do not establish that Huawei Browser installs a manifest-based PWA or exposes a browser install prompt.

How it works

Section titled “How it works”

OpenHarmony documents ArkWeb’s Web component for loading pages, whether remote or local, and HTML text.

Embedding web content

Section titled “Embedding web content”

A remote page needs the ohos.permission.INTERNET permission. The host creates a WebviewController and passes it to Web; later navigation can use loadUrl().

The documented engine mapping is specific to ArkWeb. OpenHarmony 4.1 through 5.1 use Chromium M114, while OpenHarmony 6.0 uses M132 by default and can use M114. The same source says developers can use the ArkWeb engine version to obtain W3C standards support information from the relevant websites. An engine mapping says nothing about whether Huawei Browser installs a site or shows it standalone, or how Web Push behaves there.

Browser-level PWA support

Section titled “Browser-level PWA support”

Huawei Browser installation and standalone display are unknown, and so are service worker and W3C Web Push support. The cited Huawei material documents ArkWeb and Push Kit rather than those browser behaviours. Detect each web capability at runtime and keep a browser-page fallback. For an app-store package, treat ArkWeb as a native host for web content, not as proof that the same site is installable from Huawei Browser.

Examples

Section titled “Examples”

This minimal ArkTS component follows the documented remote-page pattern.

Loading the deployed site in ArkWeb

Section titled “Loading the deployed site in ArkWeb”

The host module also needs ohos.permission.INTERNET in module.json5.

import { webview } from '@kit.ArkWeb';


@Entry
@Component
struct WebApp {
  controller: webview.WebviewController = new webview.WebviewController();


  build() {
    Column() {
      Web({ src: 'https://example.com/', controller: this.controller })
    }
  }
}

Replace the example origin with the deployed HTTPS site. Navigation remains under the host application’s WebviewController.

Detecting service workers without assuming engine support

Section titled “Detecting service workers without assuming engine support”

Run capability checks inside the loaded page. This complete page reports whether the API exists and shows an online-only fallback when it does not.

<!doctype html>
<html lang="en">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Service worker capability</title>
  <p id="offline-status">Checking offline capability...</p>
  <script>
    const status = document.querySelector('#offline-status');


    if ('serviceWorker' in navigator) {
      status.textContent = 'The Service Worker API is available.';
    } else {
      status.textContent = 'This session remains online-only.';
    }
  </script>
</html>

The fallback does not infer why the API is absent and leaves the page in its online-only mode.

See also

Section titled “See also”

Specifications

SpecificationStatus
None.
  • Legend
  • Yes
  • Partial
  • Flag
  • No
  • Unknown
Browser / PlatformSupportVersionsConfidenceSourceNotes
HarmonyOS Browser · install to home screen#Unknown—lowsource1
HarmonyOS Browser · standalone display#Unknown—lowsource2
HarmonyOS Browser · service worker#Unknown—lowsource3
HarmonyOS Browser · Web Push#Unknown—lowsource4
Mi Browser · install to home screen#Unknown—lowsource5
Mi Browser · standalone display#Unknown—lowsource6
Mi Browser · service worker#Unknown—lowsource7
Mi Browser · Web Push#Unknown—lowsource8
ColorOS Browser · install to home screen#Unknown—lowsource9
ColorOS Browser · standalone display#Unknown—lowsource10
ColorOS Browser · service worker#Unknown—lowsource11
ColorOS Browser · Web Push#Unknown—lowsource12
UC Browser · install to home screen#Unknown—lowsource13
UC Browser · standalone display#Unknown—lowsource14
UC Browser · service worker#YesU4 2.0 (Chromium 57)lowsource15
UC Browser · Web Push#Unknown—lowsource16
QQ Browser · install to home screen#Unknown—lowsource17
QQ Browser · standalone display#Unknown—lowsource18
QQ Browser · service worker#Yes—lowsource19
QQ Browser · Web Push#Unknown—lowsource20
WeChat WebView (XWeb) · install to home screen#Unknown—lowsource21
WeChat WebView (XWeb) · standalone display#Unknown—lowsource22
WeChat WebView (XWeb) · service worker#Unknown—lowsource23
WeChat WebView (XWeb) · Web Push#Unknown—lowsource24
  1. No Huawei documentation found (checked 2026-10-03 and 2026-10-20) stating whether Huawei Browser offers a manifest-based install or `beforeinstallprompt`. Huawei's developer documentation covers ArkWeb, the HarmonyOS web component, and maps it to Chromium by system version (M114 for HarmonyOS 4.1 to 5.1, M132 by default for 6.0, M132 for 6.1, M144 by default for 7.0; ArkWeb overview, updated 2026-09-17). That documents the component, not the browser's install behaviour. Huawei's support pages for HarmonyOS 5.0 and later describe adding a page to the desktop from Huawei Browser as a shortcut, with no mention of a manifest.
  2. No Huawei documentation found (checked 2026-10-03 and 2026-10-20) on whether a home-screen web app launches in `standalone` display mode or as a browser tab.
  3. No Huawei documentation found (checked 2026-10-03 and 2026-10-20) stating that Huawei Browser exposes `navigator.serviceWorker` to third-party pages. ArkWeb's API reference gives apps that embed the component service worker hooks (`warmupServiceWorker`, `setServiceWorkerWebSchemeHandler`, API 12 and later; updated 2026-10-10), which is suggestive but is not a statement about the browser.
  4. No Huawei documentation found (checked 2026-10-03 and 2026-10-20) for W3C Web Push (`PushManager`, VAPID) in Huawei Browser. Huawei's documented push path for the web is its own Push Kit service, which is not the Push API.
  5. No current Xiaomi documentation found (checked 2026-10-03). Xiaomi's MIUI 9 Global Beta 8.6.14 changelog (2018-06) announced Progressive Web Apps support in Mi Browser with an Apps section listing installed PWAs, but the forum thread is no longer online and no HyperOS-era statement replaces it, so the row stays unknown.
  6. No Xiaomi documentation found (checked 2026-10-03) on the display mode of a home-screen web app in Mi Browser.
  7. No Xiaomi documentation found (checked 2026-10-03) stating service worker availability in Mi Browser. The Xiaomi HyperOS developer documentation covers quick apps and quick games, not the browser's web platform.
  8. No Xiaomi documentation found (checked 2026-10-03) for the Push API in Mi Browser.
  9. No OPPO documentation found (checked 2026-10-03). The OPPO open platform documents app-store, quick-app and push SDK integration, not the browser (`HeyTapBrowser`) web platform; its user-facing menu offers a web shortcut, which is not a manifest install.
  10. No OPPO documentation found (checked 2026-10-03) on display modes for home-screen web apps.
  11. No OPPO documentation found (checked 2026-10-03) stating service worker availability in the ColorOS browser.
  12. No OPPO documentation found (checked 2026-10-03) for the Push API in the ColorOS browser; OPPO's documented push channel is its native push SDK.
  13. Not documented as shipped (checked 2026-10-20). UC's U4 kernel blog (2018-10-26) mentions launching a home-screen web app with `display: fullscreen` only in its survey of Chromium 58–69 features, and says U4 3.0 (Chromium 69) was still in testing and staged rollout; it states U4 2.0 is Chromium 57 and U4 3.0 Chromium 69. In a 2018 InfoQ interview (https://www.infoq.cn/article/2018/05/practice-influence-pwa-uc-ali) UC's kernel team said add to home screen and Web Push notifications need separate adaptation in the browser shell or the system. Neither says UC Browser shipped an install path, so the row is unknown.
  14. UC documents only `display: fullscreen` for home-screen launches (U4 kernel blog, 2018-10-26); no UC statement on `standalone` or `minimal-ui` was found (checked 2026-10-03).
  15. UC's U4 kernel blog (2018-10-26) documents service worker features of the Chromium 58–69 range (navigation preload, `Clear-Site-Data` covering service workers) as part of the U4 2.0 → 3.0 upgrade; the U4 developer platform advertises full PWA support. The kernel team confirmed service worker support in the 2018 InfoQ interview.
  16. UC's 2017-10 U4 2.0 launch coverage claimed a standard web push service for mainland users, but the kernel team's 2018 InfoQ interview listed service worker push among features still needing shell adaptation, and the U4 kernel blog does not mention push. With no vendor document stating the behaviour (checked 2026-10-03), the row stays unknown.
  17. Tencent's X5/TBS documentation, which covers the kernel QQ Browser ships, has no page on manifest install or `beforeinstallprompt` (checked 2026-10-03 and 2026-10-20).
  18. No Tencent documentation found (checked 2026-10-03 and 2026-10-20) on display modes for home-screen web apps in QQ Browser.
  19. Tencent's X5/TBS product documentation had a Service Worker page with a registration walkthrough; it requires HTTPS and gives no kernel version, so `version_added` is left empty rather than invented. The page is undated, has archived copies from 2018-04-09 and 2023-06-02, and by 2026-10-20 redirects to the X5 home page, so this rests on an archived copy.
  20. No Tencent documentation found (checked 2026-10-03 and 2026-10-20) for the Push API in QQ Browser.
  21. WeChat's open-community documentation describes XWeb as a Chromium-based in-app kernel (Chromium 78, 86, 107, 111, 116, 122, 138 and a 142 developer build), detectable by `XWEB/` in the user agent, and notes some devices fall back to the system WebView. It documents no install surface for third-party web pages (checked 2026-10-03).
  22. No WeChat documentation found (checked 2026-10-03) on display modes; pages opened in WeChat render inside the WeChat title bar, and the documentation describes no standalone launch for web pages.
  23. WeChat's XWeb announcements (Chromium 111 rollout; Chromium 142 developer build, production on Chromium 138) say the kernel upgrades affect third-party web page rendering, but no WeChat document states whether `navigator.serviceWorker` is exposed to third-party pages (checked 2026-10-03).
  24. No WeChat documentation found (checked 2026-10-03) for the Push API or notification permission in XWeb; WeChat's documented messaging channels for web content are official-account template and subscription messages, not the Push API.

Source data: /compatibility/cn-vendor-browsers.json · Global usage: 0 % (StatCounter 2026-09, CC BY-SA 4.0)

Source: editorial · Last verified 2026-10-20 · Confidence: low (computed from sources)

Last verified

Sources

  • developer.huawei.comhttps://developer.huawei.com/consumer/cn/app/planning/
  • raw.githubusercontent.comhttps://raw.githubusercontent.com/openharmony/docs/master/en/application-dev/web/web-component-overview.md
  • raw.githubusercontent.comhttps://raw.githubusercontent.com/openharmony/docs/master/en/application-dev/web/web-page-loading-with-web-components.md
  • raw.githubusercontent.comhttps://raw.githubusercontent.com/openharmony/docs/master/en/application-dev/web/web-debugging-with-devtools.md
  • developer.huawei.comhttps://developer.huawei.com/consumer/cn/doc/harmonyos-guides/push-kit-guide

Report a problem · View source · Changelog

© 2026 OpenPWA · Text CC BY-SA 4.0 · Data CC BY 4.0Privacy · RSS · Changelog feed