Guides Build & Release Publish a Build

Build & Release 4 min read Updated Aug 2026

Publish a Build

Use this guide when you want to take a Lenga export and hand it to another person or another machine in a repeatable way.

This guide covers a folder-based publish workflow for the exported build:

  • current-platform export
  • same-platform testing
  • packaged player builds
  • folder-based distribution

Step 1: Choose the Right Build Profile

Open:

Project -> Build Settings...

Then choose one of these profiles:

  • Development
  • Release

Use Development when you want a tester or teammate to have a build with debug-mode support still enabled.

Use Release when you want the staged build to behave like a shipping build.

Step 2: Fill in the Shipping Metadata

Before exporting, make sure these fields are correct:

  • Product Name
  • Version
  • Identifier
  • Window Width and Window Height
  • Minimum macOS
  • Startup Scene
  • Icon Path if your project has one

These fields are written into ProjectSettings/lenga.json and carried into the export manifest, including the shipped player-mode permissions.

Step 3: Export the Current Platform

Use either:

Project -> Export Current Platform...

or the button inside Build Settings.

Lenga will stage a packaged player build for the platform you are developing on.

Step 4: Test the Export Locally

Before you hand the build to anyone else, run the exported build on your own machine.

Check:

  • it launches
  • it opens the expected startup scene
  • it can load authored assets
  • UI text and audio behave correctly
  • saves, logs, and temp files land under Game/Saved/
  • Preferences settings use Lenga's engine-managed per-user preferences location
  • the exported build-manifest.json matches the intended player-mode permissions for the build

Step 5: Move It to a Second Machine

For the first real publish check, move the entire exported folder to another machine running the same platform.

Do not cherry-pick files out of the export.

Move the whole folder as a unit, including:

  • the launch artifact, such as the Windows .exe or macOS .app
  • build-manifest.json
  • any supporting packaged files the export folder contains

Step 6: Test the Same Basics Again

On the second machine, verify:

  • the game launches
  • the startup scene is correct
  • keyboard and mouse input work
  • controller input works if the project uses it
  • save files appear under Game/Saved/
  • Preferences settings still load and save through the engine-managed preferences location
  • the game does not rely on blocked PHP capabilities at runtime
  • if a sandbox violation is hit intentionally, the failure is understandable from console output and Game/Saved/Logs/php-runtime.log

Step 7: Archive the Export Folder

The recommended distribution shape is a compressed copy of the full export folder.

Examples:

  • zip the export folder on macOS

Do not flatten the contents. Keep the export root intact.

Sample Release Checklist

Use this checklist before calling a build ready:

  • Build profile is set to Release
  • product name, version, and identifier are correct
  • startup scene is correct
  • export succeeds without sandbox-blocked PHP API errors
  • exported build-manifest.json records the expected player-mode permissions
  • exported build launches locally
  • exported build launches on a second same-platform machine
  • save files are written only under Game/Saved/
  • Preferences settings write through the engine-managed preferences location
  • controller input is tested if the project supports controllers
  • the folder is archived without changing its internal layout

Platform Notes

macOS

macOS builds are distributed as zipped folder exports.

The default workflow uses:

  • the exported .app bundle as the launch artifact
  • build-manifest.json at the export root
  • the packaged project inside the app bundle

This guide does not cover signing or notarization.

Windows

Windows builds are distributed as zipped folder exports for now. Keep the export root intact, including the game .exe, lib/, Game/, and build-manifest.json.

Use a Release SDK/runtime for builds you move to clean machines. Development exports are still allowed, but the native runtime bundle itself must not be a Debug build.

Current Windows exports copy the native runtime and release MSVC runtime DLLs into lib/. If a clean Windows machine reports a missing Debug CRT dependency such as VCRUNTIME140D.dll, VCRUNTIME140_1D.dll, or ucrtbased.dll, rebuild from a Release SDK/runtime. Development exports should still use a Release-native SDK/runtime. Do not ship Debug CRT DLLs.

Linux

This guide does not cover Linux publishing yet.