Re: Web Install Meeting

Hi Ben,

I also had the same opinion in the last TPAC. One counterargument can be that it may not be feasible to show any UI element on mobile browsers, when they have limited UI area in the toolbar and often fully hides the toolbar. Adding anything to there can feel very intrusive to users. 

There was also some concern that if browsers start to show some extra UI for such explicit opt-in, then random websites may start to add the same manifest field, ending up the same UI being shown on every website.

Another concern was that websites may want to have an in-page button rather than browser provided experience, but not sure how much I buy that argument. I think that's potentially because there's simply no good existing browser provided experience.

Kagami


On 12 February 2026 18:32:04 CET, Ben Francis <ben@krellian.com> wrote:
>Hi Christian,
>
>Thank you very much for sharing the minutes of this meeting, and your
>summary of the outcomes. I look forward to hearing more as the discussion
>progresses.
>
>In the meantime I hope you don't mind if I share another perspective as a
>smaller implementer, who no longer works for one of the big browser
>vendors, but still has a commercial interest in the outcome of this
>discussion.
>
>Firstly, I'm very glad to see this topic get some serious cross-vendor
>discussion because I think getting this right could be really good for the
>web.
>
>However, I have reservations about the solutions currently being considered:
>
>   - The beforeinstallprompt event is a confusing and unpredictable API
>   which is also likely to lead to nagging popups, banners or install buttons
>   inside web apps
>   - The navigator.install() method is more explicit and predictable, but
>   similarly risks littering the web with popups, banners and install buttons
>   - The <install> element is a clever declarative solution, but again
>   risks littering the web with install buttons and is problematic for some
>   classes of applications.
>
>My main concern is that the web is already plagued with interruptions like
>ads, paywalls and cookie consent banners and moving the web app install UI
>inside the viewport under developer control would just add to the noise –
>further eroding the experience of web apps compared with native apps.
>
>In my view the web already has a declarative solution for a web page to
>point to a web app that can be installed, and that is a Web Application
>Manifest <https://www.w3.org/TR/appmanifest/> linked using a manifest link
>relation
><https://www.w3.org/TR/appmanifest/#using-a-link-element-to-link-to-a-manifest>
>in a link element. I think the best solution to this problem is through UI
>design, not API design.
>
>In my opinion, the user interface for installing web apps should be
>trusted, consistent, easy to discover, but keep out of the way when it
>isn’t needed. I think an "ambient badging" approach is the best way to
>achieve this, with browsers visibly but subtly surfacing trusted
>browser-native UI for installing web apps, which are treated as first class
>citizens on operating systems.
>
>I've quickly put together a blog post
><https://tola.me.uk/blog/2026/02/12/how-i-think-web-apps-should-be-installed/>
>which goes into more detail around pros and cons of the solutions currently
>being considered, proposes an alternative solution with an example
>implementation, but also acknowledges the hurdles that would have to be
>overcome for this to become a reality.
>
>Kind regards
>
>Ben
>
>
>
>On Wed, 11 Feb 2026 at 21:08, Christian Liebel <
>christian.liebel@thinktecture.com> wrote:
>
>> This is to inform the WebApps Working Group that the Web Application
>> Manifest editors met with representatives from Apple, Google, Microsoft,
>> and Mozilla to discuss APIs to allow developers to programmatically open
>> install dialogs for web sites. Web sites are already installable across all
>> major engines and operating systems. The goal of this effort is to enable
>> developers to advertise installation more prominently from within their
>> viewport.
>>
>> Here are the meeting minutes:
>> https://docs.google.com/document/d/16OTq60o7pJMlQeO0KwuxzlMljsBZrt30LzpswQiP5Ko/edit
>>
>> Summary:
>>
>>
>>    - The meeting participants decided to split the conversation between
>>    installing the "current app," and installing "some app."
>>    - The meeting participants favored the existing beforeinstallprompt event
>>    for solving the "current app" use case. There is a draft PR to re-introduce
>>    this event to the Manifest specification (
>>    https://github.com/w3c/manifest/pull/1206). Gecko and WebKit
>>    representatives have been asked to clarify their formal positions on
>>    supporting beforeinstallprompt (pending).
>>    - Regarding "some app" installation, vendors are asked to clarify
>>    which install use-cases (same-origin, eTLD+1, cross-origin) they would be
>>    willing to support (pending).
>>    - The Manifest editors will schedule a follow-up meeting with the
>>    participants in March.
>>
>>
>> --
>> Best regards,
>> Christian
>>
>
>
>-- 
>Ben Francis
>Founder
>Krellian Ltd. <https://krellian.com>