# Publish your first update

Register the exact Release build on your device, change a label, publish, and verify the result.

## Before publishing {#overview}

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](/docs/channels) for production.

## Choose the release path {#release-flow}

| 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 {#setup}

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 {#register-native}

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 {#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.

```bash title="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 {#publish}

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

```bash title="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:

```bash title="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 {#verify}

1. **Open the original app**: keep the registered Release build installed and connect to the network.
2. **Check for updates**: press Check update or return to the foreground. Observe download events and wait for completion.
3. **Fully close and reopen**: `silentAndLater` does not change the screen immediately. End the process after download, then reopen without uninstalling or clearing data.
4. **Confirm both changes**: the label reads `Pakta demo B`; `currentHash` changes from embedded to the new hash.
5. **Check health**: open critical screens and inspect success or rollback events in [analytics](/docs/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](/docs/faq#no-update), checking download before activation.

## Subsequent releases {#versions}

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 {#rollback}

| 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](/docs/channels) · [Production checklist](/docs/bestpractice).