App, Runtime and Container Updates
There are a number of update mechanisms to be aware of. This document describes the different update mechanisms as well as differences between platforms.
Note: Changes since version 4.56
Before version 4.56.0 of the container, the JourneyApps Runtime was bundled with the container instead of the application. This meant that runtime updates were outside the control of developers, and users of an app could have a wide range of runtime versions, depending on the container that they have installed.
From version 4.56.0, it is possible to select a runtime version to be used in the application. This runtime forms part of the application OTA update, ensuring that all users are using the same version.
Users running older versions of the container will not be able to download an OTA runtime version, and will get a message prompting to update the container. The same may apply in the future if a runtime version requires a new container.
If an application does not specify a runtime version, it will still use one depending on the installed container. The last runtime version available in this way is v4.59.1. For newer runtime versions, the version has to be explicitly configured for the application.
To see a full changelog of changes with each update to the Runtime and Container, please visit whatsnew.journeyapps.com.
The following gives an overview of the concepts of "container", "runtime" and "app":
Container
Runtime
App
Description | The native application initially installed on the user's device. It is only a shell containing the sign in process, as well as native functionality for the specific platform, e.g. camera or GPS |
Update Mechanism | |
Update Frequency | A few times per year |
Version Scheme | Year.Month.Version |
Description | The framework responsible for running an application, e.g. interpreting the XML and JS code that defines a specific app, as well as managing storage and data sync. |
Update Mechanism | Selected by developer in OXIDE for an app. Updates over-the air along with app updates for apps with Version Management enabled under App Settings. |
Update Frequency | Multiple versions per month |
Version Scheme | Major.Minor.Patch |
Description | The XML and JavaScript/TypeScript files written by developers in OXIDE that define the user workflows and logic. |
Update Mechanism | Over-the-air when a developer deploys via OXIDE. |
Update Frequency | Multiple updates per day, week, or year |
Version Scheme | Defined by developer |
The app and runtime are updated OTA ("over-the-air") as soon as a deploy is performed by a developer. Regular users will see a notification to update their app, after which the app may navigate back to the
main view.Developers, when using the Testing barcode to test their app, will see that updates are applied immediately, with no intervention required in the app. This makes it quick to make changes to the app and see the result of the changes.
To use functionality in newer JourneyApps versions (e.g. updates to UI Components), the runtime for the app must be updated to the newer version.
Container updates are comparatively more complicated than app updates, in that the way in which updates can be applied depends on the platform on which the Container is running, as well as whether the standard JourneyApps Container, or a custom-branded container is installed.
The following table explains the differences between all the Container Update mechanisms:
Platform | JourneyApps-Branded Container | Custom-Branded Container |
|---|---|---|
Android | Applied as per OS-level setting for installing updates automatically. | Need to be manually distributed and installed. |
iOS | Applied as per OS-level setting for installing updates automatically. | Need to be manually distributed and installed. |
Windows | N/A | Download initiated when user clicks on sync button. Applied when selected by the user, or application is restarted. |
We recommend keeping users on the latest container at all times. Mobile device management (MDM) software is recommended to distribute and update applications for Android and iOS.
The Runtime uses Semantic Versioning. Breaking changes will either be behind feature flags, or be part of major version bumps (for example in version 5.0.0).
New features will be introduced in minor versions, e.g. in 4.71.0. It should generally be safe to update minor versions, but always make sure to test. There may be some visual or behavioral changes as part of minor versions.
Patch releases will only include bug fixes, and should always be a safe upgrade.
Tracks are used to classify runtime versions. The table below describes all the runtime tracks. Please note that some tracks may not be visible to all developers.
Track | Description |
|---|---|
dev | These are highly experimental, often still under development. They are useful for quickly testing experimental features but have no guarantees regarding stability. These builds should not be deployed to production users. |
beta | These have passed initial Quality Assurance (QA), and may include early-access features. This track is also not intended for production use. |
rc | These have been through significant QA. It is considered production-ready but needs the opportunity to run in production environments before being considered completely stable. |
stable | These are considered completely safe to use in production and should be the default track for most of apps to be on. Developers should still test their apps when selecting a new stable runtime, since there may have been changes in terms of functionality. |
Last modified 5mo ago