Platform Browser - Package Guidelines

Overview

When a team owning a platform configures a platform’s ‘platform browser entry’, they are able to include recommended packages to be added to the project automatically when the platform is added from the browser. This document is a set of guidelines as to what types of package can be included and what types of package must not be included, and what standards those packages must adhere to in order to be considered for inclusion.

What is the platform browser

The platform browser is a new window in Unity 6 that lets customers browse the platforms supported by Unity and add build profiles for these platforms. Adding build profiles from this window enables a workflow that ensures these profiles come configured with settings, packages and quality levels that make sure the onboarding process for platforms is as easy as possible.

What is a Platform Browser Entry

A platform browser entry is the item in the list of platforms in the platform browser. These entries can represent technology platforms (like windows) or partner platforms (like meta). These can be derived platforms, and may in the future include more types of platform.

Objective

Adding packages from the platform browser is a workflow designed to ease onboarding to new platforms and limit the instances in which a platform is added to a new or existing project, resulting in a build profile that cannot be built successfully without further configuration steps.

If the package is not in service of this goal it is typically not allowed to be added from this workflow. There are other areas of the unity ecosystem that support adding packages that serve other use cases, such as gameplay features, systems and services. These include;

• Package Manager
• Asset Store
• Multiplayer Center
• Hub

If you are unable to include a package as part of this workflow it may be better to include it as part of one of these projects instead.

What packages are allowed to be recommended

Generally any packages that are meant to help developers build or optimize for the platform in question are allowed, including packages for specific optional features or services the platform supports that may not have a corresponding abstraction within Unity itself.

What packages are not allowed to be recommended

Packages that expose features or services that are unrelated to distributing games or game related content to the platform in question, or that expose features and services that compete with the business interests of Unity.

To ensure a consistent and reliable experience for all developers on our platform, partners must adhere to the following guidelines when providing optional packages. The primary principle is to leverage and extend Unity's existing cross-platform frameworks rather than duplicating or replacing them.

Functionality and Integration

Partners should not develop optional packages that introduce cross-platform functionalities when Unity already provides a standardized solution. The goal is to avoid redundancy and developer confusion.

• Prohibited Implementations: You may not add packages that replicate functionality already supported by Unity's cross-platform solutions. For instance:
  • Do not introduce a custom leaderboard or user management system if a feature like Unity's Platform Toolkit already provides this.
  • Do not add a new method for hands input if a solution like the XR Hands package is already integrated within our ecosystem.
• Required Collaboration: If you wish to add support for a new industry standard (e.g., a new OpenXR EXT extension), you must collaborate directly with Unity's engineering teams. This ensures that the extension is integrated correctly and supported consistently across the platform.

Platform-Specific and Vendor-Specific Extensions

We recognize that some platforms offer unique features that may not be covered by Unity's existing cross-platform tools.

• Allowable Implementations: A package is permissible if it exposes unique, platform-specific features that are incompatible with or otherwise not addressed by our cross-platform offerings. For example, a vendor-specific OpenXR extension that provides functionality not available in Unity's standard implementation would be acceptable.
• Respect for Existing Abstractions: Even when developing platform-specific features, you must respect Unity's established abstractions. For example, since AR Foundation is Unity's primary cross-platform AR framework, we would not approve a package that surfaces AR features through a separate, proprietary API.

Examples

The following is a breakdown of types of packages and if they are generally allowed to be included in the platform browser as a recommended or mandatory package.

Standards for Partner Packages

All content distributed from partners to 3rd parties must adhere to our general package guidelines.

In addition, with the exception of any terms of service the partner has an exemption from as part of their partner agreement, all packages must be in compliance with our terms of service.

Release Criteria

Unity generally releases new major versions every couple of years, minor versions 3-4 times per year, and patch releases every 1-2 weeks.

Partner packages released within a generation must be compatible with all subsequent minor versions within the generation for as long as the platform is integrated into the Unity Editor. Partners are expected to test their packages with each new alpha and beta release to ensure major defects are addressed ahead of launch.

It is expected that partners address major issues in a timely manner as they come up through the support cycle.

Package compatibility may be limited to a particular generation of Unity as needed.

Package Updates

Partners can update their packages as needed on their own schedule with bug fixes, performance improvements, SDK / service compatibility updates and new features as long as they do not introduce a new integration surface area with Unity not already validated in the most recent minor version.

Any updates that add support for entirely new product or service offerings, or any additions that would materially change where and how Unity content is executed, must be aligned with a minor release version and validated with Unity.

Any updates that introduce breaking changes or upgrade friction for developers, must be aligned with a minor release version and validated with Unity.

3rd party packages shouldn’t be unduly deprecated (removed) during a Unity generation.