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:
Select the Deploy button located in the upper-right corner of the Bubble menu bar, or access it via the panel.
A deployment popup will appear, allowing you to choose whether to deploy both your web app and mobile app or just the web app.
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.
Multiple live versions
Bubble allows you to manage multiple live versions of your app backend to ensure existing versions of your mobile app remain functional when a new version is deployed. What this means is essentially that an end-user can still use the app even if it’s not upgraded to the very latest version. In many cases, this is fine.
But sometimes, you’ll want to deprecate an older version of your mobile app, and force users to upgrade it before it can be used. This is particularly important because mobile and web deploys are inherently tied.
In this article, we’ll explore why and how you can deprecate older live versions of your mobile app.
Why deprecate older versions?
Deprecating older live versions of your app can be necessary for several reasons:
Critical updates: If you’ve released an overhaul or a critical business feature, you’ll want all users to transition to the updated version to prevent discrepancies or missed benefits.
Security: Older versions may have vulnerabilities that you’ve fixed in newer updates. By deprecating them, you’re ensuring your users have the latest protections.
User experience: Maintaining multiple versions can lead to inconsistencies in performance or features. Deprecating older versions ensures users are aligned with the latest functionality and design.
Deprecating (or un-supporting) a live version means it will no longer accept traffic. While maintaining multiple supported live versions can provide a smoother user experience, it’s best to retire older versions after a reasonable period to encourage users to stay up to date.
The current live version cannot be deprecated.
Deprecating a live version does not remove physical builds from circulation. You will still need to manage this through App Store Connect or other distribution platforms.
Viewing and managing live versions
You can manage your live versions by going to Settings - Mobile. When managing versions, you can see the following information about each build in the list:
Deploy : When the version was deployed.
Deploy message: Notes or details about the deployment.
Mobile platform: Whether the version was built for iOS, Android, or both, displayed as icons. If it’s an OTA update, it will show only the OTA icon.
Build version Number: The specific version identifiers.
From here, you can also deprecate or un-support a live version. Note that you can support up to 5 live versions at a time. In the future, the maximum number of supported versions may vary depending on your app plan. If you reach this limit, the oldest version will automatically be deprecated unless you manually choose which version to deprecate.
Deprecating a live version
To deprecate a live version of your app:
Navigate to Settings - Mobile
You will see the list of the builds and live versions
Click the Deprecate button at the right-hand side of the build row
You will see a confirmation screen.
Click Deprecate version to finish the process
Deprecating a version is irreversible and cannot be undone.
Update app behavior
When a version is deprecated, it will no longer work for users (e.g., server-side actions and data retrieval will stop functioning). To ensure a seamless experience, Bubble includes a built-in update_app view in every app (similar to the built-in 404 page in your web app).
This view prevents unexpected behavior or data loss by guiding users through the update process. You can customize this view to suit your app’s branding and needs.
The view includes:
Conditional text: Adjusted based on whether the latest version is an OTA update or a new build.
Update instructions: Clear messaging for users on how to proceed.
The view can be customized in any way you see fit, just like your 404 page.
The Can update via refresh data source
The deprecation feature comes with a data source called Can update via refresh, which is only available in native mobile apps. This data source lets you check whether the app can be updated via a refresh, as opposed to having to update it via the app store. If the newer version is an OTA (over-the-air) update, this data source will return a yes.
You can use this data source to customize the text on the update_app view and explain the necessary steps to upgrade the app. Note that there are currently no actions to automatically refresh the app or send users to the app store.
Update Scenarios
App refresh (OTA Update)
If the latest update is an update and users are on the current build version, they only need to refresh their app to access the latest version.
Example:
Users are on build version 2.1.
An OTA update is deployed to fix a small bug.
Version 2.1 is deprecated.
Users active during the deployment will see the update_app view prompting them to refresh their app.
If a user is on an older build version and you deploy an OTA update, they must upgrade via the app store to continue.
You can deprecate the base build version even if the update was OTA-only, as the build version remains the same with slightly newer code.
Version upgrade from App Store
If users are on an older build version and you release a new build to the app store, deprecated users must upgrade via the app store.
Example:
Users are on build version 2.1.
A new build (version 2.2) is released to the app store with significant new features.
Version 2.1 is deprecated.
Users see the update_app view with instructions to download the new version.
Users upgrading to the latest build via the app store will automatically access the most current live version, including OTA updates.
Best Practices for Deprecation
While it may seem like a disruptive action, deprecating older versions is standard practice to ensure security, functionality, and a better user experience. However, unless it’s an urgent security or bug fix, plan deprecations carefully to minimize disruption.
For example:
Provide ample time for users to adopt new versions.
Communicate updates clearly through release notes and notifications.
By being strategic, you can maintain a smooth experience for your users while keeping your app current and secure.
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
