Process for considering issues related to Web Apps in Interop 2023

[mtom55]

Intro

When measured as a percentage of installed applications on mobile ecosystems vs native applications, Mobile Web Apps have failed to gain any meaningful traction despite the advantages of interoperability, business freedom and lack of app store fees.

Mobile Web Apps have a huge future potential for the web, and could provide enormous benefits to developers, companies and ultimately consumers in the form of a lower development costs, applications that work across all devices and ultimately far more companies being invested in the future of the web.

There are two key questions that need answering and then addressing:

1. "why aren't mobile web apps successful"
2. "why does a CEO/CTO of a company choose to produce a native app instead of a web app"

Vested Interest

It needs to be explicitly acknowledged that both Apple and Google, who are custodians of the two largest mobile app stores benefit greatly from the lack of uptake of mobile web apps. This needs to be a key consideration and actively addressed in any design decisions.

Approaches

There are only three methods by which these issues can be addressed:

1. The Current Approach
   Vendors unilaterally decide how core Web App functionality works on the devices they control. Note this is has been unsuccessful in generating any meaningful uptake of mobile web apps.

2. A Standards Based Approach
   A standards based approach with a deep technical investigation resulting in cohesive solution that addresses or at least identifies the major issues.

3. Regulatory Approach
   Where the Web Community presents these problems to regulators who then eventually compel vendors to take action or to implement specific solutions.

The standards based approach with guardrails to protect against self-preferential behaviour is by far the best option, however it will be necessary to follow the regulatory approach in parallel to hedge against inaction and self-interest and to provide external pressure to follow a standards approach.

Interop and the 2023 Process

At is core Interop was designed to address key developer pain points.

These pain points are collected from:

• MDN Developer Needs Assessment Survey
• Browser Compatibility Report
• Issues lodged on github
• State of CSS Report

If the issue is simply around a ranking issue based on developer feedback, then as long as the appropriate questions are asked I am certain we can campaign to developers so that they are ranked highly, but this is only worth doing if vendors will actually be willing to take on this feedback and address the issues.

There is also an inherent chicken and egg problem with Web Apps, in that while the core functionality and stability does not exist across the mobile ecosystems, they'll continue to have poor uptake which ensures that less developers will be using them.

With that in mind there are two key questions:

1. If we were able to demonstrate clear support that these are issues that need addressing, would the standards community be willing to address them?
   1a. If so, would that be in Interop 2023 or as a separate process?
   1b. If not, is there any other approach that can be taken except for the regulatory one?
2. How can we help design questions to help collect the necessary data?

Initial List of Web App Issues

The issues we have identified that relate to Web Apps are:

1. Bugs and issues related to building native like apps
   Primarily:
   Extend Scrolling to cover Body Scroll Issues  #84
   but a large number of other issues

2. Installability / Install Prompts / Install Banners
   On iOS users do not know that Web Apps exist (even including regulatory bodies who were investigating mobile ecosystems).

3. Push Notifications (should hopefully be fixed in 2023)

4. WebAPK Minting on Android for browsers other than Chrome

5. AppStore support

6. In-App Browsers

• Installation of Web Apps via In-App Browsers
• CCT Equivalent for third party browsers on iOS

8. Badging, Fullscreen, Deep Links, Screen Orientation Lock

Other Considerations:

• Developer control of banners/install prompts between website and native app AND/OR web app
• Install speed / delay (especially when minting an APK on Android) of Web App
• Open App Banners / Dialogs
• Complexity / Number of steps to install a Web App
• Opening or Focusing the icon of a Web App after install.

General:
For every decision that is made the question "Would this decision encourage/discourage the uptake of web apps in relation to native apps" should be asked, and where the answer is discouraged there should be a clear justification.

[foolip]

@mtom55 thanks for this issue and your comments in #78 (comment).

I'll take care to not comment on regulatory matters here and focus on web standards and testing.

Although the focus of Interop 2022 is mostly CSS, no part of the web platform is out of scope by design. See the Interop 2023 RFC sections on proposals and proposal selection for the process. (This is still under review and could change. Feedback welcome.)

One very consequential part of proposal selection is this:

A proposal is accepted if there is implementer support coming from at least 2 browser engines, and no opposition.

Since the web-platform-tests project cannot force any browser vendor to implement/ship things, any implementer can oppose a proposal and it will not be included. What we are left with are the things that we do have broad consensus on.

This is both a strength and a limitation. It's helpful because we can focus on the areas where we have shared (or similar enough) priorities and avoid contentious topics with no questions asked. But it also makes the process rather unsuited to making progress on contentious features.

All that being said, there may very well be areas relating to web apps where we could find consensus, given proposals outlining the specs, tests and evidence of web developer needs.

How each participating organization evaluated proposals is up to them, but I think the rough minimum bar will be:

• A high quality spec for the feature/behavior. I'm confident that https://w3c.github.io/manifest/ would meet that bar. If https://wicg.github.io/manifest-incubations/ is the spec in question, then I'd expect a discussion about the formal status of the spec, separate from the quality question.
• Tests that cover enough of the behavior such that browsers working to pass the tests will result in a solid experience for web developers using the feature. This is a judgement call, but we'd all like to avoid incentives for very shallow/partial implementation.
• Some evidence of importance to developers and/or users. We've looked at surveys like State of CSS in the past, but it could be other (existing or new) surveys or other kinds of evidence entirely. For the kind of proposal you're thinking about, I'd say MDN DNA 2020 gives clues, but other than "Access to Filesystem" isn't quite specific enough.

To also answer each question directly:

1. If we were able to demonstrate clear support that these are issues that need addressing, would the standards community be willing to address them?
   1a. If so, would that be in Interop 2023 or as a separate process?
   1b. If not, is there any other approach that can be taken except for the regulatory one?

Nobody can speak for the whole web standards community, but I am optimistic about the power of good evidence and arguments to shape the priorities. However, responsibility is spread around, and usually there's nobody in particular who is on the hook to address a problem.

The Interop 2022/2023 effort is framed mostly around tests. While we do have 3 investigation efforts that we expect will result in some spec changes, the spec work itself will be done in the relevant standards groups.

Let's make this concrete using Screen Orientation Lock as the example. If there's evidence of web developer demand for this feature (ideally compared to other features) then that could make a good Interop 2023 proposal, assuming it can be tested.

But given the consensus-based proposal selection, there would be no guarantee that the proposal would be accepted.

For proposals that you expect some browser vendor would oppose, Interop 2023 will probably not deliver what you hope, unfortunately.

I think that public research might help, which relates to your next question.

2. How can we help design questions to help collect the necessary data?

I think there's a gap in public web developer research at the moment. MDN's Web DNA was very broad and in principle would cover many of these topics, but last ran in 2020. State of CSS is only about CSS. State of JS 2021 did have a section on browser APIs, but no question probing into pain points for web apps.

A new survey that covers some of what State of CSS/JS don't might be a good idea.

https://github.com/web-platform-dx/developer-research is another place where some folks are looking into public research to improve our shared understanding.

[gsnedders]

As @foolip mentioned, the proposed charter discussion was happening elsewhere. With this now down, and the call for proposals open, I think we can close this in favour of more specific and detailed proposals, including potentially for those listed above.