Update Commands
norrix update
Publish over-the-air (OTA) updates to deployed apps.
Synopsis
norrix update [platform] [version] [options]Arguments
| Argument | Description |
|---|---|
platform | Target platform: ios, android, or visionos |
version | Update version (e.g., 2.0.0) |
Options
| Flag | Description |
|---|---|
-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-interactive | Run without prompts (use defaults/config file) |
--dry-run | Run all pre-upload steps but skip uploading to Norrix cloud |
How OTA Updates Work
- The CLI bundles your JavaScript, CSS, and assets
- The bundle is uploaded to Norrix storage
- Devices running your app check for updates on launch
- Compatible updates are downloaded and applied automatically
- 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.1With App ID
# Specify bundle ID explicitly
norrix update ios 1.0.1 --app-id com.example.myappWith Build Number
# Set explicit build number
norrix update ios -V 1.0.1 -B 42Targeting 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.0How 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 prodCI/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_IDWhat 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
- Navigate to
/updatein the Norrix dashboard - Build your JavaScript bundle locally using NativeScript CLI
- Zip the compiled bundle files
- Upload the zip file (uploads directly to S3)
- Fill in app ID, platform, version, and optional settings
- Add release notes if desired
- 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-stableStep 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:
iOS — App_Resources/iOS/Info.plist:
<key>CFBundleVersion</key>
<string>23</string>Android — App_Resources/Android/app.gradle:
versionCode 23Step 3: Push the OTA Update
norrix update ios -V 1.0.1 -B 23Devices 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:
- The crash is reported to your OTA Analytics dashboard
- The bad OTA is removed from the device
- The app boots normally from the store binary
Recommended response:
- Go to Dashboard → Updates and Deactivate the bad OTA
- 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
| Argument | Description |
|---|---|
updateId | Update ID to check (e.g., update-1234567890) |
Options
| Flag | Description |
|---|---|
--org <orgId> | Target organization ID |
Example
norrix update-status update-1234567890Update Status Values
| Status | Description |
|---|---|
scheduled | Update job has been scheduled |
updating | Update is being processed |
success | Update published successfully |
failed | Update 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)