# AOT Compilation Deft normally runs from source: the runtime reads `.dft` files, resolves imports through the package mounts, and compiles each module as it loads. That is the right model for development — edit, reload, repeat. For shipping, Deft can compile an app ahead of time into a bytecode image (`.dftc`) that runs without its source tree. The compiler walks the app's import closure once, emits the compiled bodies into a single binary file, and every host runs that file directly. ## Why Compile Ahead of Time - Deploy a directory, not a source tree. A bundle carries the image, its assets, and metadata. The runtime never opens a `.dft` file, so the machine running the app needs no source packages — and cannot edit them. - Kiosk and commercial deployments. Lockdown's [`images-only`](lockdown-configuration) mode refuses source apps outright; AOT is the supported way to ship those devices. Vendors can distribute a product without shipping readable code. - Predictable startup. The import closure is already parsed and compiled. The loader pre-creates every module namespace, installs the macro registry, and executes precompiled bodies — no source walk at launch. - Self-describing artifacts. The image's own manifest carries the app identity (owner, name, version, description, entry, platforms) and its eventual runtime `requires`, so hosts and installers can inspect the file before loading it. - Integrity. The bundle manifest records a SHA-256 of the image, so an installer can verify exactly what it deploys. ## Why It Stays Deft AOT is a delivery format, not a dialect: - Same language, same semantics. The image is compiled from the same modules the source run loads. The integration suite compiles an app, deletes its source tree, runs the image, and compares output against the source run. - The environment still loads. Images run on top of the normal prelude, so `config.dft`/`lang.dft`/`keys.dft` layering and user-side `[eval ...]` keep working — `eval` sees the image's globals and expands its macros. - One loader, every host. `deft run`, `retro`/`retra`/`hydra`, and the launcher all accept `.dftc` files through the same app loader. An app is launched by path or discovered by name identically whether it is source or image. ## The Shape of It ``` dist/editor/ ├── editor.dftc compiled code + manifest (self-describing) ├── bundle.dft distribution metadata + image sha256 ├── package.dft the package manifest, copied for discovery ├── icon.svg when the package has one └── assets/ the package's asset tree, if any ```` The image carries code only — assets stay ordinary files. Asset loads through `[import/resolve "<owner>/<name>/assets/…"]` fall back to the directory beside the image, so a correctly built bundle is standalone. ## Where to Go Next - Compiling Apps — the commands, flags, and what gets embedded. - Running Images — which host command launches a `.dftc`, and the invocation traps to avoid. - Bundles and Manifests — image manifest, `bundle.dft`, and `package.dft` compared. - Semantics and Limits — what works unchanged, and what images cannot do.