![Robert Ferens](https://web.dev/images/authors/rferens.jpg) Robert Ferens ![Demián Renzulli](https://web.dev/images/authors/demianrenzulli.jpg) Demián Renzulli [X](https://twitter.com/drenzulli) [GitHub](https://github.com/demianrenzulli)

<br />

This document provides essential information regarding the [Isolated Web App](https://chromeos.dev/en/web/isolated-web-apps) (IWA)
allowlist, including what it is, why it's necessary, the requirements for
developers, and the allowlisting process.

## What is the IWA allowlist?

The *IWA allowlist* is a mechanism that controls which Isolated Web Apps can be
installed and updated on user devices. From Chrome 143 on ChromeOS only
applications present on this allowlist will be installable or updatable through
the [Admin Panel](https://workspace.google.com/products/admin/). This
restriction applies to other operating systems starting from their initial
support for Isolated Web Apps.
To learn how to add an app to the allowlist read the rest of this document.

## How does the allowlist affect app installation and use?

From Chrome 143, you can expect the following behavior.

### Apps on the allowlist

Apps on the allowlist remain fully functional, allowing for installation,
updates, and continued use without impact from the feature launch.

### Existing app installations not on the allowlist

Existing app installations will remain installed and can continue to be
launched, but they will no longer receive updates after the allowlist rollout.
If an app is later added to the allowlist, both existing installations and new
instances will follow the behavior described in [Apps on the allowlist](https://developer.chrome.com/docs/iwa/allowlist.md.txt#apps-allowlist).

### Apps not installed and not on the allowlist

Apps not in the allowlist cannot be installed through the Admin Panel by policy,
but can be installed and tested in Developer Mode using
`chrome://web-app-internals`. This requires enabling the Chrome flag:
`chrome://flags#enable-isolated-web-app-dev-mode`.

### Additional considerations

- Adding an application to the allowlist automatically approves all its versions.
- The allowlist impacts the following underlying policies:
  - For managed user and managed guest sessions: [IsolatedWebAppInstallForceList](https://chromeenterprise.google/policies/#IsolatedWebAppInstallForceList)
  - For Kiosk: [DeviceLocalAccounts](https://chromeenterprise.google/policies/#DeviceLocalAccounts)

## Why is the allowlist needed?

The allowlist has three primary goals.

- **Ensure stability and quality**: IWA is currently restricted to a small audience of developers because it is in an early product state. Google is working with a select group of developers to ensure the product meets a high stability and quality bar before wider release. The allowlist will make sure that the IWA only comes from these developers.
- **Establish trusted contact channels:** Create a direct communication line with developers, which is crucial for processes like [key
  rotation](https://developer.chrome.com/docs/iwa/allowlist#key-rotation).
- **Adherence to terms and conditions**: Ensure developers comprehend and adhere to Google's acceptable usage terms for deploying Isolated Web App (IWA) applications through Chrome browser.

## Developer requirements

To add your Isolated Web App to the allowlist, you should establish contact with
Google through your known Google partner contact. Provide them with specific
information about the application, adhere to IWA security principles, and accept
the acceptable use policy.

If you don't have a Google partner contact, it's likely that you are not part of
the early IWA program.

## Criteria for allowlisting

The core prerequisite for requesting allowlisting of an app is that the
developer's use case must not be achievable through existing open web solutions,
including open web APIs and browser extensions. Additionally, the currently
launched Isolated Web App (IWA) APIs must adequately meet their requirements and
the developer must be part of the IWA early adopter program.

## Allowlisting process

The process for allowlisting an IWA involves the following steps:

| Step | Action | Details | Responsible |
|---|---|---|---|
| **1** | Request allowlisting | Developer/partner reaches out to their Google contact (Partner Engineering or other point of contact). | Developer / Partner |
| **2** | Response to requestor | Google contact provides instructions to the requestor, including a link to the request form and any additional instructions by email. | Google Contact |
| **3** | Provide data | Developer/partner registers IWA using the provided form. Google contact can be consulted for assistance. | Developer / Partner |
| **4** | Request processing and providing feedback | Google reviews the allowlisting request and responds within two business weeks, either approving or denying it, or contacting the developer with further questions. Upon approval, the bundle ID is added to the allowlist, and the partner is informed of the date the change becomes effective. | Google Contact |

## Key rotation

The allowlisting process is integral to establishing trusted contact channels
with partners, which simplifies *key rotation*. Key rotation is a mechanism that
allows private keys used to sign applications to be replaced in case of leak or
loss while maintaining a stable bundle ID. This trusted connection established
during the allowlisting phase is essential for enabling seamless key rotation.