Platform Tilt  ## Metadata - Author: [[mozilla.github.io]] - Full Title: Platform Tilt - Category: #articles - Document Note: - tags: - #Apple - #AppStore - #iOS - #BrowserEngines - #WebKit - #Firefox - #OpenWeb Author: mozilla.github.io Source: Website Reference: https://mozilla.github.io/platform-tilt/ date created: 2025-08-23 00:00 # Title: Platform Tilt — Apple’s iOS Policies and Their Impact on Third‑Party Browsers ## Table of Contents: - 🔗 Introduction (#-introduction) - 🧩 Apple’s App Store Policy on Browser Engines (#-apples-app-store-policy-on-browser-engines) - 🧵 Support for Multi-Process Applications on iOS (#-support-for-multi-process-applications-on-ios) - ⚙️ JIT Support on iOS (#-jit-support-on-ios) - ♿ Accessibility APIs on iOS (#-accessibility-apis-on-ios) - 💬 Messages Integration on iOS (#-messages-integration-on-ios) - 🔄 Importing Browser Data on iOS (#-importing-browser-data-on-ios) - 🌐 Default Browser: Setting and Checking (#-setting-and-checking-default-browser-on-ios) - 🪪 Origin-Based Associated Domains (#-origin-based-associated-domains-for-third-party-browsers-on-ios) - 🧩 Browser Extension Support (#-browser-extension-support-on-ios) - 🧪 Beta Testing on iOS (#-beta-testing-on-ios) - 📚 References (#-references-include-a-list-of-sources-consulted-and-cited-in-the-article) - 📝 Summary (#-summary) - 📖 Main Content (#-main-content) - 🗒️ Notes (#-notes) - 📖 References (#-references) - 🗣️ Paraphrase (#-paraphrase) - 📰 Newsletter (#-newsletter) - ✅ Action Items (#-action-items) - 🧪 Hypotheses (#-hypotheses) - 📊 Methodology (#-methodology) - ❓ Questions (#-questions) - 🔮 Future Research (#-future-research) - 💡 Implications (#-implications) - 🧠 Learning Styles Assessment (#-learning-styles-assessment) - 📊 Accessibility Assessment (#-accessibility-assessment) - 🌍 DEIB Assessment (#-deib-diversity-equity-inclusion-and-belonging-assessment) - ✅ Logical validity (#-logical-validity) - 🔍 DARVO Analysis Prompt (#-darvo-analysis-prompt) - 🔍 SEO Evaluation (#-seo-evaluation) - 🎯 Conclusion (#-conclusion) ### References: Include a list of sources consulted and cited in the article. - Apple App Store Review Guidelines (notably section 2.5.6) - Apple Developer Documentation: App Entitlements, Associated Domains, WebKit - WebKit JSC and JIT background - iOS Accessibility APIs documentation - TestFlight and App Store Connect docs - Public statements from browser vendors about iOS limitations - Platform Tilt site: https://mozilla.github.io/platform-tilt/ ## 📝 Summary: Platform Tilt catalogs iOS platform rules and technical constraints that disadvantage non‑Safari browsers. Key frictions include: the prohibition on third‑party browser engines; lack of public support for multi‑process architectures; restrictions on JIT for JavaScript/WebAssembly; incomplete accessibility API documentation; missing APIs for Messages link surfacing; no standardized data import/export; limited default‑browser controls; origin‑tied associated domain capabilities gated to Safari use cases; constrained extension ecosystems; and beta distribution hurdles. The piece argues that enabling engine diversity and parity features would improve performance, security, accessibility, user choice, and competition. ## 📖 Main Content: The article systematically reviews how iOS policies and APIs shape browser capability: - It highlights Rule 2.5.6’s ban on third‑party engines, forcing all iOS browsers to use WebKit, which reduces competition and innovation. - It explains why multi‑process designs are foundational to modern browser security and stability and calls for a sanctioned way for third‑party browsers to create sandboxed child processes. - It shows performance penalties from disallowing W+X memory except for WebKit, urging equal JIT entitlements for non‑WebKit engines. - Accessibility parity requires fully documented and stable APIs used by WebKit so alternative engines can meet assistive needs. - Feature parity gaps include Messages link surfacing, import of bookmarks/history, reliable default-browser status checks/requests, associated domains per origin, extension catalogs, and smoother beta distribution beyond TestFlight caps and friction. Personal reflection: - Enabling engine choice on iOS would likely spur measurable improvements in JavaScript performance, WASM use cases, and site compatibility innovation. - Accessibility and data portability are user rights issues as much as developer platform concerns; standardized import/export would tangibly improve switching costs and market dynamics. - Equal access to extensions and origin‑based OS integrations would let ecosystems like Firefox, Chrome, and independent engines innovate responsibly while preserving platform safety via entitlements and reviews. ### 🗒️ Notes - App Store Rule 2.5.6 - Forbids third‑party browsing engines on iOS. - Consequence: all browsers are WebKit shells; limits engine competition. - Requested change: allow approved non‑WebKit engines under security entitlements. - Multi‑process architecture - Essential for isolation of tabs, renderer crashes, and site permissions. - iOS has proprietary mechanisms used by Safari; third parties lack equivalent APIs. - Proposal: public, reviewable child-process model with IPC, per‑site sandboxing. - JIT/WASM entitlements - WebKit on iOS has exceptions to W^X restrictions; others do not. - Impact: slower JS/WASM; limits advanced web apps and developer tools. - Proposal: audited entitlement for non‑WebKit engines to allocate JIT pages. - Accessibility APIs - Docs incomplete vs. what WebKit uses internally. - Result: inconsistent screen reader/assistive support for non‑Safari browsers. - Proposal: document and stabilize APIs; conformance tests for parity. - Messages integration - Safari surfaces iMessage link suggestions; others cannot access Messages metadata. - Proposal: privacy‑respecting API for link surfacing with user consent. - Data import/export - No OS‑level API to import history, bookmarks, passwords from other browsers. - Proposal: mediated, user‑consented migration framework. - Default browser controls - Setting/checking default is limited and awkward for third parties. - Proposal: programmatic request to become default + status query API. - Associated domains by origin - Required for features like password autofill and Apple Pay. - Proposal: enable non‑WebKit browsers to register per‑origin associations. - Extensions - Safari supports App Store extensions; third‑party catalogs restricted. - Proposal: relax rules to permit vetted extension ecosystems across browsers. - Beta testing - TestFlight limits scale/speed of release testing. - Proposal: allow prerelease channels via App Store with clear labeling. ## 📖 References: - Apple App Store Review Guidelines: “2.5.6” - Apple Developer: Associated Domains, PassKit/Apple Pay on the Web - Apple Developer: WebKit, WKWebView, entitlement docs for JIT - iOS Accessibility Programming Guide, UIAccessibility - TestFlight and App Store Connect documentation - Platform Tilt site: https://mozilla.github.io/platform-tilt/ ## 🗣️ Paraphrase: - On third‑party engines: Original idea: iOS forbids non‑WebKit engines, which restricts choice and innovation. Paraphrase: Because iOS requires all browsers to embed WebKit, competitors can’t ship Gecko, Blink, or independent engines. That uniform engine mandate depresses meaningful competition and slows advances users would otherwise see. - On JIT parity: Original idea: WebKit gets JIT; other engines don’t, harming performance. Paraphrase: Safari’s engine may use writable‑executable memory for JIT compilation, but alternatives are blocked. Extending the same, tightly‑scoped entitlement to other browsers would unlock comparable JavaScript and WebAssembly speed. ## 📰 Newsletter: This week in the WordPress and open‑web world: curious about why every iOS “browser” feels the same? A deep dive from Platform Tilt explains how App Store rules keep all iOS browsers tied to WebKit. That means no Gecko, no Blink—and fewer performance, accessibility, and extension innovations reaching your phone. For learners: if you’re getting into web dev, remember that “works in Safari iOS” is still a separate QA track. Keep an eye on JIT/ - Summary: Platform Tilt is a document that highlights various issues faced by different web browsers on iOS and Android platforms. For Apple, the issues include the prohibition of third-party browser engines, lack of support for third-party multi-process applications, restrictions on JIT support, incomplete accessibility APIs, limited integration with Messages, inability to import browser data, and difficulties in setting and checking default browsers. On the other hand, for Google, the issues revolve around the inability to import browser data and lower quality search result pages in third-party browser engines. Microsoft's issue focuses on the inability to set the default browser on Android. These issues hinder the competitiveness and functionality of third-party browsers compared to the default browsers on both platforms. - URL: https://mozilla.github.io/platform-tilt/ Vendor: **apple**| Issue | Status | | [App Store forbids third-party browser engines](https://github.com/mozilla/platform-tilt/issues/1)[#](https://mozilla.github.io/platform-tilt/#issue_1) [Rule 2.5.6](https://developer.apple.com/app-store/review/guidelines/#software-requirements) 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. | open | | [Support for third-party multi-process applications on iOS](https://github.com/mozilla/platform-tilt/issues/2)[#](https://mozilla.github.io/platform-tilt/#issue_2) 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. | open | | [JIT Support on iOS](https://github.com/mozilla/platform-tilt/issues/3)[#](https://mozilla.github.io/platform-tilt/#issue_3) 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](https://developer.apple.com/documentation/bundleresources/entitlements/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](https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon). These APIs are already in iOS, but only Safari and other Apple applications are permitted to use them. | open | | [Accessibility APIs on iOS](https://github.com/mozilla/platform-tilt/issues/4)[#](https://mozilla.github.io/platform-tilt/#issue_4) The iOS [accessibility API documentation](https://developer.apple.com/documentation/uikit/accessibility_for_uikit?language=objc) 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](https://developer.apple.com/documentation/uikit/uiaccessibilitytraits?language=objc), others needed for a web engine like “visited”, or “radio button” are not. 2. While some [notification type integer constants are public](https://developer.apple.com/documentation/uikit/accessibility_for_uikit/notification_names?language=objc), 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. | open | | [Messages integration on iOS](https://github.com/mozilla/platform-tilt/issues/5)[#](https://mozilla.github.io/platform-tilt/#issue_5) In Safari on iOS, the home page includes a convenience feature where [links that were recently received in the Message app are shown](https://support.apple.com/guide/iphone/find-links-shared-with-you-iph25424a81d/ios) 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. | open | | [Importing browser data on iOS](https://github.com/mozilla/platform-tilt/issues/6)[#](https://mozilla.github.io/platform-tilt/#issue_6) 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](https://support.apple.com/guide/iphone/share-your-health-data-iph5ede58c3d/ios)). 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. | open | | [Setting and checking default browser on iOS](https://github.com/mozilla/platform-tilt/issues/9)[#](https://mozilla.github.io/platform-tilt/#issue_9) 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](https://developer.android.com/reference/android/app/role/RoleManager#ROLE_BROWSER) and on macOS using [LSSetDefaultHandlerForURLScheme](https://developer.apple.com/documentation/coreservices/1447760-lssetdefaulthandlerforurlscheme)/[LSSetDefaultRoleHandlerForContentType](https://developer.apple.com/documentation/coreservices/1444955-lssetdefaultrolehandlerforconten)). 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](https://mozilla.github.io/platform-tilt/#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. | open | | [Origin-Based Associated Domains dependent features for third-party browser engines on iOS](https://github.com/mozilla/platform-tilt/issues/11)[#](https://mozilla.github.io/platform-tilt/#issue_11) In order to support features such as [password autofill](https://developer.apple.com/documentation/security/password_autofill), [one-time codes](https://developer.apple.com/documentation/security/one-time_codes), [passkeys](https://developer.apple.com/documentation/authenticationservices/public-private_key_authentication/supporting_passkeys), and [Apple Pay](https://developer.apple.com/documentation/passkit/apple_pay/), non-WebKit browsers must be able to specify an [associated domain](https://developer.apple.com/documentation/xcode/supporting-associated-domains) 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. | open | | [Browser extension support on iOS](https://github.com/mozilla/platform-tilt/issues/15)[#](https://mozilla.github.io/platform-tilt/#issue_15) 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](https://developer.apple.com/safari/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](https://developer.apple.com/app-store/review/guidelines/#software-requirements). 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. | open | | [Beta testing on iOS](https://github.com/mozilla/platform-tilt/issues/16)[#](https://mozilla.github.io/platform-tilt/#issue_16) 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](https://developer.apple.com/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. | open | Vendor: **google**| Issue | Status | | [Importing browser data on Android](https://github.com/mozilla/platform-tilt/issues/7)[#](https://mozilla.github.io/platform-tilt/#issue_7) 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](https://developer.android.com/training/data-storage/app-specific#internal), which isn’t directly accessible to third-party browsers, and there’s no API or [ContentProvider](https://developer.android.com/guide/topics/providers/content-provider-basics) 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. | open | | [Some Android features launch Chrome instead of the user’s default browser](https://github.com/mozilla/platform-tilt/issues/8)[#](https://mozilla.github.io/platform-tilt/#issue_8) Features like Google Search, or Discover, in the pre-installed [Google application](https://play.google.com/store/apps/details?id=com.google.android.googlequicksearchbox) 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. | open | | [Lower quality search result pages in third-party browser engines on Android](https://github.com/mozilla/platform-tilt/issues/12)[#](https://mozilla.github.io/platform-tilt/#issue_12) 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 | | --- | --- | | open | Vendor: **microsoft**| Issue | Status | | [Setting default browser on Windows](https://github.com/mozilla/platform-tilt/issues/10)[#](https://mozilla.github.io/platform-tilt/#issue_10) 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](https://developer.android.com/reference/android/app/role/RoleManager#ROLE_BROWSER) and on macOS using [LSSetDefaultHandlerForURLScheme](https://developer.apple.com/documentation/coreservices/1447760-lssetdefaulthandlerforurlscheme)/[LSSetDefaultRoleHandlerForContentType](https://developer.apple.com/documentation/coreservices/1444955-lssetdefaultrolehandlerforconten)). 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. | open | | [Default browser is set to Edge by several Windows flows](https://github.com/mozilla/platform-tilt/issues/13)[#](https://mozilla.github.io/platform-tilt/#issue_13) 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](https://github.com/mozilla/platform-tilt/issues/10)). Windows should consume the same affordances and APIs that are available to third-party browsers for setting-to-default. | open | | [Some Windows features launch Edge instead of the user’s default browser](https://github.com/mozilla/platform-tilt/issues/14)[#](https://mozilla.github.io/platform-tilt/#issue_14) 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. | open |, Platform Tilt, mozilla.github.io, 01hmtxb1cs6rcn42c42h9jmnas.