Overview:
Native Versioning allows you to control when an update should happen based on native features and binary version.
For instance, if you have Live Update pulling from the "Production" Channel, and you push an update that requires a native plugin that didn't exist until version 1.2.3 of your App, you'll want to set the iOS/Android Minimum version to 1.2.3. This will prevent earlier versions of your App from downloading live updates that require that native functionality. See the following articles for more details on Deploy and binary compatible live updates.
Caution:
When using this feature Appflow expects app versions to follow the NPM semver standard. This standard does not allow for leading zeroes before any other digit. Apps with an invalid version will not be properly handled.
Examples:
1.0.3 = valid
1.0.03 = invalid
0.0.50 = valid
0.0.050 = invalid
To resolve the issue simply correct the version and prepare a new native build.
Procedure:
To set native versioning:
- Select Build>Builds.
- Select the Web Deploy build you plan to use for an update form the list of available builds.
Select the Versioning tab and set the appropriate version for each mobile platform. After setting versions click Save.
Fields are defined as follows:
- Minimum: Native binary must be at least this version in order to download this Live Update.
- Maximum: Native binary must be this version or below in order to downloadthis Live Update.
- Equivalent: If the Native binary is this version, do NOT download this Live Update, because they are equal.
In the example shown above:
- Users running version 1.0.0 will not receive the update because the version is lower than the minimum version requirement.
- Users running version 1.0.1 will receive the update because the version meets the minimum version requirement.
- Users running version 1.0.2 will not receive the update because the version matches the equivalent version.
- Users running version 1.0.3 to 2.0.0 will receive the update because the version meets the maximum version requirement.
- Users running version 2.0.1+ will not receive the update because the version is greater than the maximum version requirement.
Example Scenario:
Below is an example of a common native versioning scheme. In this scenario we'll be managing each native release (distributed through the App Store/Play Store) with equivalent, and minimum version requirements. Bear in mind that all changes to an app's native configuration will require a new native build, and native distribution. See our doc on binary compatible changes for more details on when a new native build is necessary.
We'll manage updates to our webcode using the minimum version exclusively. This will allow for seamless updates for a given native version.
Note: As a best practice we recommend that only commits intended for release be deployed to a channel.
| Commit Version | Min | Max | Equivalent |
| 1.0.0 (native) | 1.0.0 | 1.0.0 | |
| 1.0.1 | 1.0.0 | ||
| 1.0.2 | 1.0.0 | ||
| 1.1.0 (native) | 1.1.0 | 1.1.0 | |
| 1.1.1 | 1.1.0 | ||
| 1.1.2 | 1.1.0 | ||
| 2.0.0 (native) | 2.0.0 | 2.0.0 | |
| 2.0.1 | 2.0.0 |
Frequently Asked Questions:
- What happens when no native versioning is used?
All versions of the app will attempt to download the live update. This can lead to issues where an older version of the app tries to install a live update that is not binary compatible.
- What happens when I set the native versioning a day or two after and some users received the live update?
Users who have already received the live update will continue to be on this updated version. The native versioning restriction will then work moving forward for other users.
- Is there a way to pause or stop the live update after deploying it?
The recommendation for this scenario would be to restrict the native version to 0.0.0 so that no devices can receive the Live Update.
Comments
0 comments
Article is closed for comments.