the Chromium logo

The Chromium Projects

Layered Components: Design


Chrome for iOS cannot use the content layer as-is due to the restrictions that Apple places on third-party browsers on iOS. Given this fact, the goal of this project is to enable iOS’s usage of chrome- and component-level features that:

To that end, we will be performing refactorings to introduce layered components: components that consist of shared code that is content-free together with a driver based on the content layer and an alternative driver for iOS that uses an iOS-specific API.


Apple restricts third-party iOS apps to using UIWebView as the JavaScript/rendering engine and additionally to being single-process. This fact means that Chrome for iOS:

As a result, iOS usage of chrome- and component-level features currently requires a sea of ifdef’s, code modifications, and code additions. Upstreaming this surgery would introduce maintainability and readability challenges.

The fact that most Chromium developers have no visibility into iOS’s restrictions and requirements additionally causes a raised level of difficulty for developers looking to target feature work to iOS in addition to other platforms.

Layered Components

Our approach to the challenges outlined above is to gradually eliminate dependence on the content API in code that is used on iOS (see the below background for discussion of alternative approaches and how we converged on this approach). In determining how to structure this approach within the codebase, we took the position that DEPS restrictions are easiest for developers to understand and introduce the least amount of maintainability pain when they are put within a recognizable structure. We will introduce layered components. These components will live in one of a small number of known locations within the source tree (e.g., src/components). Each such component will consist of the following:

The technical details of our plan to realize this approach are detailed here, and a detailed description of the proposed structure within the Chromium codebase is detailed here.


Background: iOS and the Content API

We have examined several approaches to iOS’s usage of content:

  1. iOS uses all the parts of the content API that it needs/can support, providing alternative partial implementations of interfaces for which it cannot share the existing full-fledged implementation (e.g., WebContents).
  2. iOS uses only the parts of the content API for which it can share the implementations, refactoring the Chromium codebase to remove and disallow usage of problematic parts of the content API (e.g., WebContents) in shared code.
  3. iOS does not use the content API (the approach that we ultimately decided on).

The conclusion re: Approach 1 was that the fact that iOS would only be able to provide a partial implementation of the content API would make it more challenging for developers to develop against the API: they would have to always be aware of (a) whether the given piece of code that they were working on was shared on iOS, and (b) which subsets of the content API were OK to use in code shared on iOS. The conclusion re: approach 2 was similar to that re: approach 1, with the added concern that performing somewhat arbitrary-looking refactorings throughout the codebase would introduce maintainability and readability problems (initial CLs targeting this approach bore out these fears).


Stuart Morgan (stuartmorgan@) and Colin Blundell (blundell@) are the leads on this project. Darin Fisher (darin@) and John Abd-El-Malek (jam@) are providing guidance, direction and approval.