Application Modules

An application module is a homebrew title the console installs and launches from the home screen. Write it in C#, derive from ProsperoApp, override OnFrame, and call Run. The toolchain compiles it ahead of time to an eboot.bin, packs it with its sce_sys metadata, and produces an installable package — everything an installable title needs. See Payloads for the other executable form the toolchain builds.

What an application module is

An application module runs as its own process with a full lifecycle: install, launch, run, exit. The console’s own program loader binds every device-service import by name, sets up the module’s thread-local storage, registers the exception frames, and runs the global constructors before the entry point. That means an application module can reach the full device-service surface — graphics, input, audio, media, networking, memory, save data, dialogs, trophies, capture, package install, firmware compatibility — because the loader connects it to those services.

The pages under this section cover the API surface an application module builds against.

The API surface

Area	What it covers
Application host	ProsperoApp, the frame loop, timing, threading, diagnostics, and animation.
Graphics	The 2D drawing surface, images, fonts, 2D scenes, and the GPU command layer.
Input	The controller, motion and touch, rumble and light bar, keyboard, and mouse.
Audio	Output and microphone, decoding, encoding, filters, envelopes, synthesis, and mixing.
Media	Playing a media file, reading a track’s tags, and decoding video.
Networking	TCP and UDP sockets, a poller, an HTTP client and server, and downloads.
Memory	Direct and flexible memory, the managed heap, pooling, and an asset cache.
Interface toolkit	Building screens from labels, buttons, lists, and other controls.
Data and utilities	Files, numerics, buffers, text, XML, compression, and hashing.
System services	System info, dialogs, save data, trophies, capture, packages and devices, and firmware.
Modules and libraries	Loading a .prx at run time and building one.
Samples	Ready-to-build sample projects for each kind of application module.
Promoting an application	Asking a companion payload to lift the module’s credential, capability, and filesystem-view state past the per-title bounds.

The build path

The default build-app.ps1 invocation compiles, links, and packs an application module:

pwsh build/build-app.ps1 -ProjectPath MyGame/MyGame.csproj

• -Output Folder writes the loose eboot.bin, sce_sys, and any sce_module files into MyGame/out/module instead of a *.pkg.
• -TitleId <PPSAxxxxx> overrides the title id and the title portion of the content id, so a build can sit beside the last one on the console.

The three-step pipeline is documented in Build pipeline.

The lifecycle

An application module has a distinct install-launch-run-exit lifecycle. Between installs, the console re-applies the module’s sandbox before each launch: on every run the module is confined to /app0 (its own package files, read-only) and its writable per-title folder. A payload the user ran once does not persist across a launch, because launching a new process starts with a fresh sandbox. That is why promoting an application is a runtime call to a companion payload rather than a persistent setting — see Promoting an application.

---

Table of contents

• Application host
• Graphics
• Input
• Audio
• Media
• Networking
• Memory
• Interface toolkit
• Data and utilities
• System services
• Modules and libraries
• Samples
• Promoting an application