Native mobile actions
Last updated
Last updated
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.
Push notifications currently only work on iOS. We are working to add Android support as soon as possible.
Before you can use the push notification feature, you need to add your APNs ID and key to your mobile app settings.
Article section: Push notification ID and key
Push notifications allow you to send real-time updates, reminders, or alerts directly to a user’s device, even when the app is not actively in use. Whether it’s a personalized message, a promotional offer, or a notification about app activity, push notifications help keep your users informed and connected with your app’s content.
These notifications leverage the native capabilities of iOS and Android devices, and provide a highly targeted way to reach your audience.
Push notifications require an active permission from users before they can be sent. You must request this permission before sending push notifications to users who have not explicitly approved them.
The push notification features outlined in this article apply only to native mobile applications, and do not apply to web apps.
Using push notifications adds a new built-in data type to your app called devices. This data type contains key information about a user's device(s), and is used as a data source when sending push notifications.
The devices data type is read-only: you cannot rename it, any of its fields or add new fields. This data type is also automatically protected by a preconfigured , since the push notification token is sensitive and should not be shared.
This devices data type is automatically added as a property on the user, meaning that you can access it with a dynamic expression such as:
The push notification token should be considered sensitive data, and should generally not be shared. If you need to share the taken outside of your Bubble app (such as sending a request to a third-party app or system), you can use a backend workflow and check Ignore privacy rules when running this workflow to circumvent the built-in privacy rule.
Both iOS and Android require explicit user consent before sending push notifications. This permission is obtained using the Request push notification permissions action, which triggers the operating system’s standard notification request prompt. The prompt is system-generated and consistent across all apps, meaning it cannot be customized.
After the user has approved the permission request, you can start sending push notifications. To do this, set up an event in the workflow editor, and locate the Emails and notifications action category, and select the Send push notification action.
Keep in mind that you have to use the Request push notification permissions action first to be able to send push notifications.
The Send push notification action comes with the following properties:
Title: the main header
Subtitle: the sub-header
Body: the main message
Devices: needs to be populated with the device data type from one or more users. If you are sending a push notification to the current user, you can use the dynamic expression described in the section above.
Your app icon will also be displayed in the push notification, and cannot be customized per notification. The properties above are used on both systems (iOS/Android) and the final result looks fairly similar on both device types.
Sometimes you'll want to send push notifications at a scheduled time. The Send push notification action is available in the To schedule a push notification, set up an API workflow and use the action.
Web preview: Push notifications cannot be tested in web preview mode.
BubbleGo: Push notifications cannot be tested in the BubbleGo app.
Deployment for testing: To test push notifications, your app must be deployed and uploaded to App Store Connect and added to TestFlight.
