Mobile (Android, iOS, visionOS)

The mobile platforms share many concerns — small screens, restricted I/O, tile-based GPUs, signed application packaging — but each has its own platform layer in the repo. iOS and visionOS share an "Apple Embedded" common layer.

Android

Layout

platform/android/
├── godot_android.cpp                Native entry (called from JNI)
├── os_android.{cpp,h}               OS_Android subclass
├── display_server_android.{cpp,h}   ANativeWindow + JNI input
├── audio_driver_opensl.{cpp,h}      OpenSL ES audio
├── android_input_handler.{cpp,h}    Touch, gamepad, sensor input
├── api/                             JNI helper classes (`JNISingleton`, GlobalConstants)
├── java/                            The Java/Kotlin side: GodotActivity, Godot library, gradle build
│   ├── lib/                         The shared library wrapper exposed to apps
│   └── editor/                      The editor APK (the editor running on Android)
├── export/                          APK + AAB packaging, asset packs, manifest editing
├── plugin/                          Android plugin host (.aar plugins for ads/IAP/permissions)
└── detect.py

Process model

The Java side (java/) starts the activity. GodotActivity (Java/Kotlin) loads libgodot_android.so via System.loadLibrary, hands off to Godot::native_step per frame, and forwards lifecycle events. The native side runs the engine on a dedicated thread; touch and sensor events are marshalled across via JNI.

Display server

DisplayServerAndroid translates between Android's Surface / ANativeWindow and the engine's display server interface. It supports:

• Vulkan (preferred on modern devices) and OpenGL ES 3 (fallback).
• Multi-touch (up to ~10 pointers).
• Soft keyboard with IME composition events.
• Sensor input for tilt-based games (accelerometer, gyroscope, magnetometer).
• Predictive back gesture handling.

Audio

• OpenSL ES via audio_driver_opensl.cpp is the default.
• Oboe-based driver may be selected for lower latency on supported devices.

Plugins

plugin/ defines a plugin system whereby .aar archives can register Java classes that the engine then exposes to scripting via Engine.get_singleton(plugin_name). This is how Google Play Billing, Admob, and various permission plugins integrate.

Export

export/export_plugin.cpp:

• Builds APK or AAB via embedded gradle invocations.
• Patches AndroidManifest.xml with permissions, screen orientations, app icons.
• Bundles per-architecture native libraries (arm64, armv7, x86_64, x86 — pick your subset).
• Aligns and signs via apksigner / bundletool.
• Supports asset packs for AAB-based distribution.

The editor APK lets users run the editor on tablets — useful for tablet-native level design workflows.

iOS

Layout

platform/ios/
├── godot_ios.mm                     UIApplicationMain + GodotApplicationDelegate
├── os_ios.{mm,h}                    OS_IOS subclass
├── display_server_ios.{mm,h}        UIWindow + Metal CAMetalLayer
├── ios.{mm,h}                       Bridge between iOS lifecycle and engine
├── godot_view.mm, godot_view_renderer.mm  CAEAGLLayer / CAMetalLayer view
├── joypad_apple.{mm,h}              GameController.framework joypad
├── plugin/                          iOS plugin host
├── export/                          IPA / Xcode project export
└── detect.py

Apple-embedded layer

Both iOS and visionOS share platform/apple_embedded/:

platform/apple_embedded/
├── godot_app_delegate.{mm,h}      Shared UIApplicationDelegate
├── godot_view.{mm,h}              Shared CAMetalLayer-hosting view
├── godot_view_gesture_recognizer.{mm,h}
├── apple_embedded.{mm,h}          Lifecycle bridge
├── api/                           Shared JS-bridge-like dispatch for plugins
├── ios.{mm,h}                     iOS-specific glue
└── visionos.{mm,h}                visionOS-specific glue

This shared layer means the iOS and visionOS platform directories are thin and inherit most behaviour from Apple Embedded.

Display server

DisplayServerIOS is a UIWindow + Metal renderer host. Highlights:

• Metal is the only supported render API on iOS now (OpenGL ES 3 is deprecated by Apple); Vulkan is supported via MoltenVK.
• Touches are routed through UIView::touchesBegan/Moved/Ended/Cancelled and translated into InputEventScreenTouch and InputEventScreenDrag.
• Tablet pencil input uses UIPencilInteraction and UITouchTypeStylus for pressure / tilt.
• Screen rotation and safe areas are surfaced through Window::get_safe_area.
• IME via UITextField invisible bridge.

Audio

• CoreAudio (drivers/coreaudio/) — same driver as macOS; audio session management is iOS-specific.

Export

export/export_plugin.cpp:

• Generates an Xcode project from a template.
• Bundles required frameworks, embedded fonts, splash screens.
• Configures entitlements (push notifications, in-app purchase, GameCenter, AR usage).
• Codesigns and packages as .ipa for App Store submission or ad-hoc distribution.
• Supports plugin .xcframework bundles for native code injection.

C# projects are AOT-compiled via dotnet publish -p:PublishAot=true to satisfy iOS's no-JIT requirement.

visionOS

Layout

platform/visionos/
├── godot_visionos.mm
├── os_visionos.{mm,h}
├── display_server_visionos.mm
├── joypad_apple.mm
├── export/
└── detect.py

visionOS is Apple's spatial computing platform. The integration:

• Uses RealityKit / ARKit alongside Metal for window placement in 3D space.
• Plugs into XRServer so apps can take advantage of head + hand tracking through OpenXR (when an OpenXR runtime is present) or via direct ARKit bridges.
• Reuses most of the Apple Embedded layer; visionOS-specific code is small.

The platform is comparatively young and will continue to evolve.

Common concerns across mobile

Concern	Approach
Small screen	Viewport content scaling modes (STRETCH_MODE_*, content scale factor)
Tile-based GPUs	Mobile rendering method (renderer_rd/forward_mobile/) avoids depth-prepass and minimizes load/store ops
Background suspension	OS subclasses raise NOTIFICATION_APPLICATION_PAUSED / _RESUMED; SceneTree propagates and the engine pauses audio / physics
Battery / thermal	OS::get_thermal_state (where supported), low-power audio backends, power saver mode integration on Android
Permissions	Android requires runtime permission requests; iOS uses Info.plist usage strings; both are handled by the export plugin and runtime helpers
In-app purchase / ads / push	Plugins (Java for Android, Swift/Obj-C for iOS) registered via the platform's plugin host

Entry points for modification

• Adding a Java / Kotlin singleton callable from GDScript → drop a class in platform/android/api/ (Java side) and bind via JNI in platform/android/api/.
• iOS plugin → write a .xcframework and ship a Plugin .gdip descriptor; register from platform/ios/plugin/.
• visionOS-specific features → platform/visionos/ and platform/apple_embedded/visionos.mm.