Tree Structures in iOS, Android, Web, and Flutter: Views, Layers, and Rendering

This article is the second part of a two‑part series that compares the tree‑related technologies of Web, Android, iOS, and Flutter. It aims to help front‑end developers understand the similarities and differences among platforms.

iOS Views

In iOS a view is a rectangular block displayed on the screen (image, text, video, etc.) that can intercept touch gestures. Views are nested in a hierarchy; a parent view manages the positions of its child views.

All views inherit from the UIView base class, which handles touch events, Core Graphics drawing, affine transforms (rotation, scaling), and simple animations.

iOS Coordinate System

Origin is at the top‑left corner (0,0).

CGPoint(x, y) creates a point.

CGSize(width, height) represents size.

CGRect combines a point and a size.

origin – the top‑left point of a view.

bounds – the view’s own rectangle (x=0, y=0, width, height).

frame – the rectangle of the view in its superview.

center – the center point of the view in its superview.

UIView and Event Handling

UIView receives touch events through UIResponder and delegates visual rendering to CALayer . The responder chain propagates events from the UI down to the appropriate view.

CALayer

CALayer is responsible for the actual drawing of content. The relationship between UIView and CALayer is:

UIView provides content and handles touch events.

CALayer handles all visual rendering.

CALayer also maintains a tree structure (layer tree) with capabilities such as shadows, rounded corners, borders, 3D transforms, non‑rectangular clipping, masks, and multi‑stage animations.

Three kinds of trees exist within Core Animation: the presentation tree, the model tree, and the render tree.

Presentation vs. Model Tree

The presentation tree is created when a layer is first committed and stores the on‑screen values used for implicit animations. The model tree holds the intended values set by the developer. Most of the time developers interact only with the model tree.

Render Process and Render Tree

The rendering service runs in a separate process and follows four stages: layout, display, preparation, and commit. During commit, Core Animation packages layers and animation properties and sends them via IPC to the render service, which deserializes them into a render tree and draws each frame.

Flutter Tree Structure

Flutter uses three primary trees: Widget tree, Element tree, and RenderObject tree, plus a Layer tree for actual drawing. Widgets describe configuration, Elements act as a diffing layer (similar to Virtual DOM), and RenderObjects perform layout and paint.

The build process starts from the root element, creates corresponding widgets, elements, and render objects, and repeats until no more child widgets exist.

View updates in Flutter consist of build, layout, and paint phases, all driven by a dirty‑list mechanism managed by a singleton Owner that processes updates on each vsync.

Summary

All front‑end view systems share a common pipeline: parse view description → layout → render. They also employ a logical tree (e.g., Virtual DOM, Widget‑Element tree) to improve performance. iOS integrates animation configuration into the view tree, while Android typically animates by mutating the view hierarchy. Flutter extends the Virtual DOM concept with its own widget‑element‑render object architecture, enabling high‑performance rendering.

References are provided for iOS coordinate system, UIResponder, UIView rendering, Core Animation techniques, and Flutter’s rendering model.