Previewing a mobile app

This section describes previewing mobile apps. If you're looking for documentation on previewing web apps, see the article below:

Article: Previewing a web app

BubbleGo is being deprecated as a preview option and is no longer being updated. Because of this, it won't reflect features added to Bubble going forward, so what you see in BubbleGo may not match your app. To preview reliably, use simulated device or a dev build instead.

Previewing your app works much like the Bubble web app editor, letting you see and test changes as you make them. Keep in mind that some parts of the native mobile app editor rely on built-in features of mobile devices, which can vary between iOS and Android. As a result, not every element displays accurately in web preview. Simulated device closes most of that gap.

There are four ways to preview your app:

Method	Where it runs	Plugins	What you need	Best for
Web preview	Your browser, in the editor	Shows a "can't render this" message	Nothing	Quick iteration on layout and logic
Simulated device	Your browser, on a simulated device	All, including those with third-party native libraries	Nothing	Checking native elements and plugin behavior without a device
BubbleGo	Your device, in the BubbleGo app	React Native and a few third-party libraries already installed by Bubble	The BubbleGo app	Getting a feel for the app on a device
Dev build	Your device, as your own app	All, including those with third-party native libraries	An App Store and Google Play connection	Testing native features like push notifications and deep linking

Web preview and simulated device both run in the editor. Switch between them with the preview mode dropdown at the left of the bar above the preview.

Web preview

Differences from web app preview

Web preview works mostly like the preview in the Bubble web app editor, with a few key differences:

• There's no update banner in the preview when changes have been made to the app

• There's an extended bar for managing how the app will look across different devices (see below)

Current web preview limitations

There are currently a few limitations in web preview:

• Native maps element will not render — use simulated device

• Native datetime picker will not render — use simulated device

• Plugins with their own third-party native libraries will not load — use simulated device

• Permissions request workflows may not work properly — use simulated device

• Camera workflows will not work properly — use a dev build

• Push notifications cannot be sent to web preview — use a dev build

• Multi-line inputs in floating groups will not expand to fit height

Device emulator bar

The bar at the top of the screen lets you emulate how the app will look on different devices, screen sizes, and with a specific zoom level.

1. Show device frame: Shows or hides the frame of the selected device (the frame, buttons, and notch, camera, or sensors of the device selected in setting 2).

2. Select device: Provides a list of widely used devices to emulate how the app will look and behave on that specific device.

3. Screen size (px): The actual screen size of the selected device. This is a locked field and updates according to the device selected in setting 2.

4. Zoom level: Zooms the emulator to a specific percentage or to fit the screen height. This zoom affects the entire emulated device, not just the screen.

We recommend testing your app across all devices, so it looks and works the way you expect everywhere.

Simulated device

Simulated device runs your app on a simulated iOS or Android device, streamed into your browser. Unlike web preview, which renders your app in the browser, the simulator runs a real build of your app, so native elements and plugins that rely on their own third-party native libraries work the way they will on a device.

Use simulated device to check anything web preview can't render, without needing a physical device or an App Store or Google Play connection.

Web preview is still the fastest way to iterate on layout and logic, and it's the only place you can inspect and debug. Switch to simulated device when you need to confirm that native behavior is correct.

Switching to simulated device

1

Open preview

Open preview for your mobile app.

2

Open the preview mode dropdown

In the bar at the top, open the preview mode dropdown.

3

Select Simulated device

Choose Simulated device. If your app has plugins that need a real build, Bubble also prompts you in web preview with a tooltip.

Current simulated device limitations

The simulator runs a real build of your app, but it runs it in the cloud, so anything that depends on physical hardware won't work:

• Camera workflows will not work properly — use a dev build

• Push notifications cannot be sent to the simulator — use a dev build

• Device sensors will not report real data — use a dev build

• Inspect and debug are not available in simulated device — use web preview

When you need a new build

Most changes reach the simulator instantly, but some are baked into the build itself:

• Adding or updating plugins that use third-party native libraries

• Changing native device permissions

• Bubble updates to its internal mobile engine

When one of these happens, a Rebuild button appears in the top-right corner of the simulator, along with a message telling you which change caused it: that you added a plugin since the last build, that you changed a setting that affects native configuration, or that Bubble made an update.

Click Rebuild to start the build. Building can take up to 10 minutes, and you can keep working in the editor while it runs. The button shows Building while the build is in progress, and Up to date once you're on the latest build. Until the rebuild finishes, the simulator keeps running the previous build, so what you see may not match your current settings.

If you don't see a Rebuild button, your simulator is already running the current build.

Testing on your own device

The simulator includes a Test on your own device panel, which is your path from previewing in the browser to testing on real hardware. From here you can create a dev build, or connect your app to App Store Connect and Google Play if you haven't yet.

Use this when you've confirmed native behavior in the simulator and want to try your app on a physical device, either through a dev build or BubbleGo.

BubbleGo

BubbleGo is being deprecated as a preview option and is no longer being updated. Because of this, it won't reflect features added to Bubble going forward, so what you see in BubbleGo may not match your app. To preview reliably, use simulated device or a dev build instead.

BubbleGo is a native mobile app that lets you load and interact with your mobile app directly on your device. This mimics the experience of having the app installed on your phone, without needing to connect your project or publish it to the app store.

Use BubbleGo to get a feel for how your users will actually use your app, and to test more advanced interactions, flows, and system connections.

BubbleGo can't send push notifications, and it can't run plugins that rely on their own third-party native libraries. To test those plugins, use simulated device or a dev build. To test push notifications, use a dev build.

Accessing BubbleGo for iOS

In BubbleGo for iOS, you can refresh your app by shaking your iPhone.

1

Download TestFlight

Download the TestFlight app from the App Store.

2

Open the BubbleGo link

Click on this link.

3

Download BubbleGo

Follow the link to download BubbleGo onto the TestFlight app.

4

Log in

Log into BubbleGo using your Bubble account credentials.

5

Select your app

Select the mobile app you'd like to test and go.

Accessing BubbleGo for Android

1

Download BubbleGo

Download the app from the Google Play Store, using either the mobile link or the computer link.

2

Log in

Log into BubbleGo using your Bubble account credentials.

3

Select your app

Select the mobile app you'd like to test and go.

Dev build

A dev build is a version of your native mobile app that you install on your own device for testing. It looks and behaves like your real app, with your icon, your branding, and your plugins, but it stays synced with the Bubble editor, so changes appear on your phone right away. This lets you test your app the way your users will experience it, without publishing to the app stores.

Because a dev build is compiled from your app specifically, it also uses your app's own URL scheme for deep linking and universal links, and runs against your app's real push notification configuration.

Dev builds vs. production builds

A production build is pinned to one version of your app. To ship changes, you create a new build and release it through the app stores. A dev build works differently: it stays synced with the editor, so you rarely need a new one. Create it once, install it on your device, and keep testing as your app evolves.

Dev builds use the same bundle ID and package name as your production app, so push notifications and plugins run against your app's real configuration. This also means your dev build appears alongside production builds in TestFlight or the Google Play Console. To help you tell them apart, a dev build has a modified app icon and launch screen.

	Dev build	Production build
App version	Any of your development branches	Pinned to a single version
Getting changes live	Appears as you edit, shake to refresh	Requires a new build and app store release
Bundle ID or package name	Your app's production identifiers	Your app's production identifiers
Icon and launch screen	Modified, so you can tell it apart	Your production branding

Creating a dev build

Creating a dev build requires your app to be connected to the App Store and Google Play Store, since the build is delivered through TestFlight and the Google Play Console. If you haven't set this up yet, see iOS App Store and Google Play Store.

Dev builds are created per app.

1

Open the build manager

In the Settings tab, open Manage builds and live versions.

2

Start a new dev build

Click + Dev build in the top-right corner.

3

Confirm and build

In the modal, add an optional description, confirm the version, and click Build.

Building can take up to 15 minutes. You can track the status on the same page where your builds and live versions are managed, and we'll email you when the build is ready. From there, install it on your device the same way you install a regular test build:

Platform	How to install
iOS	Through TestFlight
Android	Through the Google Play Console. You'll need to manually release the build to an internal testing track.

TestFlight builds expire 90 days after they're uploaded. If your dev build expires, create a new one.

Testing with a dev build

1

Open the dev build

Open the dev build on your device. The launch screen shows your app's name with a Dev build tag.

2

Log in

Log in with your Bubble account credentials.

3

Select a branch

Select the branch you want to test. It loads immediately.

4

Refresh to see updates

Shake your device to refresh and view new updates.

Your dev build now loads your app as it exists in the editor for that branch. Changes you make in the editor become available in the dev build without a new deployment. Shake your device to refresh the app or return to the launch screen, for example to reload from scratch or switch to a different branch.

When you need a new dev build

Most changes reach your dev build instantly, but some are baked into the native binary itself and can only be delivered by creating a new build. This includes:

• Adding or updating plugins that use third-party native libraries

• Changing native device permissions

• Bubble updates to its internal mobile engine

When this happens, the affected dev build is marked Outdated in Manage builds and live versions. An outdated dev build still receives your changes, but it won't reflect the ones listed above until you create a new build.

To help you keep track of what each build contains, every build card in Manage builds and live versions lists the plugins that were included when the build was created. Inside the dev build itself, branches that contain changes requiring a new build are flagged on the branch selection screen.

The same changes require a new build in simulated device, where Bubble prompts you with a Rebuild button when one is needed.

FAQ: Previewing a mobile app

What are the ways to preview a mobile app?

There are four: web preview (in the browser, inside the editor), simulated device (a real build of your app on a simulated device, in the browser), BubbleGo (your app loaded on your own device through Bubble's BubbleGo app), and dev builds (a synced version of your app installed on your device).

Which preview method should I use?

Use web preview for quick iteration on layout and logic, since it's the fastest option and the only place you can inspect and debug. Switch to simulated device to confirm native behavior without needing a physical device. Use a dev build to test native features like push notifications and deep linking.

Why doesn't everything display correctly in web preview?

Some parts of the native mobile app editor rely on built-in features of mobile devices, which vary between iOS and Android, so not every element renders accurately in web preview. Simulated device closes most of that gap.

What are the current limitations of web preview?

The native maps element and native datetime picker won't render, plugins with their own third-party native libraries won't load, permissions request workflows may not work properly, camera workflows won't work properly, push notifications can't be sent to web preview, and multi-line inputs in floating groups won't expand to fit their height.

How is simulated device different from web preview?

Web preview renders your app in the browser, while simulated device runs a real build of your app on a simulated iOS or Android device, streamed into your browser. Because it's a real build, native elements and plugins that rely on their own third-party native libraries work the way they will on a device.

Do I need a device or an app store account to use simulated device?

No. Simulated device lets you check anything web preview can't render without a physical device or an App Store or Google Play connection.

What are the limitations of simulated device?

The simulator runs a real build, but it runs it in the cloud, so anything depending on physical hardware won't work: camera workflows won't work properly, push notifications can't be sent to the simulator, and device sensors won't report real data. Inspect and debug also aren't available in simulated device. To test any of these, use a dev build.

When does simulated device need a rebuild?

Most changes reach the simulator instantly, but some are baked into the build itself. When that happens, a Rebuild button appears in the top-right corner of the simulator. Building can take up to 10 minutes, and you can keep working in the editor while it runs. Until the rebuild finishes, the simulator keeps running the previous build, so what you see may not match your current settings.

Can BubbleGo send push notifications or run any plugin?

No. BubbleGo can't send push notifications, and it can't run plugins that rely on their own third-party native libraries. To test those plugins, use simulated device or a dev build. To test push notifications, use a dev build.

How do I refresh my app in BubbleGo?

In BubbleGo for iOS, you can refresh your app by shaking your iPhone.

What is a dev build?

A dev build is a version of your native mobile app that you install on your own device for testing. It looks and behaves like your real app, with your icon, branding, and plugins, but it stays synced with the Bubble editor, so changes appear on your phone right away, without publishing to the app stores.

What do I need before creating a dev build?

Your app needs to be connected to the App Store and Google Play Store, since the build is delivered through TestFlight and the Google Play Console.

How long does a dev build take, and how do I install it?

Building can take up to 15 minutes, and Bubble emails you when it's ready. On iOS you install it through TestFlight, and on Android through the Google Play Console, where you'll need to manually release the build to an internal testing track.

Do dev builds expire?

Yes. TestFlight builds expire 90 days after they're uploaded. If your dev build expires, create a new one.

How do I see my latest editor changes in a dev build?

Your dev build loads your app as it exists in the editor for the branch you select, and changes you make in the editor become available without a new deployment. Shake your device to refresh the app or return to the launch screen, for example to reload from scratch or switch branches.

When does a dev build need to be rebuilt?

Most changes reach your dev build instantly, but some are baked into the native binary and need a new build: adding or updating plugins that use third-party native libraries, changing native device permissions, and Bubble updates to its internal mobile engine. When this happens, the build is marked Outdated in Manage builds and live versions. It still receives your other changes, but won't reflect those three until you create a new build.