Deploying

Once you have your accounts and projects set up, you can begin the process of building your app. This process will start by deploying your app to Live, just like you would with your web app.

Relationship between web and mobile deploys

While your mobile app is its own standalone application, it still relies on a hosted database and server to store and retrieve data. This means there’s always a connection between your mobile app and web app, even if your app doesn’t have explicit web pages.

One key difference to be aware of is that web deploys are nearly instantaneous, whereas mobile app updates, outside of OTA (Over-The-Air) updates, can take a few days to go through the app store review process. So while changes to your web app go live immediately, updates to your mobile app may take additional time before they are available for users to download.

This timing difference is crucial because when you deploy your app to Live, you’re releasing a new version of both your mobile and web apps. Even if there are no changes to your mobile views, any updates made to backend workflows on the web app will still affect the mobile app when it makes server calls to the shared web backend.

For example, imagine you have a backend workflow that triggers when a user taps a button on both the mobile and web versions of your app. If you modify that workflow to send an email as part of the process and then deploy the changes to the web app without publishing a new mobile version, the mobile app will still interact with the older version of your web app’s API—the version before the email action was added. This is because we support “older” versions of your app’s API to prevent your mobile app from breaking while the new version is under review.

To ensure that your mobile app communicates with the most up-to-date version of the web app, you’ll need to release a new version of the mobile app. In some cases, this can be resolved with a simple OTA update, especially if no mobile-specific changes were made. However, in other cases, you may need to build and submit a new version of the app to the app store.

We'll explore the differences between OTA updates and new builds below.

OTA vs. Build Updates

Build

In mobile development, a “build” refers to generating a new version of your app that users need to download from the app store. When you submit a build to the App Store or Google Play, users must update the app on their devices to access the latest features, functionality, or bug fixes. You should create a new build for submission when making significant changes to the app’s user interface (UI), functionality, or fixing critical issues. If you’re addressing major bugs or security vulnerabilities, it’s a good idea to retire older versions in the App Store Connect or Google Play Console, forcing users to update to the new version.

OTA (Over-the-Air) Updates

An OTA update works more like a web deployment. It allows users to receive updates via the internet without needing to download a new version from the app store. Once an OTA update is pushed, users will get the latest code when they refresh the app. While OTA updates are convenient, they are best suited for minor updates.

Apple recommends using OTA updates only for small functionality changes or bug fixes that won’t significantly alter the app’s UI or overall experience.

For instance, avoid pushing an entire app redesign or a major feature update via an OTA. However, a common strategy is to release new features or UI changes behind a , and then remove the flag for selected users through an OTA update.

This explains why you might occasionally see visual or functional changes in an app without having downloaded a new version.

Semantic Versioning

Semantic versioning is a method used to track your app’s version and the nature of the updates. Versions are typically formatted as {Major}.{Minor}.{Patch}.

For example, version 1.5.14 indicates:

  • Major: 1 – Large updates like a complete redesign or major new features.

  • Minor: 5 – Smaller updates, such as adding new features or making design tweaks.

  • Patch: 14 – Tiny updates that address bugs or improve security.

In Bubble, the deploy flow simplifies this by asking you to choose whether the update is Major, Minor, or Patch, and the system automatically increments the version number for you.

The version number increments even if the build fails. For example, if version 1.0.1 fails during the build, the next available version will be 1.0.2, even if the 1.0.1 update wasn’t released.

Operating system compatibility

Our current version of React Native will support:

  • iOS devices running version 13.4 and later

  • Android devices running version 6.0 and later.

Devices running unsupported OS versions are not guaranteed to work as expected.

Please be aware that certain native features may only be supported by later OS versions as well. The oldest supported version will be noted per feature in the documentation.

As we stay up to date with the latest versions, these versions are bound to change.

The deployment process

To deploy your app, follow these steps:

  1. Select the Deploy button located in the upper-right corner of the Bubble menu bar, or access it via the panel.

  2. A deployment popup will appear, allowing you to choose whether to deploy both your web app and mobile app or just the web app.

    1. If you choose to publish your native mobile app, you’ll have the option to perform either an OTA (Over-the-Air) update or create a new build. Selecting a new build also allows you to adjust your app’s semantic versioning as part of the process.

Build timeouts (unhandled errors)

Bubble manages a wide range of errors during the build and update processes. Most errors are handled automatically, resulting in a clear failure message either at the start of the build or during its progression. However, there are instances where unhandled errors may occur, causing the build or update process to become stuck in the “building” stage. This can block future deployments.

To address this, we have implemented timeouts as a safeguard to automatically fail builds or OTA updates that remain stuck due to unhandled errors. This ensures that the deployment pipeline remains functional and prevents disruptions caused by lingering processes.

App store build

  • Duration: 1 hour

  • Behavior: If a build runs for longer than one hour without completing, it will automatically be marked as failed. This indicates that the process encountered an unhandled error.

OTA build

  • Duration: 10 minutes

  • Behavior: OTA updates that exceed 10 minutes will also be marked as failed.

Last updated