Views and navigation
Last updated
Last updated
Views and navigation are the foundation of native mobile app design. Views contain the information, while navigation is all about getting users to the views they want to go to - with as little friction as possible.
Views: What views are
Navigation: Different ways of displaying and navigating between views
Appearance: Tweaking how views look
View types: covering the different types of views
Note on branches: We recommend avoiding adding a mobile app directly to the Main branch unless you plan to work in a sub-branch created after the mobile app has been added to Main.
Adding a mobile app to both Main and an existing branch may lead to conflicts. As long as you create a branch after adding the mobile app to Main or add the mobile app in a branch and then merge it with Main, the setup should work as expected.
Mobile apps use views instead of pages. While views and pages both serve as the “base layer” where you design and add content, they differ in functionality within the app. In a mobile app, you don’t link between separate pages with unique URLs; instead, you navigate between views based on the chosen navigation paradigm (more on this below).
First, you can manage your project’s mobile views through the pages dropdown at the top of the editor. From here, you can create new views, navigate to existing ones for editing, or delete views no longer needed. This dropdown also lets you seamlessly switch between web app pages and mobile app views, allowing you to work on both within the same editor.
Typically, each view represents a distinct “screen” you want to display to the user. For example, in Spotify, the app has three bottom tabs—Home, Search, and Your Library. Tapping each tab brings you to its corresponding view. If you’re in the Home tab and tap a playlist, a new view (not a tab) opens, displaying the playlist’s songs. A back arrow at the top lets you return to the previous view, which is an example of “stack navigation” (explained further below).
In stack navigation, views are layered on top of the root view, like stacking cards. Each view you open adds a layer to the stack, and the back button allows you to step back down the stack, one layer at a time. As you navigate, notice that the Home tab remains active. If you switch to the Your Library tab and open a playlist, you’ll see the same Playlist view, but this time within the Your Library tab’s stack. Tapping the back button will return you to the root view of that tab.
You can assign one or more properties on a view to hold data. The property can hold a default value, or be left empty.
Dynamic value: any basic data type or custom data type
Color picker: a hex color code or a saved color variable.
Checkbox: a yes/no value to or from the reusable.
To define a property on a view, use the property inspector:
You can use the Set current view's property action to assign a value to the property of the currently open view.
Navigating between views differs from navigating between pages on the web. Views are more integrated with your app, and both the method and settings used to transition between them can influence how the view behaves within the app’s navigation flow.
Navigating to a new view can be done in two different ways in Bubble:
Tab: Tabs are an integrated part of your app that let users switch between views via a navigation panel at the bottom of the screen, much like in the Spotify example mentioned earlier. Tab navigation doesn’t require an action to trigger the switch; it responds automatically to user taps.
Go to view action: The go to view action is similar to Go to page in the Bubble web app editor, except that views do not technically load any URL or refresh the page. Instead it opens the new view either as a stack or a modal.
Tab navigation allows users to navigate to different views by tapping on tab items on a tab bar at the bottom of your screen, where the tab item has some sort of active state so a user knows what tab they are on.
Bubble makes this easy by including a tab bar with built-in navigation out of the box. Tab items are connected to views, so there is no need to set up any navigation workflows to go between tabs. There are a few ways to add the tab bar to a view.
You can designate a view as a tab item by checking the Include as tab item setting on the view itself. This will automatically add a tab bar to your view, if there isn’t one already, and a new tab item that references the current view.
You can further customize things like the label, the icon, active state behavior, etc. through the tab item property editor. You can always change the view a tab item references as well.
You can create a new tab item from the Tab Bar property editor and either link it to an existing view you have already created or create a new view right there. As before, you can further customize the tab item through the tab item property editor.
A tab item can only reference a single, unique view, meaning a view cannot be linked to multiple tab items.
The tab bar can also be added to a view that isn’t a tab item itself. This helps users stay aware of which tab "stack" they are in, even when navigating to a different view.
The appearance and layout of the tab bar itself can be customized using the tab bar PE. Since the tab bar is a global component, you can make changes to the tab bar on any view, and those changes will be visible across your app on any view that has the tab bar on it.
The appearance and layout of a tab item can be customized using the tab item property editor. Keep in mind, any changes to a tab item will be reflected globally in your app.
Label: This will default to the name of the view. Optional value for text below the icon
Target View: The view that the user should be directed to if they tap the tab item
Icon: Required field. Icon that should be displayed for the tab item
Icon Size: Size of the icon in pixels
Icon color: Color of the icon
Label color: Color of the label can be set using the Font appearance controls
Use conditionals to set up the active and inactive states for the tab items, such as active icon, active color, etc.
Stack navigation is a navigation pattern where users move through a “stack” of screens as they progress through your app. Take the Spotify app as an example: when you’re on a tab, such as Home or Your Library, and navigate to a playlist screen, you’re viewing a new screen while the original tab remains active. This is because the current view is “stacked” on top of the base view, which is the tab itself. To return to the base view, you simply tap the back arrow in the top left corner of the screen.
Another way to navigate to a new view is to use a modal. A modal should be used when you want to provide a scoped experience to the user that requires the full screen. A good example of this is the new message modal in the iOS messages app. Since you don’t need the context of the messages view below, the modal takes up the full screen to allow you to craft your message, but also allows you to quickly return to your messages view.
To open a view as a modal, you’ll use the “Go to view” navigation workflow action but select Modal instead. This will open the target view as a modal sheet over the base view. While you can swipe down to close the modal, it's generally a good idea to include a button to close the modal in an app bar.
To add a close button, add an app bar to the view that will be opened as a modal and add a trailing button with a “Go to previous page” workflow action. This will close the modal when the user taps the button.
Modals are similar to sheets, as both are used to provide a more focused experience for the user. Since a modal represents an entire view, it’s best used when specific data from the "base" view isn’t needed, such as when the data source of a particular group on the base view is irrelevant.
The Go to tab action functions similarly to the Go to view action, including the use of view properties. However, the target view must be associated with a tab. When navigating using the Go to tab action, the tab bar will automatically update to reflect the new tab
The Set current view's property action lets you assign a value to a property on the current open view. To use the action, you need to first define one or more properties on the view.
Show top app bar
Toggles an app bar on the top of your view.
Safe area
Toggles a safe area on your view. Turning the safe area on adds device-specific padding to the view so that the content of your page does not get cut off by features of your device, such as a notch at the top of the screen or rounded corners. You can choose to turn off the safe area on a view if you want a more immersive experience, such as a map or image taking up the entire top of a screen like Google Maps or Tik Tok.
The top safe area will remain visible on the canvas if a top app bar is added to the view, and the bottom safe area will be visible if a tab bar is present. However, even with the safe area setting toggled off, it will still impact content near the side safe areas, even though those areas don’t appear on the canvas.
Show status bar
Toggles the status bar on your view. The status bar represents high level device information like time, battery percentage, and wifi reception. You can choose to turn off this status bar for a more immersive experience - however, keep in mind that this contains important information your users may want to see while they are using your app.
Show tab bar
Toggles a tab bar on the bottom of your view. More details on the Tab Bar below. Note this option is checked and disabled when Include as Tab item is checked since the tab bar must be present when the view is a tab item. Like the Spotify example, there are also instances where you would want the tab bar to appear on the screen even if the current view is not a tab item.
The tab bar is a global component in your app, meaning there is only one tab bar, but it can appear across different views, similar to how reusable elements function in web apps today.
Include as Tab item
Checking this creates a new tab in your tab bar that is linked to the current view. The label will by default be the name of your view, and the default icon will be a star. You can change these settings by selecting the tab item on the canvas.
There are 4 different view types that determine your view’s overall behavior.
If you have content on your view and switch to or from a List view, the existing content will be temporarily removed. If you switch back to the original view type, your elements will reappear.
Scrollable: This is the most common type of view and allows the user to scroll through the screen to see all of the content on the view.
Non-scrollable: A non-scrollable view, true to its name, will not scroll i.e. content cannot extend past the size of the device screen. Non-scrolling views are good for things like a splash screen, a full screen image/video or map.
Vertical list: The vertical list view is also very common and is to be used when you want to display a list of information. See more information in the Components and gestures article.
Section list: A section list is like a vertical list, but it allows you to group your list items by a property of that list item. A good example of this is your contacts app where your contacts are grouped by the first letter of their first or last name.
Signing up and logging in users works in the same way across native apps and web apps within the same app project. In other words, you can use the same actions to sign up or log in a user regardless of whether they are accessing your app through the web or through an app installed on their device.
Using the two actions above will work in exactly the same way as in your web app. You can read more about how user authentication works in our dedicated article in the Data section:
Article series: User accounts
This action, unique to native apps, allows you to use a page from your web app to sign up a new user or log in an existing one. This allows you to use an existing page for the signup/login workflows, as opposed to building one version for your web app and one for your native app. It supports email/password login, OAuth login, and 2FA.
