Xojo Project Format Reference

Sample Xojo projects saved in the IDE's text project format (Xojo 2026r3+), one per project type. Each folder holds a project written by the Xojo IDE, plus a short README.md.

The kit has two purposes:

• A format reference for AI agents that create or edit Xojo project files by hand. Agents use it to check the correct structure, syntax and conventions of each file type.
• Training data. Every file is genuine IDE output, so the projects show what valid Xojo text-format files look like.

These projects are references, not templates.

Pick the folder for your project type

Check the Type= line at the top of the target project's .xojo_project file:

Type=	Project type	Folder
Desktop	GUI app with windows, menus, toolbars	DesktopAppStructure/
Web2	Web app (pages, dialogs, sessions)	WebAppStructure/
Console	Command-line app, no UI	ConsoleAppStructure/
Mobile	Android app (screens, mobile containers)	AndroidAppStructure/
iOS	iOS app (screens, layouts, launch screen)	iOSAppStructure/

Starting a new project? Use the folder for the kind of app you're building.

How to work with a folder

1. Read that folder's README.md first. It says which files show what.
2. Check, don't guess. Each project contains a sample of every item and member type for its platform (and, for Desktop, Web, Android and iOS, every control). Before writing a file, look at the matching sample file to confirm the exact format.
3. Use only the folder for your project type. The formats look alike but differ in the details: file extensions, manifest item types, control classes, event names and panel indexing. A rule from one folder can produce a broken file in another project type.

Common to all project types

Code items and the manifest follow the same rules in every project here. Module1.xojo_code in any folder shows most of them.

• Code items (.xojo_code) open and close with paired tags: #tag Class / Protected Class X … End Class / #tag EndClass, and the same shape for Module and Interface. Top-level items are written as Protected too.
• Members use the same tags everywhere: #tag Method, Property, ComputedProperty, Constant, DelegateDeclaration, ExternalMethod, Hook (event definition), each closed by its #tag End….
• Scope is set by Flags: &h0 public, &h1 protected, &h21 private. The signature's keyword must match (Flags = &h21 → Private Sub …). Constants use Scope = Public|Protected|Private instead.
• Help text (Description = … on a tag) is stored as hex-encoded UTF-8.
• Indentation: #tag structure uses tabs. Code lines inside a method use the tag's tabs plus two spaces.
• Manifest item lines (.xojo_project): ItemType=Name;Path;ItemID;ParentID;false. Root items have ParentID &h0000000000000000. Items inside a folder or module use that container's ItemID and live in its directory.
• ViewBehavior blocks are generated by the IDE. Don't write them by hand.

Build Automation

Every project has a Build Automation.xojo_code file, created by the IDE. Don't create it or add comments to it. Before reading or editing build steps, see BuildAutomation.md.

Repository files

• BuildAutomation.md is the format reference for Build Automation.xojo_code, common to all project types.
• .gitignore excludes the per-user .xojo_uistate files, build output, the IDE's *.obsolete_* leftover folders, agentic-mode handshake files and OS clutter.
• .gitattributes normalizes text line endings and marks .xojo_resources and .xojo_uistate as binary.