Using alternative browser engines in the European Union

iOS 17.4 introduces new capabilities that let iOS apps use alternative browser engines — browser engines other than WebKit — for dedicated browser apps and apps providing in-app browsing experiences in the EU. To use an alternative browser engine in your app, you’ll need to request the Web Browser Engine Entitlement (for browser apps that want to use alternative browser engines) or the Embedded Browser Engine Entitlement (for apps that provide in-app browsing experiences that want to use alternative browser engines).

Apple will provide authorized developers access to technologies within the system that enable critical functionality and help developers offer high-performance modern browser engines. These technologies include just-in-time compilation, multiprocess support, and more.

However, as browser engines are constantly exposed to untrusted and potentially malicious content and have visibility of sensitive user data, they are one of the most common attack vectors for bad actors. To help keep users safe online, Apple will only authorize developers to implement alternative browser engines after meeting specific criteria and who commit to a number of ongoing privacy and security requirements, including timely security updates to address emerging threats and vulnerabilities.

Web Browser Engine Entitlement

With the Web Browser Engine Entitlement, you can use an alternative browser engine in your browser app. If you’re interested in using an alternative browser engine in your browser app, review the requirements below, then submit your request for the Web Browser Engine Entitlement. For technical guidance, review:

Requirements

To qualify for the entitlement, your app must:

Be available on iOS in the European Union only
Be a separate binary from any app that uses the system-provided web browser engine
Have the default web browser entitlement
Meet the following functional requirements to ensure your app is using a web browser engine that provides a baseline of web functionality:
- Pass a minimum percentage of tests available from industry standard test suites:
  - 90% of Web Platform Tests
  - and 80% of Test262
- Meet the above test suite requirement if Just in Time (JIT) compilation is unavailable (e.g., if Lockdown Mode is enabled by the user)
You and your app must meet the following security requirements:
- Commit to secure development processes, including monitoring your app’s software supply chain for vulnerabilities, and following best practices around secure software development (such as performing threat modeling on new features under development).
- Provide a URL to a published vulnerability disclosure policy that includes contact information for reporting of security vulnerabilities and issues to you by third parties (which may include Apple), what information to provide in a report, and when to expect status updates.
- Commit to mitigate vulnerabilities that are being exploited within your app or the alternative web browser engine it is using in a timely manner (e.g., 30 days for the simplest classes of vulnerabilities being actively exploited).
- Provide a URL to a publicly available webpage (or pages) that provides information on which reported vulnerabilities have been resolved in specific versions of the browser engine and associated app version if different
- If your alternative web browser engine uses a root certificate store that is not accessed via the iOS SDK, you must make the root certificate policy publicly accessible and the owner of that policy must participate as a browser in the Certification Authority / Browser Forum.
- Demonstrate support for modern Transport Layer Security protocols to protect data-in-transit communications when the browser engine is in use.

Program security requirements

You must do the following:

Use memory-safe programming languages, or features that improve memory safety within other languages, within the alternative web browser engine at a minimum for all code that processes web content;
Adopt the latest security mitigations (for example, Pointer Authentication Codes) that remove classes of vulnerabilities or make it much harder to develop an exploit chain;
Follow secure design, and secure coding, best practices;
Use process separation to limit the effects of exploitation and validate inter-process communication (IPC) within the alternative web browser engine;
Monitor for vulnerabilities in any third-party software dependencies and your app’s broader software supply chain, migrating to newer versions if a vulnerability impacts your app;
Not use frameworks or software libraries that are no longer receiving security updates in response to vulnerabilities; and
Prioritize resolving reported vulnerabilities with expedience, over new feature development. For example, where the alternative web browser engine bridges capabilities between the platform’s SDK and web content to enable Web APIs, upon request you must remove support for such a Web API if it is identified to present a vulnerability. Most vulnerabilities should be resolved in 30 days, but some may be more complex and may take longer.

Program privacy requirements

You must do the following:

Block cross-site cookies (i.e., third-party cookies) by default unless the user expressly opts to allow such cookies with informed consent, or as required for compatibility in the case of popup windows that interact with frames in their opening window;
Partition any storage or state observable by websites per top level website, or block such storage or state from cross-site usage and observability;
Not sync cookies and state between the browser and any other apps, even other apps of the developer;
Not share device identifiers with websites without informed consent and user activation;
Label network connections using the APIs provided to generate an App Privacy Report on iOS; and
Follow commonly adopted web standards on when to require informed user activation and/or user consent, as appropriate for Web APIs (e.g., clipboard or full screen access), including those that provide access to PII.

Embedded Browser Engine Entitlement

With the Embedded Browser Engine Entitlement, you can embed an alternative browser engine within your app to provide in-app browsing. In-app browsing is the display of content dynamically from the web that would be accessible and work within a web browser app. This doesn’t include content embedded within or only obtainable via the app.

The primary focus of your app while providing in-app browsing must be to provide web browsing functionality. When providing in-app browsing, the user interface must:

Take over the majority of the display, apart from relevant controls allowing the end user to control the browsing session;
Provide a button or link to the default browser of the system to allow the end user to open a dedicated browser app to view the content currently being displayed; and
Display the domain or URL whose content is being rendered by in-app browsing.

If you’re interested in using an alternative browser engine in your app to provide in-app browsing experiences, review the requirements below, then submit your request for the Embedded Browser Engine Entitlement. You will need to provide information on the engine that you are intending to embed, including how it meets the requirements and how it can be integrated into an app to provide the in-app browsing experience. For technical guidance, review the Examples and Resources section.

Requirements

To qualify for the entitlement, your app must:

Be available on iOS in the European Union only
Be a separate binary from any app that uses the system-provided web browser engine
Not have the default browser entitlement
Meet the following functional requirements to ensure your app is using a web browser engine that provides a baseline of web functionality:
- Pass a minimum percentage of tests available from industry standard test suites:
  - 90% of Web Platform Tests
  - and 80% of Test262
- Meet the above test suite requirement if Just in Time (JIT) compilation is unavailable (e.g., if Lockdown Mode is enabled by the user)
Meet the following security requirements:
- Commit to secure development processes, including monitoring your Application’s software supply chain for vulnerabilities, and following best practices around secure software development (such as performing threat modeling on new features under development).
- Provide a URL to a published vulnerability disclosure policy that includes contact information for reporting of security vulnerabilities and issues to you by third parties (which may include Apple), what information to provide in a report, and when to expect status updates.
- Commit to mitigate vulnerabilities that are being exploited within your app or the alternative web browser engine in a timely manner (e.g., 30 days for the simplest classes of vulnerabilities being actively exploited).
- Provide a URL to a publicly available webpage (or pages) that provides information on which reported vulnerabilities have been resolved in specific versions of the browser engine and associated app version if different.
- If the alternative web browser engine you choose uses a root certificate store that is not accessed via the iOS SDK, you must make the root certificate policy publicly accessible and the owner of that policy must participate as a Certificate Consumer in the Certification Authority / Browser Forum.
- Demonstrate support for modern Transport Layer Security protocols to protect data-in-transit communications when the browser engine is in use.

Program security requirements

You must do the following:

Use memory-safe programming languages, or features that improve memory safety within other languages, within the Alternative Web Browser Engine at a minimum for all code that processes web content;
Adopt the latest security mitigations that remove classes of vulnerabilities or make it much harder to develop an exploit chain;
Follow secure design, and secure coding, best practices;
Monitor for vulnerabilities in any third-party software dependencies and your app’s broader software supply chain, migrating to newer versions if a vulnerability impacts your app;
Not use frameworks or software libraries that are no longer receiving security updates in response to vulnerabilities; and
Prioritize resolving reported vulnerabilities with expedience, over new feature development. For example, where the alternative browser engine bridges capabilities between the platform’s SDK and web content to enable Web APIs, upon request you must remove support for such a Web API if it is identified to present a vulnerability. Most vulnerabilities should be resolved in 30 days, but some may be more complex and may take longer.

Program privacy requirements

You must do the following:

Block cross-site cookies (i.e., third-party cookies) by default unless the user expressly opts to allow such cookies with informed consent, or as required for compatibility in the case of popup windows that interact with frames in their opening window;
Partition any storage or state observable by websites per top level website, or block such storage or state from cross-site usage and observability;
Not sync cookies and state between the browser and any other apps, even other apps of the developer;
Not share device identifiers with websites without informed consent and user activation;
Label network connections using the APIs provided to generate an App Privacy Report on iOS; and
Follow commonly adopted web standards on when to require informed user activation and/or user consent, as appropriate for Web APIs (e.g., clipboard or full screen access), including those that provide access to PII.

Additional requirements

You must submit with each binary submission the name and version of the alternative web browser engine embedded in your app.
Upon a new version of the alternative web browser engine embedded in your app being made available, you must submit an update to your app with that new version within fifteen (15) calendar days.

Examples and resources

This section contains additional resources and examples to help you meet the requirements that allow you to use an alternative browser engine.

Secure SDLC (Software Development Lifecycle)

Many of the requirements that you need to meet rely on developing a security and privacy-first approach to introducing new features into your app. When you begin development on a new feature, you should first develop a threat model as well as a plan for how you will gain assurance that your architecture and the released version of your app mitigates the risks you’ve identified. There are a number of techniques to gaining assurance — for example, code auditing, fuzz testing, and writing tests to verify the security properties you intend to enforce. You should consider all web content to be untrusted and potentially malicious.

You should also consider what current security mitigations are provided by iOS, such as Pointer Authentication Code, and what programming languages (or language features) are available to mitigate each threat you identify. For example, Swift is a memory-safe language by default, and can help you avoid a number of common sources of vulnerabilities as well as other memory-related software bugs. However, memory unsafe languages such as C++ do provide features that provide memory safety benefits - such as std::span.

Resources

Vulnerability Management

You should assume that undiscovered vulnerabilities will always be present within a browser engine or that any new features could introduce unintended risks. Therefore, it is vital that you have the processes in place to allow you to respond when a vulnerability is discovered either internally through testing and security and privacy assurance efforts, within your software supply chain, or disclosed to you by another party.

Where you provide a pathway for a third party (for example, a security researcher) to report a vulnerability to you, you should consider what information you will need from them to enable you to quickly determine the validity and cause of the issue. You should also ensure that you have processes in place to prioritize a fix for the vulnerability and then release an update that might be out of step with your normal schedule.

It’s also important that users can quickly determine which public vulnerabilities that have an associated CVE-ID are resolved in which version of your app (or alternative browser engine).

Resources

Network Security

By using the iOS SDK, specifically the Network framework and/or SecTrust APIs, you reduce your need to take responsibility for evaluating the trust of web certificates and maintaining or using a corresponding root trust store and program for the alternative browser engine you use. If you do operate a program - it should provide information on how a root certificate authority (CA) can apply to become part of the program, and also how incidents (for example, the exposure of a root certificate authority’s private key material) can be reported such that you can take action.

Protocols used on the web are constantly evolving to respond to emerging threats and better protect user privacy and security. The current modern TLS versions that should be compatible with your alternative browser engine that have not been deprecated are TLS 1.2 and 1.3. However, these may change over time. You can support deprecated protocols in your alternative browser engine, but you should inform users when they browse to a site that only supports these.