Platform Tilt

Rule 2.5.6 of the Apple App Store Review Guidelines forbids the usage of third-party browser engines:

2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript

Notably, this means that Firefox can’t be shipped with Gecko on iOS. It also means that Firefox can’t be distributed in the App Store on other Apple platforms like macOS. The App Store policy should be updated to allow third-party browser engines for web browsers.

All modern web browsers employ a multi-process architecture where a single browser application is implemented as a collection of operating system processes with one main process that spawns child processes. This generally involves loading each site in a separate process, and moving certain sensitive functionality (e.g., GPU usage) into a dedicated process. This design allows the browser to be more resilient against crashes, more responsive under load, more secure against malicious exploits, and less susceptible to information leaks like Spectre. Most applications don’t need this level of granular isolation, but for browsers — which load interactive content from many different origins — it’s a table-stakes requirement.

On iOS, Safari uses a multi-process architecture. However, it does so with a proprietary mechanism that is not available to third-party applications unless they use Safari’s WebKit engine. To support third-party browser engines, iOS should provide a mechanism to create and efficiently communicate with isolated child processes.

Some basic requirements:

• The number of child processes and their duration are dictated by user browsing behavior and should not be fixed outside of reasonable device constraints.
• The child process should be configurable with tightly controlled privileges while permitting inter-process communication using messaging and shared memory.
• The parent process must be able to establish shared memory mappings with child processes and vice versa. Child processes must be able to communicate with each other in the same way.
• Access to shared memory regions should be configurable as read/write or read-only per region.
• For optimal security, child processes’ entitlements/privileges should be configured independently from the parent process and the parent process should be able to create child processes of different types using different executables.
• Child processes should be able to load libraries from the bundle that are shared with the parent process.
• To support isolating GPU access to a GPU process, child processes should be able to use Metal or OpenGL (when configured as such) to render into an IOSurface. Child processes should be able to share IOSurfaces across processes.

Firefox uses a shared codebase across different operating systems with platform-specific adapters for functionality like process management. Some quirks may be inevitable, but it’s important that the interface and behavior be broadly similar to other platforms like macOS and Android so as to avoid systematically breaking assumptions in overall browser architecture and platform-specific code. Something shaped like posix_spawn would be a reasonable starting point.

In order to ship a performant JavaScript/WebAssembly engine, a necessary component of a modern web browser, it must be possible for browser processes to create memory regions that are both writable and executable. However, applications on iOS are prevented from creating such memory regions because the system call used to configure memory region permissions (mmap(2)) does not allow it.

This is sound default behavior that improves security in general, but web browsers need this capability. As evidence, an exception is made for Safari’s WebKit rendering engine on iOS, allowing writable and executable memory regions to be created.

The same general security mitigation is employed on macOS, but on macOS applications like web browsers can opt-out by using entitlements. To allow these memory regions for non-WebKit browsers on iOS, iOS should allow an equivalent entitlement to the macOS Hardened Runtime entitlement com.apple.security.cs.allow-jit (which permits use of the mmap(2) system call using the MAP_JIT flag) and include its accompanying APIs pthread_jit_write_protect_np and sys_icache_invalidate. These APIs are already in iOS, but only Safari and other Apple applications are permitted to use them.

The iOS accessibility API documentation is incomplete, and many APIs that are needed for a web browser to support accessibility web standards are undocumented. Further, it’s difficult to infer how to use them based on WebKit’s open source implementation because there appears to be a closed-source system bundle which is tailored for and loaded into WebKit at runtime.

This lack of visibility makes it difficult to enumerate a full list of gaps. There are many closed-source methods loaded at runtime, and we don’t have visibility into their full signature or how they are used. Here are a couple examples that we know of:

1. While some trait integer constants are public, others needed for a web engine like “visited”, or “radio button” are not.
2. While some notification type integer constants are public, others needed for a web engine, like “value changed” are not. The closed-source bundle has a method loaded at runtime into the WebKit wrapper named accessibilityOverrideProcessNotification. It takes a string, such as AXValueChanged or AXSelectedTextChanged, internally maps it to a private integer constant representing the notification type, and forwards it to the platform via UIAccessibilityPostNotification.

Supporting accessibility web standards is table stakes functionality for a web browser. In order to do this, all of the accessibility APIs used by WebKit must be documented and stable, and WebKit should ideally consume them in the same manner as third-party browser engines.

In Safari on iOS, the home page includes a convenience feature where links that were recently received in the Message app are shown along with the contact that sent them. Third-party browsers cannot offer the same functionality because they don't have access to Messages data. iOS should expose an API to third-party browsers so they can implement their own features using Message links similar to Safari.

Browsing information like history, bookmarked sites, and cookies isn’t accessible to third-party browsers on iOS, and there’s no API to allow this data to be imported. While this is sensitive data, similar import functionality is possible on all major desktop platforms, and iOS is able to mediate access to other sensitive data with user consent (e.g., health and fitness data). Not being able to import data creates significant friction to change from Safari - a user should be allowed to bring their data with them to another browser.

Allowing a third-party browser to programmatically set itself as the default is an important platform feature. Without this, even after the user has installed the browser of their choice they must navigate operating system settings and make the choice there as well. This adds friction and creates inertia to continue using Safari, despite the user's preference.

A well-established design pattern is to allow the third-party browser to invoke a system prompt which permits the user to easily confirm or reject the request to set the current browser as the default. This is an intuitive user experience that mirrors similar permissions models used in operating systems, browsers, and web applications. Android and macOS offer such a capability (on Android by requesting to hold the browser role and on macOS using LSSetDefaultHandlerForURLScheme/LSSetDefaultRoleHandlerForContentType).

Unfortunately, iOS does not support anything like this for third-party browsers: browsers are forced to “deep link” into the iOS settings UI, at which point the user must understand the UI and make the change on their own. For users that try to find the setting themselves, when using the search feature in the iOS Settings app, no results are returned for “Default browser app” (the text identifying the default browser elsewhere in the iOS Settings app) nor "Default" (which matches several other default applications in the iOS Settings app) -- see screenshots. iOS should instead provide a method for third-party browsers to programmatically request they be set as the default.

Furthermore, a third-party browser cannot even detect if it currently is the default browser on iOS. This prevents them from understanding how their browser is used and limits their ability to optimize the browser based on user intent. This also makes it impossible to identify the conditions in which it would be appropriate to ask the user if they’d like to change their default since the browser should only prompt in cases where it’s not currently the default. iOS should provide a method for third-party browsers to programmatically detect if they are the default browser, as exists on all other major platforms.

Screenshots

Screenshots from iOS 17.2.1 which depict that searching Settings for “Default browser app” and “Default” do not show results for changing the default browser.

In order to support features such as password autofill, one-time codes, passkeys, and Apple Pay, non-WebKit browsers must be able to specify an associated domain based on the web-content origin when using their APIs. WebKit-based browsers override the browser application’s associated domain (e.g., mozilla.com for Firefox) to be able to perform password autofill for the domain the user is browsing.

Non-WebKit browsers must also have this capability. For example, when a user is entering a password on a text field on site example.com, the browser should be able to indicate the password field corresponds to origin example.com so that the password manager can be invoked with a scope of example.com.

The intent of this issue is to cover the functionality needed for non-WebKit browsers to support these features using OS support available to Safari. Origin-based associated domains underpins this support, but additional functionality may need to be made available to non-WebKit browsers as well. For example, supporting Apple Pay may require additional changes so that third-party browsers are not bound by associated merchant identifiers and can accept payments for any registered Apple Pay payee like Safari.

Browser extensions are a key part of the web ecosystem and most popular browsers support them. Browser extensions allow developers to add functionality to the browser providing increased utility, usability, and interoperability with applications installed on the system.

For distribution, popular browsers have established extension catalogs that are available on the open web and curated by the browser vendors. Because extensions have elevated privileges, developers submit them to be approved to ensure safety and compatibility. Browser vendors make their own decisions about the APIs available to extensions. Extensions for each browser are installed and managed within the browser resulting in a common user experience across platforms.

Safari supports extensions distributed on the iOS App Store. However, third party browsers are prevented from offering their own established extension functionality because it would violate section 2.5.2 of the App Store Review Guidelines. To allow third-party browsers to offer the same functionality and be competitive with respect to browser extensibility, the App Store software requirements should be relaxed to permit third-party browsers to use their own extension catalogs. Third-party browsers could then use the existing web-based distribution model (where users can browse and install extensions directly from the browser) allowing for browser extensions to be used on iOS, similarly to other mobile and desktop platforms.

Beta testing is a critical part of the web browser release cycle which, for popular browsers, results in new major versions shipping at a monthly cadence. Browser stability and quality is dependent on a large and active beta testing audience. Due to the dynamic nature and enormous size of the web platform, new web APIs are frequently added and adopted by web sites, and new features and fixes are continuously developed. As a result, many problems are discovered and fixed in the beta phase which enables the vast majority of users to have a smoother experience.

On other platforms, separate Beta and Nightly builds can be distributed using the typical platform affordances. On iOS, beta versions of applications are not permitted on the App Store and instead are distributed through a separate TestFlight system. This has a few issues:

TestFlight has a 10,000 user limit, which is a tiny fraction of the beta population for web browsers with large user bases. The limitation becomes a maintenance burden for browser developers: when reaching the limit, old users must be manually removed from the list. The user experience for prerelease testers is more complicated than on other platforms: users must download the separate TestFlight application, sign up for an access code, wait to receive it, and then paste it into the application. Distributing with a public link is not feasible because of the user limit restriction.

This may be solved by allowing browsers to distribute prerelease builds in the App Store, or by making changes to Test Flight (removing the user limit entirely and allowing unlimited distribution from a public link without manual management). In any case, prerelease testing should not create more friction than exists for Safari: new versions of the Safari web browser are included in beta versions of the iOS operating system and do not face the same restrictions.

iOS and macOS have context menu items which allow a user to search online for the selected text (Search Web or Search with <Search Engine>). There’s an additional search entry point in the macOS menubar under <Application Name> -> Services. Clicking on any of these performs the search in Safari regardless of the default browser.

All built-in applications and affordances that open external links should open them in the user’s default browser.

Browsing information like history, bookmarked sites, and cookies isn’t accessible to third-party browsers on Android. This data is kept within a web browser application’s data directory, which isn’t directly accessible to third-party browsers, and there’s no API or ContentProvider to enable it to be imported. While this is sensitive data, similar import functionality is possible on all major desktop platforms, and Android is able to mediate access to other sensitive data with user consent. Not being able to import data creates significant friction to change from Chrome - a user should be allowed to bring their data with them to another browser.

Features like Google Search, or Discover, in the pre-installed Google application ignore the user’s default browser choice: links to websites outside of the application are always opened in Chrome, regardless of the default browser. This is a widely used application, with additional entry points from built-in features such as the search bar on the home screen and app launcher. Each time it opens a link in Chrome, a user is driven away from their default browser.

All built-in applications and affordances that open external links should open them in the user’s default browser.

The web search experience is tightly integrated with a number of built-in features in Android (see https://github.com/mozilla/platform-tilt/issues/8), and the experience provided to Firefox is inferior compared to the version provided for Chrome. As seen in the screenshots below, identical search terms show less information and receive a lower quality design in Firefox on Android.

While strictly speaking this is an issue with the Google Search website, given the prominence and integration of search on Android this is a meaningful user experience gap that creates an incentive for users to not choose a third-party browser - especially those implemented with third-party browser engines, like Firefox. There are no technical limitations which would prevent this page from operating in Firefox: an equal experience should be offered.

Chrome	Firefox

Allowing a third-party browser to programmatically set itself as the default is an important platform feature. Without this, even after the user has installed the browser of their choice they must navigate operating system settings and make the choice there as well. This adds friction and creates inertia to continue using Edge, despite the user's preference.

A well-established design pattern is to allow the third-party browser to invoke a system prompt which permits the user to easily confirm or reject the request to set the current browser as the default. This is an intuitive user experience that mirrors similar permissions models used in operating systems, browsers, and web applications. Android and macOS offer such a capability (on Android by requesting to hold the browser role and on macOS using LSSetDefaultHandlerForURLScheme/LSSetDefaultRoleHandlerForContentType).

Unfortunately, Windows does not support anything like this for third-party browsers: browsers are forced to “deep link” into the Windows settings UI. On Windows 10 this requires several clicks and a double confirmation in the settings UI. On Windows 11 there is a “Set default” button. Neither is sufficient. Windows should instead provide a method for third-party browsers to programmatically request they be set as the default.

In general, the Windows 10 and 11 operating systems have persistent messaging that Microsoft Edge is the “recommended” browser for Windows, and offer affordances to change the default browser to Edge. In some cases the wording is misleading, asking a user to adopt “recommended browser settings”, which does not obviously suggest a default browser change. This messaging is a moving target, with examples added and removed from Windows over time, often on UI surfaces that appear automatically on update or otherwise, making it difficult to enumerate specific examples.

In all cases these Windows components are able to change the user’s default browser directly, and are not forced to use the ms-settings: protocol deep linking that browsers are required to use (see issue #10). Windows should consume the same affordances and APIs that are available to third-party browsers for setting-to-default.

There are at least three prominent Windows features that open URLs in Microsoft Edge and not in the current default browser. The user’s default browser choice should be respected when web pages are opened by built-in operating system features.

The first is Windows Search, also known as Start Menu Search, and formerly known as Cortana. The UI for this feature is represented by a taskbar search box or search button (depending on user settings), and a search suggestions / results UI that appears when activated and updates as the user types. The suggestions and results UI also appears if the user starts typing when the start menu is open, and by the WIN+S hotkey. All links from this UI, whether they initiate web searches or link directly to articles or results, open in Microsoft Edge regardless of the user’s default browser.

The second is the new Windows Copilot, currently only available on Windows 11, which appears as a docked window on the right side of the screen. If Copilot produces links in its responses, or offers other links within its rendering area, these links open in Microsoft Edge regardless of the user’s default browser.

The third are Windows “widgets” which are called “news and interests” on Windows 10, a UI surface area which can be activated by a taskbar button. These show information like news, weather, stocks, and sports scores. On Windows 11 new widgets can be added from 3rd parties. Regardless, all links to a web page from widgets will open in Microsoft Edge regardless of the user’s default browser.