Unity Screen Navigator gives uGUI pages, modals and sheets a history model

Page, Modal and Sheet have different history rules

The library's central idea is a classification. Unity Screen Navigator classifies screens into three types, Page, Modal and Sheet, and the difference between them is not visual, it is behavioural.

A Page is a screen that transitions in sequence. When you move from Page A to Page B, Page A is stacked in the history, and when you return from Page B, Page A is redisplayed with its states intact. That last clause is the whole point of the history stack, and it is the behaviour most navigation systems get wrong or approximate.

A Modal is a screen that is stacked in a window. When it is displayed, all interactions except for the foreground modal are blocked, so it sits above the content rather than replacing it, and the content underneath keeps its state because it was never unloaded.

A Sheet is used for tab-like GUI. History is not managed for it, and only one active screen is displayed. That is the right model for a tab bar, where the previous tab is not a step you return to but a peer you switch from.

The feature list adds tabs alongside pages and modals, and mentions the standard features such as history stacking and click prevention during transitions. The interaction rule is what makes a modal feel like a modal, and it is enforced by the library rather than left to the developer to remember for every screen.

Lifecycle management is the part most teams build badly

The second bullet of the feature list is that you can manage screen lifecycle and memory from load to destroy. That is a bigger claim than it sounds.

In a uGUI application, a screen is usually a prefab instantiated into a container, and the moment it is pushed onto a history stack it has an addressable or a Resources reference, a canvas, event handlers, and possibly a coroutine or two running. Teams that build navigation themselves typically leak those objects, or they destroy and rebuild screens so eagerly that state is lost, or they keep a history array of booleans and hope it matches what is on screen.

The library's own answer is that the screen lifecycle is a first class object with events, and the table of contents shows lifecycle events documented separately for the page, the modal and the sheet. Three separate sets, because the three screen types genuinely have different lifecycles: a page in the history is alive but not active, a modal is alive and blocking, a sheet is swapped out.

The other lifecycle decision in the table of contents is telling: a section titled use async methods instead of coroutines. That is a deliberate choice about the calling convention, and it changes how a screen transition is awaited. The documentation also covers how to wait for a transition, and how to get containers with static methods, which is the part of the API that has to be pleasant if the library is to be adopted at all, since the container is what you call to push a screen.

Transition animation is a separate animator workflow

Complex transition animations are the reason many teams give up on a navigation library, and the design choice here is to keep them out of the core.

The feature list describes a separated workflow with animators for complex screen transition animations, and the table of contents shows how deep that goes. You can set common transition animations for all screens, set a transition animation for each screen, and change the transition animation according to the partner screen, which is the case where the same screen animates differently depending on where it came from.

There is also a section on screen transition animation and drawing order, because a transition that animates two screens at once has a z-order problem, and one on implementing interactive animation with partner screen, where the animation is not a fixed clip but reacts to the other screen's state. A section on creating animation with Timeline covers the case where the motion is authored in the Timeline tool rather than in code.

The reason to separate this is that most of the work in a navigation library is bookkeeping, and animation is the part that is specific to a project. The library's own summary claims a well-separated library with no extra functions, explicitly excluding a GUI library and a state machine, and the animator split is the same idea applied to animation.

For a team that wants transitions to feel designed rather than default, the list of supported cases here is long enough to build a real transition system on top of, rather than the two or three presets that most navigation packages provide.

Resource loading is pluggable, and Addressables is the intended path

The table of contents has a section on loading screen resources with four sub-topics, and that is a bigger design surface than it first appears.

Screens in a uGUI app are prefabs, and prefabs come from somewhere. The library lets you change the loading method of screen resources, use the Addressable Asset System for the loading, load synchronously, and preload. Those four are the choices between a bundle system, an addressable system, a blocking load and a warm up front.

Preloading deserves particular attention, because it is the difference between a transition that stutters and one that does not. If the next screen's prefab is still being loaded when the user taps, the transition either waits or plays over a hole. Both look bad, and the first is a frame rate problem while the second is a visual one.

The Addressable path is the one that scales, since it lets the library request assets through the addressable system rather than loading everything into memory at start-up. The synchronous option is for a small project where the whole screen set fits in memory and simplicity beats everything, and the fact that it is offered at all is a reasonable sign that the library is not trying to impose one opinion.

Other features in the same area, from the table of contents, cover popping multiple screens at once, not stacking pages in history, changing the backdrop of modals, closing the active modal when the backdrop is clicked, enabling interaction during transitions, disabling masking for a container, and using already loaded prefab instances when loading screens.

Install it as a git package, in three ways

Installation is through the Unity Package Manager, and the README gives two routes.

In the editor, open the Package Manager from Window > Package Manager, use the + button and choose Add package from git URL, then enter:

https://github.com/Haruma-K/UnityScreenNavigator.git?path=/Assets/UnityScreenNavigator

Alternatively, add the dependency to Packages/manifest.json:

{
    "dependencies": {
        "com.harumak.unityscreennavigator": "https://github.com/Haruma-K/UnityScreenNavigator.git?path=/Assets/UnityScreenNavigator"
    }
}

And if you want to pin a version, append a tag to the URL, with the example given being #1.0.0.

Two details in those instructions are worth noticing. The path query parameter points at a subdirectory of the repository, which is how a package embedded in an Assets folder can be consumed as a package, and the package name is com.harumak.unityscreennavigator, which is the identifier to use in the manifest rather than the repository name.

The requirements are short and they are the first thing to check. Unity 6, that is 6000.0 or higher, and uGUI, with UIElements not supported. That second point is the boundary of the library: it is built on the older uGUI system, and a project that has moved to Unity's UI Toolkit will not find what it needs here.

The demo is the fastest way to see the three screen types behave. You clone the repository, open the DemoEntryPoint.unity scene under Assets/Demo/Core, and play it.

The FAQ answers point at the hard questions

The FAQ section of the README is short, and its four questions are the ones that decide whether a navigation library fits.

How to make each Screen with Scene instead of Prefab answers the deployment question. A prefab based screen lives inside the one scene and is instantiated into a container, which keeps the screen graph simple and the state alive. A scene based screen means scene management, with a scene load per screen and different lifecycle consequences, and the library supports it because teams do want it.

How to separate view and logic is the architectural question. The library's own philosophy leans towards keeping the screen component as the view, with the navigation calls made from outside it, and the answer in the documentation spells out the recommended split.

How to pass data to each screen is the one every navigation library has an opinion about, and the answer here is the pattern to copy for your own code.

How to reuse popped pages or modals is the question that connects back to the history model. A popped page is normally destroyed, and if your flow needs it again, you either keep it alive or rebuild it, and the answer describes the mechanisms for both.

A repository that answers these four questions directly, rather than leaving them to a wiki, is a repository whose author has used the library in production. That is worth more than any feature list, and it is also the reason the FAQ is the first section to read.

Maintenance, licence and the scale at which this pays off

The project is MIT licensed, with the LICENSE.md file at the root, and there is a Japanese version of the documentation in README_JA.md, which is a useful signal about who the library is for.

The release history is small and deliberate. The published versions are v1.8.0 on 2026-08-18, v1.7.5 in May 2025 and v1.7.4 a few days before that, and the repository is not archived with the last push on 2026-08-18, the same day as the 1.8.0 tag. So the current release is also the current state of the code, which is a good sign for a library that is tied to a specific Unity version.

The limit on the project is its scope, and the author states it plainly in the feature list: a well-separated library with no extra functions, explicitly not a GUI library and not a state machine. The top level of the repository matches that, with Assets/, Packages/, ProjectSettings/ and the READMEs, and the .claude/, .codex/ and .uloop/ directories, which are the working files for automated agents on the project.

So the honest summary is that this is a focused navigation layer, not a UI framework, and its value is concentrated where uGUI applications usually go wrong: history, lifecycle, input blocking during transitions, and the ordering of an animated transition. A project with a dozen screens and a simple flow will not notice it. A project with a deep navigation stack, modals over pages, and screens that must release their memory when they leave will notice it immediately, and the lifecycle events and the pop-multiple-screens feature are the parts that pay for the adoption.

Editorial conclusion

Unity Screen Navigator suits a Unity team building a uGUI application with a real navigation structure, where screens need to stack, block input, animate in and out and release their memory at the right moment, and where the team wants that behaviour without adopting a UI framework or a state machine. It does not suit a project on UI Toolkit, since the library states UIElements is not supported, and it is the wrong choice for a small app with three screens. Verify first that your Unity version is 6 or newer, and read the FAQ entries on reusing popped pages and on building screens as scenes rather than prefabs, because those two answers determine how much of your screen content survives a back navigation.

Frequently asked questions

Official sources

1. Haruma-K/UnityScreenNavigator on GitHub
2. Issues
3. License: MIT
4. README
5. Releases