Skip to Content
CLI ReferenceUpdate Commands

Update Commands

norrix update

Publish over-the-air (OTA) updates to deployed apps.

Synopsis

norrix update [platform] [version] [options]

Arguments

ArgumentDescription
platformTarget platform: ios, android, or visionos
versionUpdate version (e.g., 2.0.0)

Options

FlagDescription
-p, --project <name>Project name (for Nx workspace builds)
-c, --config <config>Configuration/deployment target (e.g., prod, stg, dev)
--org <orgId>Target organization ID
-V, --version-name <version>App version (e.g., 1.0.0) - should match the build version
-a, --app-id <id>App identifier (bundle ID)
-B, --build-number <number>Build number - should match the build number
-n, --non-interactiveRun without prompts (use defaults/config file)
--dry-runRun all pre-upload steps but skip uploading to Norrix cloud

How OTA Updates Work

  1. The CLI bundles your JavaScript, CSS, and assets
  2. The bundle is uploaded to Norrix storage
  3. Devices running your app check for updates on launch
  4. Compatible updates are downloaded and applied automatically
  5. The update takes effect on the next app restart

Important: Deep Link Base Route Handling

If your app uses deep links (custom URL scheme handlers), make sure the base route (/) is valid and mapped to a real screen.

During OTA activation/restart, the app is relaunched using your URL scheme at the base route. If / is not handled correctly, the app can relaunch to a white screen with no matching route handler.

Before shipping OTA updates, verify that:

  • your-scheme:// resolves to a valid in-app route
  • / (or empty deep-link path) redirects to your default/home screen
  • Unknown/empty routes have a safe fallback instead of rendering nothing

Examples

Basic Updates

# Publish iOS update norrix update ios 1.0.1 # Publish Android update norrix update android 1.0.1 # Publish visionOS update norrix update visionos 1.0.1

With App ID

# Specify bundle ID explicitly norrix update ios 1.0.1 --app-id com.example.myapp

With Build Number

# Set explicit build number norrix update ios -V 1.0.1 -B 42

Targeting Specific Version Series (Hotfixes)

When you have multiple app versions in production, you can target OTA updates to specific version series:

# Hotfix for the 1.1.0 series (even if 2.0.0 exists) norrix update ios --version 1.1.0 # Hotfix for the 2.0.0 series norrix update ios --version 2.0.0

How it works:

  • The CLI finds the latest successful build matching the specified version
  • Fingerprint comparison uses that version’s build as the baseline
  • Users on v1.1.0 receive the v1.1.0 hotfix (if fingerprints match)
  • Users on v2.0.0 receive the v2.0.0 hotfix (if fingerprints match)

This enables parallel maintenance of multiple release branches without forcing users to update to the latest version.

Nx Workspace Updates

# Update specific project from workspace root norrix update ios 1.0.1 --project my-mobile-app # With configuration norrix update ios 1.0.1 --project my-app --config prod

CI/CD Updates

# Non-interactive mode for CI norrix update ios -V 1.0.1 -B 42 -n --org $ORG_ID # Dry run (full archive/fingerprint check, no upload) norrix update ios -V 1.0.1 -n --dry-run --org $ORG_ID

What Can Be Updated

Can be updated via OTA:

  • JavaScript/TypeScript code
  • CSS/SCSS styles
  • Assets (images, fonts, etc.)
  • Non-native npm packages

Requires a new store build:

  • NativeScript platform version changes
  • Native plugin version changes
  • App_Resources folder contents
  • Custom native code (NativeSource)

See OTA Compatibility for details.


Alternative: Web Interface

You can also publish OTA updates directly from the Norrix dashboard.

When to Use the Web Interface

  • Quick updates without CLI setup
  • Team members who don’t have the CLI installed
  • Publishing from any browser-equipped device

How It Works

  1. Navigate to /update in the Norrix dashboard
  2. Build your JavaScript bundle locally using NativeScript CLI
  3. Zip the compiled bundle files
  4. Upload the zip file (uploads directly to S3)
  5. Fill in app ID, platform, version, and optional settings
  6. Add release notes if desired
  7. Publish the update

The web form supports:

  • iOS, Android, and visionOS platforms
  • Version and build number configuration
  • Nx workspace project and configuration
  • Release notes

See Web Interface for detailed instructions.


Rolling Back an OTA Update

To roll back users to a previous version of your JavaScript/CSS code, publish a new OTA update with a higher build number that contains the older codebase.

OTA updates are always delivered forward — a device will never be offered an update with a lower build number than what it currently has. This prevents accidental downgrades when a newer native build (from TestFlight or the App Store) is installed alongside an older active OTA.

Rollback Workflow

Step 1: Check Out the Older Code

# Switch to the commit/tag you want to roll back to git checkout v1.0.1-stable

Step 2: Bump the Build Number

Update your build number so it’s higher than what devices currently have. For example, if devices are on build 22, set the build number to 23:

iOSApp_Resources/iOS/Info.plist:

<key>CFBundleVersion</key> <string>23</string>

AndroidApp_Resources/Android/app.gradle:

versionCode 23

Step 3: Push the OTA Update

norrix update ios -V 1.0.1 -B 23

Devices on build 22 will see build 23 as a newer update and install it. The JS/CSS content is the older (stable) code, but the build number moves forward.

Why Not Just Activate an Older OTA?

Activating an older OTA in the dashboard does not roll it out to devices running a newer build. For example, if a device installed build 21 from TestFlight and build 20 is the active OTA, the device would skip it — build 20 is not newer than build 21.

By publishing a new OTA with a bumped build number, the rollback is explicit, the version history stays monotonically increasing, and there is no risk of accidentally downgrading devices.

Client-Side Reset

If a single user needs to return to the original store binary (for debugging or testing), the SDK provides resetAllOTAs():

norrix.resetAllOTAs();

This clears all downloaded OTA packages on that device and reverts to the installed store binary. See SDK Usage — Reset OTA Updates for details.

Automatic Crash Recovery

If a bad OTA update causes the app to crash on launch, Norrix automatically detects the crash and rolls back to the original store binary on the next launch attempt. No user action is required.

When this happens:

  1. The crash is reported to your OTA Analytics dashboard
  2. The bad OTA is removed from the device
  3. The app boots normally from the store binary

Recommended response:

  1. Go to Dashboard → Updates and Deactivate the bad OTA
  2. Fix the issue and publish a new OTA with a bumped build number

See OTA Crash Recovery for details on how this works and what to do when it occurs.


norrix update-status

Check the status of an update.

Synopsis

norrix update-status <updateId> [options]

Arguments

ArgumentDescription
updateIdUpdate ID to check (e.g., update-1234567890)

Options

FlagDescription
--org <orgId>Target organization ID

Example

norrix update-status update-1234567890

Update Status Values

StatusDescription
scheduledUpdate job has been scheduled
updatingUpdate is being processed
successUpdate published successfully
failedUpdate failed

Output

The command outputs update details including:

  • Update ID
  • App ID (bundle ID)
  • Platform
  • Version
  • Build Number
  • Status
  • Release notes
  • Error message (if failed)