The element hierarchy

Every page or view in a Bubble app is made up of elements arranged in a hierarchical structure. This hierarchy shapes how elements are organized, how they inherit data, and how they respond to layout changes.

The element tree in a native mobile app organizes elements into distinct layers, based on how they interact with the view. Each layer serves a different purpose and appears in its own section of the tree.

The Overlays layer holds elements that appear on top of the view’s content, such as sheets (mobile) and popups (web). Elements in this layer float above the main layout and are typically shown and hidden through workflow actions.

The Navigation layer holds the app bar and tab bar. These are pseudo child elements that appear when enabled in the view’s properties. They handle the standard navigation patterns of the app and are edited from within the view. This layer is only visible when you’re editing a mobile app.

The Layers section holds the main content of the view: the elements users interact with as part of the normal flow. Groups, buttons, inputs, lists, and other elements all belong here.

Organizing elements into these layers makes it easier to understand a view at a glance. The main content is separate from the overlays and navigation, and each part can be edited without visually competing with the others.

A Bubble page or view is built from three types of components. Each plays a distinct role in how the app looks and behaves.

The page (on web) or view (on native mobile) is the top-level component. Every element you add exist inside it. The page/view sits at the very top of the hierarchy, and everything else on the screen is a descendant of it.

The page/view also holds properties that affect the whole screen, such as background color, layout mode, and its data type. In many ways, the page/view is a special kind of container: the one container every other element ultimately belongs to.

Containers group elements together and control how they behave as a unit. They act as boxes that hold other elements, forming the branches of the hierarchy.

Containers can:

Common container types include groups, repeating groups, popups, floating groups, sheets, and reusable elements. Each behaves differently, but all follow the same core principle: they contain other elements.

Article:Web containers\
​Article:Mobile containers

Elements are the actual content users see and interact with. These are the leaves of the hierarchy: the specific pieces that make up your app’s interface.

Elements include:

Elements can trigger workflows, display data, and respond to user input. They can also be styled, hidden, animated, or made conditional based on the state of the app.

Article:Web app elements\
​Article:Mobile app elements

The way these three components are organized and nested defines the structure of your page or view. Every element has a parent, and every container can have children. This creates a tree-like structure that flows from the page or view down to the individual elements users interact with.

Here’s a simplified example of a page hierarchy:

Each level of indentation represents a parent-child relationship. Group 1 and Group 2 are children of the page, and the elements to the right are child elements of them.

The hierarchy works in the same way for both web and mobile apps.

The hierarchy isn’t just an organizational tool. It has real, practical implications for how your app looks and behaves.

Container layout rules cascade to their children. A container with a column layout stacks its children vertically. A container with a row layout arranges them side by side. Changing a container’s layout affects every child inside it.

This is what makes the hierarchy essential for responsive design. By nesting containers with different layout modes, you can build complex layouts that adapt gracefully to different screen sizes.

Containers can hold data, and their children can reference that data directly. For example, if a group holds a User, any element inside it can reference Parent group's User's name without having to look the user up again.

This “data flows down” pattern is one of the most powerful features of the hierarchy. It lets you set data once at a high level and use it throughout everything nested inside.

Styling and visibility often follow the hierarchy. Hiding a container hides everything inside it. Applying an opacity change or a transform can affect a whole branch of the tree at once. This makes it easy to control large sections of the interface as single units.

Workflows can reference parent groups, sibling elements, and children, all through the hierarchy. Knowing how elements are nested helps you understand which references are available where.

Some elements can create pseudo child elements automatically as part of their configuration. These are elements that appear in the hierarchy without being added manually. They’re generated by the parent element based on how it’s set up.

Examples include:

Pseudo child elements behave like any other element in the hierarchy: they can be selected, styled, given workflows, and referenced in dynamic expressions. What sets them apart is that they can’t be created or deleted directly. They exist because of the parent’s configuration, and they disappear if that configuration changes.

This pattern lets Bubble expose complex native components in a way that fits naturally into the element hierarchy, without forcing you to build each part from scratch.

In many ways, the hierarchy is how your browser or mobile app “sees” the page or view before rendering it. The browser reads the tree from top to bottom, uses the container layout rules to determine positioning, and then paints each element on the screen.

Bubble handles most of this automatically, but understanding the hierarchy helps you anticipate how your design will render, how changes will cascade, and how to structure things for the best results.