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.