Mobile: The view element

A view is the top-level element in a native mobile app, serving the same role that a page does in a web app. Every mobile screen your users interact with is a view, and everything else on the screen sits inside it.

If pages are canvases in a web app, views are the canvases of a mobile app.

A view is a full-screen container that holds all the elements that make up a screen in your app. Instead of loading separate URLs like a web app does, a mobile app moves between views within a single app shell.

This has a few important implications:

Typically, each view represents a distinct screen. A social app might have views for a home feed, a profile, a settings page, and a compose screen, each designed and configured independently.

Mobile views differ from web pages in that they can hold regular content (elements placed on the view) or fullscreen lists. Instead of building lists with elements, you can set the view’s type to vertical list or section list.

You can read more about this below.

Views serve the same purpose as pages, but with a few key differences. The main distinction is that you don’t choose between them: views are for mobile apps, and pages are for web apps. Beyond that, there are some functional differences worth being aware of:

Mobile views are managed through the pages dropdown at the top of the editor. From here, you can create new views, open existing ones, or delete views you no longer need.

Views come in four types, each suited to a different layout style. The view type determines how the view handles scrolling, content layout, and how users interact with the content inside.

The most common view type. In a scrollable view, users can scroll vertically to see all of its content, similar to a standard web page. This is the right choice for most views, especially those with forms, mixed content, or anything that might extend beyond the height of the screen.

Scrollable views are flexible and work well for the majority of screens in an app, from settings pages to detail views.

A non-scrollable view keeps its content fixed to the size of the device screen. Nothing scrolls, and everything the user sees is contained within the visible area.

This type is useful for:

Non-scrollable views work best when the content is intentionally limited to what fits on the screen at once.

A vertical list turns the view into a scrollable list, similar to a repeating group on web. The list repeats a set of elements for each item in the data source, creating a familiar mobile list interface.

Vertical list views are ideal for:

Because vertical lists lazy-load their items, they perform well even with large collections.

A section list works like a vertical list but groups items into sections based on a shared property. Each section has a header, and items are organized under the header they belong to.

Section list views work well for:

The section list handles the grouping and header rendering automatically, so you only need to configure the data source and choose the grouping property.

Several appearance settings control how the view integrates with the device and the app shell.

Toggles the app bar at the top of the view. The app bar holds a title and navigation controls.

Toggles the safe area on the view. When enabled, device-specific padding keeps content clear of hardware features like notches, home indicators, and rounded corners.

Disabling the safe area allows content to extend across the entire screen, which is useful for immersive views like maps or full-screen media.

Toggles the device’s status bar, which displays time, battery level, and network status.

Disabling it creates a more immersive view, though it also hides information users may expect to see.

Toggles the tab bar at the bottom of the view. This option is checked and locked when Include as tab item is enabled, since a view that acts as a tab item must display the tab bar.

Adds the current view to the tab bar as a tab item. The tab item defaults to the view’s name and a star icon, both of which can be customized.

Views can hold data through custom properties, similar to how a reusable element passes data between its definition and its instances. Custom properties let a view accept data when it’s opened, so its content can adapt to whatever the user is doing at the time.

For example, a Post detail view might have a Blog post property that receives the specific post the user tapped in a list. Once the property is set, elements inside the view can reference it in dynamic expressions.

A custom property can hold any type of value your app works with, including:

Each property can be marked as a list to hold multiple values of the same type, or set as optional if a value isn’t always required.

Properties are configured through the property editor for the view itself. Each property has:

Properties can also have a default value or be left empty until data is passed in.

There are two ways to give a property a value:

You can add a description to each property using the Description field. Descriptions don’t affect how the property behaves; they’re a convenience for you and your team, giving the property a bit of context so its purpose stays clear when someone opens the view later.

Descriptions are especially useful for properties whose names aren’t fully self-explanatory, or for views with several properties that serve different roles.

Once a property is defined, elements and workflows inside the view can reference it using Current view's [property name]. This works the same way as referencing a reusable element’s properties from within the element.

Navigating between views is different from navigating between pages on the web. Views are more tightly integrated with your app, and both the method and settings used to move between them affect how the navigation flow behaves.

There are two ways to navigate between views in Bubble:

Tab navigation is powered by the tab bar, a persistent navigation panel at the bottom of the screen. Each tab item references a single view, so tapping a tab takes the user directly to that view without needing a workflow.

The tab bar is a global component, similar to a reusable element on web. There’s only one tab bar in your app, but it can appear across multiple views, and changes made to it anywhere apply everywhere.

Tab items can be added to the tab bar in two ways:

A tab item can only reference one view, and a view can only be linked to one tab item.

You can customize each tab item’s label, icon, icon size, colors, and active/inactive states through its property editor. Conditions can also be used to hide a tab item based on criteria like the user’s login status.

Similar to Go to page in a web app, but no URL loads and no page refreshes. The new view opens either as a stack or as a modal.

The Go to view action supports two navigation styles:

In Spotify, tapping a playlist from the Home tab pushes a new view onto the Home tab’s navigation stack. Tapping the back arrow returns you to the Home view. If you switch to the Your Library tab and open the same playlist there, it opens within that tab’s stack instead, keeping each tab’s navigation history independent.

The Go to view action includes an option to reset the navigation stack. This clears the navigation history, so the user can’t return to the previous view. It’s useful for flows like completing a login, where returning to the login screen after signing in doesn’t make sense.

Resetting the stack removes previous views from memory, so any data stored on those views (like form content) is no longer accessible.

What’s the difference between a view and a page?

A page belongs to a web app and is accessed via a URL. A view belongs to a native mobile app and is reached through in-app navigation. Both serve as top-level containers for their respective platforms, but they behave differently.

Do views have URLs?

No. Views live inside the mobile app and aren’t accessible through a URL. Navigation between views happens through workflows or tab taps within the app itself.

How do I navigate between views?

There are two ways: tap an item in the tab bar, or use the Go to view workflow action. Go to view supports stack navigation, modal presentation, and resetting the navigation stack.

Can I pass data to a view when navigating to it?

Yes. Define custom properties on the view, then pass values into those properties when using Go to view. The view’s child elements can then reference the properties in dynamic expressions.

What’s the difference between stack navigation and a modal?

Stack navigation adds the new view on top of a stack, keeping the previous view active behind it. A modal presents the new view as a temporary sheet, usually for focused tasks. Both are triggered through the Go to view action.

Can I have more than one tab item link to the same view?

No. A tab item references exactly one view, and a view can only be linked to one tab item.

Can I hide a tab item based on a condition?

Yes. Add a condition to the tab item and use it to set This element is visible to no when the condition is true. This is useful for tab items that should only appear to certain users, such as admins or logged-in users.

Can I hide the status bar on a specific view?

Yes. Turn off Show status bar in the view’s properties. The status bar stays hidden while that view is active.

Can I hide the tab bar on a specific view?

Yes. Turn off Show tab bar in the view’s properties. Note that if Include as tab item is enabled, the tab bar is required and can’t be hidden on that view.

What happens if I reset the navigation stack?

The navigation history is cleared, and the user can’t return to previous views.

Can views be indexed by search engines?

No. Views live inside the mobile app and don’t have URLs, so they can’t be indexed. Content that needs to be discoverable through search should also be published as web pages.

Can I change a view’s type after building it?

Yes, but switching between view types can temporarily remove existing content from the view. Switching back restores it. Test carefully if the view already contains significant work.