Platforms

platform/<name>/ contains the platform-specific entry points: each platform supplies a binary's main function, an OS_<Platform> subclass, a DisplayServer<Platform> (where the platform owns the windowing system), per-platform export logic, and any platform-only drivers.

Supported platforms

Platform	Directory	Render APIs	Audio API	Notes
Linux/BSD	linuxbsd/	Vulkan, OpenGL ES 3 (compatibility)	ALSA, PulseAudio	Both X11 and Wayland display servers
Windows	windows/	Vulkan, Direct3D 12, OpenGL ES 3	WASAPI, XAudio2	MSVC and MinGW supported
macOS	macos/	Metal (via MoltenVK or native), Vulkan, OpenGL 3.3	CoreAudio	Universal (arm64 + x86_64) builds supported
Android	android/	Vulkan, OpenGL ES 3	OpenSL ES, Oboe	Java + JNI integration; can ship as editor APK
iOS	ios/	Metal, OpenGL ES 3	CoreAudio	Apple-embedded layer shared with visionOS
visionOS	visionos/	Metal	CoreAudio	Apple-embedded layer; XR-ready
Web	web/	WebGL2 (compatibility renderer)	Web Audio API	Emscripten; WebAssembly + JS shim

The "apple_embedded" subdirectory under platform/ holds code shared between iOS and visionOS. The Apple desktop / mobile / vision split mirrors how Apple has structured its OS family.

Per-platform structure

Each platform follows roughly the same pattern:

platform/<name>/
├── SCsub                        SCons enumeration of sources
├── detect.py                    Build options + toolchain detection
├── godot_<name>.cpp             Application entry (the equivalent of main.cpp on that OS)
├── os_<name>.{cpp,h}            OS subclass (file system, threads, environment, exit code)
├── display_server_<name>.{cpp,mm,h}    Window + input + render context
├── crash_handler_<name>.{cpp,h}        Crash handler + symbolicated stack traces
├── joypad_<name>.{cpp,h}        Joypad / gamepad backend
├── export/                      Platform's exporter (.app/.apk/.ipa/.exe creation)
├── doc_classes/                 (optional) platform-only API docs
└── platform_<name>_builders.py  Build-time data baking (e.g., entitlements, plist generation)

The platform layer is the smallest non-thirdparty layer in the engine — everything heavy lives elsewhere. Its job is to translate the OS event loop, file paths, and threading primitives into the abstract OS and DisplayServer interfaces.

Boot sequence per platform

sequenceDiagram
    participant OS as OS-supplied entry point
    participant Plat as platform/<name>/godot_<name>.cpp
    participant Main as main/main.cpp
    participant Loop as scene/main/scene_tree

    OS->>Plat: WinMain / NSApplicationMain / android_main / em_arg_callback_func / int main(...)
    Plat->>Plat: instantiate OS_<Platform>, DisplayServer<Platform>
    Plat->>Main: Main::setup(...)
    Plat->>Main: Main::setup2()
    Main-->>Plat: ready
    Plat->>Plat: enter platform-specific message loop
    loop frame
        Plat->>Main: Main::iteration()
        Main->>Loop: SceneTree::process(delta)
    end
    Plat->>Main: Main::cleanup()

The platform-specific message loop matters: on Windows it pumps PeekMessage/TranslateMessage/DispatchMessage; on Linux/X11 it pumps the X event queue alongside select/poll for timers; on Android it integrates with the JNI lifecycle (the Java side calls into native at each frame); on Web it hooks requestAnimationFrame via Emscripten.

Cross-platform abstractions live elsewhere

When working on platform code, lean on the shared abstractions:

• OS (core/os/os.h) — every platform supplies its OS_<Platform> subclass under platform/<name>/os_<name>.cpp.
• DisplayServer (Display server) — defines the window + input contract.
• Drivers (Drivers) — graphics + audio + input drivers are decoupled from platforms; e.g., the Vulkan driver works on Linux, Windows, Android equally.
• Build detection — detect.py advertises which compilers, SDKs, and architectures the platform supports; methods.py is consulted for shared build helpers.

See also

• Linux / BSD
• Windows
• macOS
• Mobile (Android, iOS, visionOS)
• Web