Apple's current proposal requires browser vendors to distribute a separate app in the EU if they wish to use their own browser engine, rather than updating their existing app.

This would force existing EU users to switch to a new app, which is infeasible and creates a significant barrier to competition. This would lead to a poor user experience when transitioning to and from the alternative browser engine app. Some examples of areas of concern for Firefox are:

• EU users of WebKit Firefox being unable to effectively discover and migrate to Gecko Firefox. The current model introduces significant friction and risks for the user and for Mozilla.
• EU users of Gecko Firefox traveling outside the EU for > 30 days. In the current model they would lose access to their browser at that time with no recourse.
• Users outside of the EU using WebKit Firefox who permanently relocate to the EU. In the current model we understand that they would remain on an “orphaned” version of WebKit Firefox (unable to receive updates), and would need to navigate through many steps on their own to migrate to Gecko Firefox.

Moreover, from the browser developer point of view, it requires developing, maintaining, and deploying two completely separate apps. This creates complex data migration issues for the situations above, increases the likelihood of user churn and reduced acquisition, and prevents an iterative A/B rollout to provide the best experience for iOS users in the EU.

A solution which is much simpler and more likely to make BrowserEngineKit effective would be to allow browser vendors to ship a single worldwide binary & bundle that contains webviews for both engines, with the OS informing the app at start up whether it is BrowserEngineKit eligible or not (based on the same logic that currently causes an error at startup).