Release and distribution

Release and distribution

AI Markdown

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:

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.

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:

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.