Using alternative browser engines in Japan

In iOS 26.2 and later, browser engines other than WebKit can be used in two types of apps for users in Japan: Dedicated browser apps that provide a full web browser experience, and apps from browser engine stewards that provide in-app browsing experiences using an embedded browser engine.

Apple will provide authorized developers access to technologies within the system that enable critical functionality and help them 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

For browser apps

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 distributed solely on iOS in Japan (except for any other jurisdiction or Apple platform expressly permitted by Apple under the Developer Agreement - including any addenda - for which you have likewise obtained a corresponding entitlement profile);
Be a separate binary from any application that uses the system-provided web browser engine;
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
  - 80% of Test262 on an iOS device, iPadOS device, or Mac with Apple silicon; and
- 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 web page (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:

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. This includes adoption of:
- Pointer Authentication Codes (PAC);
- Memory Integrity Enforcement (MIE) for any (i) system-provided allocators in any content extension and (ii) custom- or system-provided allocators in any processes and extensions of your app, including in your network and graphics rendering extensions;
Follow secure design and 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:

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 any state (including cookies) between your app and any other app, even another app from the same developer, unless the user has explicitly given permission for the state to be synced, either by signing into both your app and the other app, or through another mechanism of providing explicit permission;
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 (i.e., wherever your app is distributed); 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

For in-app browsing

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 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 organization must be a browser engine steward. A browser engine steward is an entity with the primary responsibility for operating a distinct web browser engine.

Primary responsibility means you have operational control over, and are ultimately responsible for, coordinating a response where a security or privacy vulnerability is found in the web browser engine, and resolving it.
A distinct web browser engine is maintained by a different entity or organization than any other web browser engine, and has both architecture and support for Web APIs that are materially distinct from any other engine. The engine is not generally updated to reflect changes made to its forks, but instead pushes out changes to its forks.

App requirements

Your app must:

Be distributed solely on iOS in Japan (except for any other jurisdiction or Apple platform expressly permitted by Apple under the Developer Agreement - including any addenda - for which you have likewise obtained a corresponding entitlement profile);
Use the entitlement solely for in-app browsing;
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
  - 80% of Test262 on an iOS device, iPadOS device, or Mac with Apple silicon; and
- 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:

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:

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 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 (i.e., wherever your app is distributed); 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.

Resources

Security Mitigations and Memory Safety

You should also consider what current security mitigations are provided by iOS or iPadOS, such as Pointer Authentication Codes and Memory Integrity Enforcement, and what programming languages (or language and compiler features, and other tooling) 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. Additionally, compiler options and tools can be used, for example -fbounds-safety with C, which allows annotation of existing code to mitigate out-of-bounds memory access without always requiring rewriting of functionality in a language that’s memory safe by default.

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.