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.

Overview

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

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	Dependent on OS and specific container. Read more in Container updates section.
Update Frequency	A few times per year
Version Scheme	Year.Month.Version

Runtime

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

App

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

App and runtime updates

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

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.

Runtime versioning in more detail

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.

Runtime tracks

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.