Publish your first update

Updated 2026-09-14

On this page

Before publishing
Choose the release path
1. Confirm application and native version
2. Register the exact installed build
3. Change a label and bundle
4. Preview and publish to the test device
5. Verify on the device
Subsequent releases
Recover from a production incident

Before publishing

Your device has a Release app with the Provider and displays Pakta demo A. Change it to Pakta demo B without installing another native package.

Use a separate test application at 100%. Use staged rollouts for production.

Choose the release path

JS, styles and JS-referenced assets only	Native code, permissions, dependencies or runtime
Publish an update	Publish a native installer
Edit and test JS	Edit and test native project
↓	↓
`pakta bundle` produces `.ppk`	Build Release APK / AAB / IPA / APP
↓	↓
Upload update package	`pakta uploadApk` / `uploadAab` / `uploadIpa` / `uploadApp`
↓	↓
Choose registered channel and native version	Retain and distribute that exact installer
↓	↓
Set percentage, preview and publish	Target this native version in future updates
↓	↓
Matching installed devices check, download and activate	Users install the new native version first

For initial integration complete the right branch before the left. The walkthrough uses Android; step 2 lists iOS and HarmonyOS upload commands.

1. Confirm application and native version

Run from the app root. me checks the current identity:

bash

pakta me
pakta selectApp --platform android

Examples use android, channel default and native version 1.0.0. Replace 1.0.0 with the native version displayed on your device. Do not use the update name or rebuild the app just to match the example.

2. Register the exact installed build

This APK path is for a standard Gradle project without flavors. Substitute the actual artifact path.

bash

pakta uploadApk ./android/app/build/outputs/apk/release/app-release.apk
pakta packages --platform android

the CLI and console native-package view contain the channel, version and build. Do not substitute a newly rebuilt package for the installed one.

Format	Registration command	Note
APK	`uploadApk PATH`	Simplest local Android exercise
AAB	`uploadAab PATH`	Match the distributed build and relevant splits
IPA	`uploadIpa PATH`	The archive corresponding to the installed build
Harmony APP	`uploadApp PATH`	The `.app` built in DevEco

Channel comes from native metadata, defaulting to default. --channel asserts identity, not rewrites it. Uploads use a reduced baseline rather than sending the whole store package as OTA content.

3. Change a label and bundle

Change Pakta demo A to Pakta demo B. Do not change native dependencies, native version, Hermes or RN, and do not reinstall the app.

App root

pakta bundle --platform android --output .pakta/output/android.ppk --no-interactive

.pakta/output/android.ppk exists and bundling completed without errors. The default sourcemap is .pakta/intermedia/android/index.bundlejs.map; check build logs for custom settings. Add --expo for Expo projects.

Omit --name here; it makes bundle enter publishing immediately.

4. Preview and publish to the test device

Replace the version, channel and paths. These single-line commands work in PowerShell, Bash and zsh:

Preview only

pakta publish .pakta/output/android.ppk --platform android --name demo-b --channel default --packageVersion 1.0.0 --rollout 100 --dryRun --no-interactive

Preview parses targets and percentages. It does not prove device compatibility, upload connectivity or publication. Once targets are correct, publish:

Publish to the separate test application

pakta publish .pakta/output/android.ppk --platform android --name demo-b --channel default --packageVersion 1.0.0 --rollout 100 --sourcemap .pakta/intermedia/android/index.bundlejs.map --no-interactive

save packageId and deploymentIds. In the application's update/deployment view, verify the active target, native version, channel and 100% percentage. Devices can use full downloads while differential tasks are pending.

5. Verify on the device

Open the original app: keep the registered Release build installed and connect to the network.
Check for updates: press Check update or return to the foreground. Observe download events and wait for completion.
Fully close and reopen: silentAndLater does not change the screen immediately. End the process after download, then reopen without uninstalling or clearing data.
Confirm both changes: the label reads Pakta demo B; currentHash changes from embedded to the new hash.
Check health: open critical screens and inspect success or rollback events in analytics.

	Before	After
Label	Pakta demo A	Pakta demo B
Native version	1.0.0	1.0.0 (unchanged)
currentHash	Empty, shown as embedded	New update hash

Still seeing A? Follow troubleshooting, checking download before activation.

Subsequent releases

For compatible JS/assets, repeat steps 3–5. Native changes require distributing and registering a new native package before targeting its version.

bash

pakta versions --platform android

Contents and hashes are immutable; names and descriptions can be edited. Retain native baselines, .ppk files, matching sourcemaps and deployment records.

Recover from a production incident

Action	Devices not yet updated	Devices already running the bad update
Pause the bad deployment	Stop receiving that deployment	Installed content is not undone
Reduce the percentage	Fewer subsequent matches	No active rollback
Redeploy a stable historical package at 100% to the original target	Can receive stable content	Can return on subsequent check and activation

Select a retained stable package in the console and create a new full deployment for the same channel and native version. Review affected targets before submitting. A new deployment sequence makes older content eligible as a later release. Recovery follows device check/activation policy, not an instantaneous remote undo.

Next: Channels and rollouts · Production checklist.