Platform Support

Hosanna has first-class HST targets for Roku, Apple TV, Android TV, iOS, Android, and Web. The same Web output can also be packaged by an app-owned Samsung/Tizen host. The framework keeps application code focused on views, state, focus, input, AppConfig, networking, and tooling while each platform boundary handles rendering, packaging, and device integration.

Supported Targets

Platform	Primary runtime	Main validation path
Roku	BrightScript and SceneGraph	hst run roku dev device, Roku sideload, device logs, MCP debugger
Apple TV	Native Apple target	hst run apple-tv dev sim/device, focus/input validation, Xcode for signing/profiling
Android TV	Native Android target	hst run android-tv dev sim/device, DPAD validation, Android Studio for signing/profiling
Samsung TV	App-owned Tizen host around compatible Web output	Browser validation, Samsung packaging tools, device validation
iOS	Native mobile target	hst run ios dev sim/device, touch validation, Xcode for signing/profiling
Android	Native mobile target	hst run android dev sim/device, touch validation, Android Studio for signing/profiling
Web	Browser runtime	hst run web dev browser, Vite, DevTools, MCP debugger

Shared App Model

Most product code should stay platform-neutral:

• Define screens with Hosanna views and view state.
• Use AppConfig for styles, fragments, callbacks, and shared app metadata.
• Route remote, keyboard, pointer, and touch input through onInputEvent and the focus system.
• Use the active expression (tv, web, phone, or tablet) for layout intent, and use platform capabilities for feature availability.
• Read design size, DPI, safe areas, and host viewport values from the device facade instead of direct browser or native checks.
• Keep platform-specific code behind hst run/hst build target selection, aliases, build flags, native adapters, and packaging scripts.
• Validate common behavior in Web first, then finish each release on the target devices.

For the shared runtime vocabulary, config variant selection, device metrics, orientation callbacks, and capability groups, see Cross-Platform Runtime Model.

Platform-Specific Work

Each platform page documents the parts that differ: setup, packaging, store requirements, native services, input behavior, media playback, and debugging. Keep shared UX behavior in the core docs and use platform pages for target-specific decisions.

Start with Platform-Specific Code, Running On Device, and the page for your release target.