Mobile Platform Support

Glyx is currently focused on desktop (Windows, macOS, Linux), but mobile platforms are on the roadmap.

Status: Research phase for mobile packaging/runner itself. One real prerequisite has shipped since this page was written: the QuickJS JsRuntime backend (binary size ~3x smaller than V8, no JIT dependency) is stable and selectable today via glyx.config's engine field — see JS Engine Selection. Mobile packaging and a mobile runner are still not started.

Motivation

Mobile support would let you share code across desktop and mobile from a single React codebase. The architecture already shares similarities with React Native — custom reconciler, native element tree, platform-specific rendering — making mobile a natural extension.

Technical approach

The rendering pipeline would target a new backend per platform:

The runner model (see Runner Model) would gain a mobile runner that handles platform lifecycle (suspend/resume, back button, touch input). The capability system (see Capability System) already abstracts platform details, so most capabilities would work with a mobile implementation behind the same interface.

What this means for your code

Components and logic written for desktop should port to mobile with minimal changes:

function ShareButton() {
  // Works on desktop. Would also work on mobile with a mobile dialog implementation.
  const handlePress = async () => {
    const file = await fs.readFile('report.pdf')
    // mobile: shares via OS share sheet
    // desktop: shows save dialog
  }
 
  return (
    <Pressable testID="share-button" onPress={handlePress}>
      <Text>Share</Text>
    </Pressable>
  )
}

Limitations on mobile

• No GPU canvas (3D) — WebGPU/Vulkan compute is not available on all mobile devices. Canvas 3D would require a fallback.
• No arbitrary native extensions — Mobile app stores sandbox extensions. Only capabilities included in the runner would be available.
• Larger binary — Device coverage requires bundling multiple GPU backends.

Timeline