# UniWindowController: a transparent, draggable Unity window > UniWindowController is a Unity library for Windows and macOS standalone builds that makes the application window transparent and borderless and accepts file and folder drops. It ships a prefab, a hit test that can follow the mouse through transparent areas, and a Windows-only colour key mode for natural touch input. **kirurobo/UniWindowController** — Makes your Unity window transparent and allows you to drop files - Repository: https://github.com/kirurobo/UniWindowController - Stars: 753 · Forks: 94 - Language: C# - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/kirurobo-uniwindowcontroller ## What the library controls in the Unity window UniWindowController is a library for apps built for Windows and macOS standalone with Unity. It controls transparency, borderless mode, position and size of its own window, and it also accepts file and folder drops. The project is abbreviated UniWinC, and the topics list drag-and-drop, file-dialog, macos, unity, unity3d-plugin, winapi and windows, which is the union of the two platform APIs it sits on top of. The design is deliberately not a code-level API. The usage instructions are scene setup steps. You add the UniWindowController prefab from Runtime/Prefabs to your scene, select it and watch the inspector, fix the Player Settings appropriately with the green button changing all settings at once, and adjust settings such as IsTransparent to your liking. There is a separate DragMoveCanvas prefab if you want the window moved by mouse dragging, and an EventSystem is required for that, added through the UI, Event System menu if it is not already in the scene. Then you build for PC or Mac standalone and launch it. That approach is the reason the library exists at all. A Unity window is a rectangle on the operating system's desktop, and making it look like a floating character or a chat bubble means doing Win32 and AppKit work that the Unity API does not expose. The library does that work and exposes it through the inspector, so a team gets a translucent frameless window without writing platform code. The C# side exists for scripts that need to change things at runtime, and the README is upfront that those specifications are not final and are subject to change. The main script exposes isTransparent, isTopmost, isZoomed, isHitTestEnabled, isClickThrough, windowPosition and windowSize, and a second script, UniWindowMoveHandler.cs, is attached to a UI element as the Raycast Target so that dragging that element moves the window. ## Installing through the Unity Package Manager or a unitypackage Two installation routes are documented, and the package manager route is the one the project steers you towards, noting that you can also perform version upgrades from it. For the Unity Package Manager route, you open Package Manager from the Window menu of the Unity Editor, select the plus button, and choose Add package from git URL. The URL to enter is the repository with the upm branch suffix. ```bash https://github.com/kirurobo/UniWindowController.git#upm ``` The #upm suffix is what tells Unity which branch to treat as a package, and it is why the repository has a default branch of main and a separate packaging branch. Version upgrades then come through the same Package Manager panel rather than by re-importing an archive. The alternative is the unitypackage route. You download an .unitypackage file from the Release page and import the asset in the Unity Editor, which is the familiar approach for a project that is not yet set up for git-based package management. The releases are versioned, and the recent ones are v0.9.8 from November 2025, v0.9.7 from July 2025 and v0.9.6 from February 2025. The 0.x line is the signal that the API is still moving, which matches the README's own warning that the C# scripting specifications are not final. There is a sample to look at. The demo is a VRM viewer built on this library, published as the separate UniWinC_VRM project, which is the fastest way to see the window behaving as intended before wiring it into your own scene. ## The hit test, and why transparent windows need one The hit test section explains the problem that a transparent window creates, and the explanation is the best argument for using this library rather than rolling your own. When the window is successfully made transparent, it looks as if it were a non-rectangular window. However, this is only an appearance, and the window actually exists as a rectangular window. Therefore, if you look directly under the mouse cursor and the window is transparent there, the mouse operation is passed to the window below, a click-through. If the area is opaque, the mouse operation returns to normal. Two hit test methods are available, and you can also disable the automatic hit test and control it yourself. The Opacity method checks transparency. It matches the appearance and is natural, but the processing is heavy. The Raycast method checks a collider. It is lightweight, but it requires colliders. The Raycast method is recommended in terms of performance, but if you forget the collider you will not be able to touch the screen, so the default is Opacity. That default is a sensible trade: correct behaviour at the cost of CPU, with the cheaper path available to a project that has already put colliders on its UI. The README also flags a consequence of the whole approach, that touch operation may feel uncomfortable because you cannot see the colour under your finger in advance. The author says the best solution has not been found and that touch support has been put on the back burner. ## The Windows colour key mode for touch input The transparency method section is marked as selectable only on Windows, and it exists for one reason, to make touch input feel right. One way to support touch operation is to select monochromatic transparency for layered windows. If this is selected, semi-transparency cannot be expressed and performance will be reduced, but since the hit test is left to Windows, it should match your senses for touch operation. The two options are Alpha, which reflects the transparency of the rendering results and is described as standard, and ColorKey, where only one colour with a matching RGB value is transparent, which has poor performance but makes touch natural. The Windows specific detail is that changing TransparentType from Alpha to ColorKey loses the translucency but makes the touch operation natural, and the alternative on the table is that you keep Alpha and accept that touch feels wrong. So on Windows you are choosing between looking good and feeling good, and the same choice is not available on macOS. That is a real trade in the library's design, and it is worth understanding before you ship, because the polished look and the usable touch input are in direct conflict on the platform where touch matters most for a desktop app with a transparent window. ## Limitations, URP settings and the platform requirements The limitations section is the most useful part of the README for anyone evaluating this, and it starts with the graphics API. Background transparency is not enabled in Direct3D12. In Direct3D11 it can be enabled by disabling the Use DXGI flip model swapchain for D3D11 setting, which is the usual cost of a per-pixel transparent window on that API. Transparency is not available in the Unity Editor, so you have to build and try it. The README says it works for topmost and moving windows in the editor, but that closing the game view or changing the docking arrangement while it is running is not recommended, and the window will reacquire when focus shifts back to the game view. That is a limitation of the approach rather than a bug, since the editor's own window handling is not what the library controls. The proper support for touch operations has not been determined, which is the point the colour key mode addresses. Multiple windows are not supported. And the README says plainly that this has not been fully tested and there may be unstable behaviour. The URP section is a short checklist for the render pipeline, and it is the kind of detail that costs an afternoon if you do not have it. To make the background transparent the alpha channel must be maintained, and there are conditions for that. HDR must be disabled, in the Main Camera's Camera component under Output. And AlphaProcessing must be enabled. On system requirements, Unity 2019 4.31f1 or later with the .NET 4.x scripting runtime or later, and Windows 10, Windows 11 or macOS. The development environment is stated as Unity 2022.3.22f1 on Windows 11 and macOS 15.3, which tells you the current work happens on recent Unity and recent macOS, so the older versions are the supported floor rather than the tested configuration. ## Where UniWindowController is the wrong choice The first limitation is the one the README lists plainly, that multiple windows are not supported. A Unity application that opens a settings window or a separate utility on top of its main window is outside this library entirely, and there is no partial support described. The second is the graphics API. No transparency on Direct3D12, and on Direct3D11 it costs you the DXGI flip model, which has its own consequences for rendering behaviour. A project targeting Direct3D12 as its default pipeline, which is increasingly the default for new Unity projects, has to change the pipeline or go without a transparent background. The third is that the feature is standalone-only. The editor cannot show it, so every visual iteration on the window's look requires a build and a launch. That is a slow loop compared with tuning a material in the editor, and it is a structural cost of the approach rather than something that can be configured away. The fourth is the API stability. The C# scripting specifications are not final and are subject to change, the package is on a 0.x version line, and the documented properties are a subset of what may be added. Code that drives the window from gameplay logic has to expect to be revisited. The fifth is the touch situation, and it is worse on macOS. The colour key workaround is Windows only, the author says touch support has been put on the back burner, and the hit test by opacity is heavy. A Unity desktop app that is primarily used by touch input on a Mac is a poor fit, and the honest version of the assessment is that the library was designed for mouse-driven applications with an optional touch gesture. The last is platform coverage. Windows and macOS only, with the Win32 and AppKit implementations and no Linux entry, which is a limit for a project with Linux users. ## Licence, maintenance and the cost of a platform shim The project is under the MIT licence, with the LICENSE.txt file at the root of the repository, and the README carries a licence badge. It is also offered through the GMO project, with a badge for that, which is worth noting because the GMO project is about distributing software freely and the badge suggests the author cares about the licensing terms being explicit. The repository is not archived and the last push was on 2026-05-11, so the code is being worked on, though the release history is slower, with the most recent release v0.9.8 dated 2025-11-17. That is a normal pattern for a Unity plugin, where the package lives in a user's project and changes rarely need a new release. The repository layout is small and tells you what is in the package. The UniWinC/ directory holds the plugin itself, the docs/ directory holds documentation, and there are VisualStudio/ and Xcode/ directories, which are the native project files for the two platforms. The VisualStudio and Xcode directories are the interesting part, because they are where the Win32 and AppKit code lives, and they are what a maintainer has to keep in step with each Unity version. The cost of a platform shim like this is the maintenance tail. A Unity plugin that reaches into the windowing system has to keep working across Unity releases, since Unity's own window handling and the render pipeline settings it depends on change, and it has to keep working across Windows and macOS releases, where the API surfaces differ. The URP section in the README is a good example of that: the alpha channel requirement is a consequence of how the pipeline is configured, and it has to be re-checked when Unity changes the defaults. What you get in exchange is a window that behaves the way a desktop app should, without a team writing platform code for a feature that every serious Unity desktop project ends up needing. ## Conclusion UniWindowController suits a Unity team shipping a desktop app that needs a frameless translucent window, a custom title bar or drag and drop of files, since the prefab and inspector approach avoids writing Win32 and Cocoa code. It does not suit a project that needs multiple windows, direct3D12 transparency or editor-time transparency. Build a standalone target before judging it, because the README is explicit that transparency is unavailable in the Unity Editor. ## FAQ ### How do I install UniWindowController in a Unity project? Add it through the Unity Package Manager by opening Package Manager from the Window menu, selecting the plus button and choosing Add package from git URL, then entering the repository URL with the #upm branch suffix. Alternatively, download an .unitypackage from the Release page and import it in the editor. ### Why does a transparent UniWindowController window need a hit test? The window is still a rectangle on the desktop, so a click over a transparent area would be received by the window instead of passing to whatever is behind it. The Opacity method checks transparency to match what you see but is heavy, while the Raycast method checks a collider, is lightweight, and needs colliders to be present. ### Does UniWindowController work in the Unity Editor? Transparency does not. The README says you have to build and try it, and that while topmost and moving windows work in the editor, closing the game view or changing the docking arrangement while it is running is not recommended, with the window reacquiring when focus returns. ### What are the system requirements for UniWindowController? Unity 2019 4.31f1 or later with the .NET 4.x scripting runtime or later, running on Windows 10, Windows 11 or macOS. The development environment is Unity 2022.3.22f1 on Windows 11 and macOS 15.3. ## Sources - [Issues](https://github.com/kirurobo/UniWindowController/issues) - [kirurobo/UniWindowController on GitHub](https://github.com/kirurobo/UniWindowController) - [License: MIT](https://github.com/kirurobo/UniWindowController/blob/main/LICENSE) - [README](https://github.com/kirurobo/UniWindowController/blob/main/README.md) - [Releases](https://github.com/kirurobo/UniWindowController/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kirurobo-uniwindowcontroller