# Release and distribution

## Function
 can distribute the `dist/{app.name}.exe` generated by `bt_app.exe build` when publishing, and can also distribute the `bt_app.exe pack` generated by `dist/{app.name}.btr` to users who have installed bt_app. The independent exe tail contains application resources and runtime; BTR only contains configuration and resources, allowing multiple software to share the same bt_app. The build directory no longer generates additional FFI license bypass files.

## BTR Distribution

BTR is suitable for tool collections, internal enterprise software libraries and unified toolbars. The publisher only needs to distribute the smaller `.btr`, and the user machine retains a copy of bt_app that matches the system architecture. Run the command:

```powershell
bt_app.exe run .\MyTool.btr
```

 When Windows installs the universal runtime for the first time, execute `bt_app.exe associate` in the final path of the runtime to register the `.btr` open command for the current user. PATH and file association are two different things: PATH only supports direct input of `bt_app` from the terminal, and double-clicking requires file association. BTR's `app.file_associations` will not be automatically registered when running externally, preventing downloaded or temporarily opened software from modifying other business file types.

Every time BTR is run, an independent application process is created, and the VM, window, tray, global shortcut keys and exit do not affect each other. What BTR saves is the disk and distribution volume of duplicate runtimes; multiple concurrently running software may still each create WebView processes.

## Windows
Windows users can directly double-click the packaged exe to run it. If the system lacks WebView2 Runtime, `bt_app` will give a friendly prompt in the startup error path, and users need to install Microsoft Edge WebView2 Runtime.

 It is recommended to confirm before publishing:

- `dev.console` is `false`.
- Whether `app.icon` is a valid `.ico`.
- `dist/{app.name}.exe` can be run independently in a clean directory.
 - If distributing BTR, execute `info` and `run` using the target version bt_app and check the icons, startup parameters and minimum version prompts.
- All the resources required for `static` mode enter the Bundle.
-`server` mode ports do not conflict with common software.
 - When configuring `app.file_associations`, start the packaged exe at least once and verify the double-click file, startup parameters and right-click menu; the existing user default application selection in Windows needs to be confirmed by the user in the system settings.

## The undefined command line interpreter in the official Linux package for Linux and macOS
 is built using the `x86_64-unknown-linux-musl` static target and does not depend on the target server's glibc version when deploying scripts and web services. The static CLI is built using `--no-default-features --features extensions` and does not include FFI which only supports GNU Linux targets; scripts can use `BT.has('ffi')` to detect this boundary. If the server executes `./bt -c main.bt` and reports `GLIBC_2.38 not found` or `GLIBC_2.39 not found`, it should be replaced by `bt` in the new Linux official package.

Linux's `bt_app` is a desktop application engine, which still relies on the WebKitGTK, desktop session and graphical runtime environment of the target system, and is not released statically in musl mode. When distributing for Linux desktops, actual boot verification on the target distribution is required.

macOS uses Darwin/libSystem and does not use glibc, so the `GLIBC_x.y not found` error of Linux will not occur. macOS distributions should use macOS builds for the corresponding architecture and handle signatures, security prompts, and run permissions as required by the system.

 The official packaging output of the current project is still based on `.exe` single file logic. `bt_app.exe export` is a reserved entry. The current version of cross-platform export capability has not yet been completed. When publishing for Linux or macOS, the current actual build product and operating environment verification results should prevail. Do not write the `.icns` and `.png` platform icons as supporting packaging capabilities.

## Remote application update
 In remote entry mode, the software shell itself can remain stable, and business pages and BT scripts can be deployed on the server side. After the developer updates the server content, the user can use the new version of the app again and does not necessarily need to re-download and install the client.

```json
{
  "app": {
    "mode": "remote",
    "entry": "https://example.com/app"
  }
}
```

Remote pages can currently call `window.bt.call()` and window control capabilities. Only trusted HTTPS addresses should be configured when publishing, and attention should be paid to the account, permissions, and content security of the remote page.

## Local packaged application update
 Local resources for `static` and `server` modes have been packaged into exe or BTR. After updating the page, BT script, icon or `app.json`, you need to re-execute the corresponding command:

```bash
./bt_app.exe build
./bt_app.exe pack
```

 and then distribute the new `dist/{app.name}.exe` or `dist/{app.name}.btr` to users.

## WebView2 depends on
Windows desktop window depends on WebView2. During development and release testing, if the window cannot be opened and a WebView-related error is prompted, first check whether the WebView2 Runtime is installed on the system.