A community group to incubate work on MiniApps and serve as a base for analysis and proposals of specific work items
w3c/miniappGroup's public email, repo and wiki activity over time
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Chairs, when logged in, may publish draft and final reports. Please see report requirements.
Yao Suibin from Tencent, who chairs the High-Performance Web Apps CG, pitched a “high-performance Web” vision, pointing out that the Web still has some fundamental weaknesses on mobile. Users tend to prefer native apps and cross platform frameworks, so if the Web wants to feel truly native, it needs some serious rework at the infrastructure layer to boost performance.
He suggested packaging Web apps as installable bundles, locking down dynamic JS execution, relying more on AOT compilation, and leaning on WebAssembly, WASI, and multithreading to improve performance and security across devices. The group also discussed using the WebAssembly component model and interface types to evolve both the UI and logic layers: on the UI side, moving away from heavy, traditional HTML elements toward template syntax and leaner components; on the logic side, compiling languages like AssemblyScript to WASM and opening the door for Rust, C++, Go, Python, and others to run on the Web, cutting JS memory and power overhead.
Yu Sen from Ant Group, a W3C TAG member and chair of the MiniApps WG, talked about how MiniApps can run across iOS, Android, HarmonyOS, in-car systems, and other “super apps,” giving developers a true “write once, run anywhere” experience. Under the hood, MiniApps are basically Web based DSLs plus tooling running on top of a custom runtime, which still needs to evolve in areas like rendering performance, multithreaded execution, and automated testing, as well as better use of GPU and NPU for AI scenarios.
On the AI interaction side, the discussion covered multimodal input, “generative UIs,” and new APIs for an “Agentic Web”: how to structure page and app data so agents can understand and operate MiniApps and Web apps, while still respecting permissions, security, and privacy boundaries.
Martin Alvarez Espinar from Huawei, who chairs both the MiniApps WG and CG, shared the status update: specs like MiniApp Lifecycle, Addressing, Manifest, Packaging, and Widgets are getting close to stable, but real world implementations and deployments are still quite limited, which is currently the biggest blocker. The group has been maintaining API and element “gap analysis” docs that compare what MiniApps can do in major super apps versus what the current Web platform supports out of the box.
Most MiniApp runtimes are built on top of WebViews, but these differ a lot in API surface, performance, and stability across platforms. That fragmentation is a key background factor for both standardization work and getting things to ship consistently in production.
How it plugs into the Web ecosystem
Participants stressed that MiniApps should not become some forked, “subset Web” that drifts away from the main Web platform. Instead, the idea is to use concepts like baselines and profiles to give concrete guidance for specific devices and scenarios, while still honoring the One Web principle. There was a strong push to work closely with TAG, OpenUI, Isolated Web Apps (IWA), the WebView CG, WebAI, and others to avoid reinventing the wheel around templating, packaging, sandboxing, and device APIs.
They also called out accessibility and semantics as must haves: custom markup and non DOM models shouldn’t break ARIA and related features. MiniApp runtimes are encouraged to reuse standard HTML elements and Web APIs wherever possible, and to validate behavior using shared test suites (like w3c/miniapp-tests) and data platforms such as caniwebview for baseline capability data.
MiniApps + IWA: good timing to team up
MiniApps and Isolated Web Apps (IWA) are very aligned in terms of isolated execution environments, app level packaging, and permission/security models. IWA’s work in WICG overlaps heavily with previous MiniApps standardization discussions, so there’s a good opportunity to move the Web forward together in this space.
The group suggested that the updated MiniApps WG charter should formally tighten collaboration with IWA and include a shared track for assessing where the Web is currently lacking in these areas, so that standards work can better support these new application models.
Deepening collaboration with the WebView CG
Since MiniApps on mobile mostly rely on system WebViews, their real world behavior is only as good as those WebViews. The WebView Community Group shared survey data showing big gaps in API coverage, performance, and interoperability, and emphasized how urgent it is to improve compatibility and stability.
Both sides agreed it makes sense for the MiniApps WG and WebView CG to jointly define a “WebView capability baseline” and a “gap analysis framework,” so there’s a measurable way to track and improve cross platform consistency. The plan is to explicitly include this collaboration in the next MiniApps WG charter.
Concrete next steps
The meeting landed on several follow up items:
Put together a Web capability gap list (led by the High-Performance Web Apps CG) to identify core issues hurting mobile performance, cross device adaptability, and consistent UX, and then work with TAG, IWA, and others on fixes.
Update the MiniApps WG charter with a clear collaboration model that spells out how the group works with IWA, the WebView CG, and others, to avoid duplicated efforts.
Focus more on runtime ecosystems, app level packaging, permissions, and security models, and turn existing best practices into more generally applicable standard proposals.
Looking into the Future
With mobile and multi device ecosystems expanding fast, MiniApps have attracted a significant number of users. The general view was that MiniApps shouldn’t try to evolve in isolation, but instead grow together with the broader Web community to build a cross platform, reliable, and secure foundation.
Over the next few months, the group plans to push these action items forward, kick off the process to update the MiniApps WG charter, and open that up for public review, hoping to get more browser vendors, framework authors, and super app platforms involved.
The WebEvolve Annual Event 2025, as part of the serial events of the “WebEvolve” open forum initiated by Beihang University (W3C Partner), will be held on 5-6 September in Hangzhou (China). This hybrid event will feature a session on high-performance, cross-platform web apps, which is particularly relevant for the MiniApps standardization, as most MiniApps are web-like apps that can be distributed across operating systems and run on embedded browsers.
We encourage participants from the W3C MiniApp Working Group and Community Group, web developers, super-app vendors, toolset developers, MiniApp publishers, and researchers in general to engage in discussions on the future of the MiniApp standardization.
During this event, we will foster discussions on interoperability, standardization gaps, and future directions for MiniApps within the W3C ecosystem.
Read more about the topics, agenda, and logistics on the official WebEvolve 2025 website.
The MiniApps Ecosystem Community Group provides a forum for global community to discuss, incubate and propose MiniApp related standard ideas with the goal to bring more interoperability and robustness to MiniApp ecosystem.
Background
MiniApp as a new form of mobile application, leveraging both Web
technologies (especially CSS and Javascript) as well as capabilities of native
applications, is gaining more and more popularities in Asian countries such as
China. To enhance the interoperability between different MiniApp platforms (AKA
the super application or host application), main stream MiniApp vendors has
been working together in W3C Chinese Web Interest Group
since May 2019 and published MiniApp Standardization
White Paper in September 2019 as the initial standardization
exploration for MiniApp technologies.
As more global companies get interested in joining the MiniApp related discussion, the MiniApp Ecosystem Community Group was proposed and approved during TPAC2019 so that global Web community can join the discussion.
Scope of Work
The MiniApp Ecosystem Community Group aims to discuss proposals for MiniApp features that would benefit the interoperability and robustness of MiniApp ecosystem, including:
Out of Scope
The group does not intend to discuss ideas related to MiniApp platform operation.
New projects or status changes are communicated to the group through the
public mailing list. Chairs and editors should publish status updates to the group
public mailing list to allow group participants to monitor progress without
having to directly watch every repo.
Coordination
It is anticipated that the group will collaborate with appropriate W3C
Working Groups and WHATWG work streams in order to transition spec proposals to
the Recommendation or Living Standard track. This group will probably get into
collaboration with the following groups:
Web Application Working Group
Web Performance Working Group
Service Workers Working Group
Cascading Style Sheets (CSS) Working Group
Devices and Sensors Working Group
Web Application Security Working Group
Immersive Web Working Group
Web Incubator Community Group (WICG)
Accessible Platform Architectures Working Group
Machine Learning Community Group
Internationalization Working Group
Privacy Interest Group(PING)
WHATWG
Community Group Process and Patent Policy
The group operates under the Community and Business
Group Process. Terms of in this charter that conflict with those
of the Community and Business Group Process are void.
As with other Community Groups, W3C seeks organizational licensing
commitments under the W3C Community Contributor License Agreement
(CLA) (Proposals in
this Community Group charter are applicable “Specification” in the
CLA). When people request to participate without representing their
organization’s legal interests, W3C will in general approve those requests for
this group with the following understanding: W3C will seek and expect an
organizational commitment under the CLA starting with the individual’s first
request to make a contribution to a group deliverable. The section on Contribution
Mechanics describes how W3C expects to monitor these
contribution requests.
Communication
The
group tends to have monthly teleconferences and conducts its work on the public
mailing list public-miniapps@w3.org as well as its GitHub Repository for
technical discussions. Other communication tools are allowed if considerable
number of the group participants decide to embrace them.
Participation and Contribution
Membership of the group is open to everybody but all participants will
have signed the W3C Community Contributor
License Agreement. Chairs and editors of feature proposals must
ensure that no contributions are adopted from anyone who is not a member of the
Community Group.
All Github repositories attached to the Community Group must contain a
copy of the CONTRIBUTING
and LICENSE
files.
Note: this CG will not use a contrib mailing list for contributions
since all contributions will be tracked via Github mechanisms (e.g. pull
requests).
Decision Policy
This group will seek to make decisions when there is consensus. consensus
decisions will be recorded through meeting minutes or its GitHub repo issue
list with assistance from the Chairs.
Any technical specification that is planned to be proposed to a W3C
working group should require:
About This Charter
This Charter can be amended by the Chairs with consultation of the
Community Group.
Charter History
The following table lists details of all
changes from the initial charter.
This is a community initiative. This group was originally proposed on 2019-09-18 by Charles ‘chaals’ (McCathie) Nevile. The following people supported its creation: Charles ‘chaals’ (McCathie) Nevile, Angel Li, Qing An, Michel Weksler, Chris Wilson. W3C’s hosting of this group does not imply endorsement of the activities.
w3c/miniapp
