# Ensemble: streaming Mac windows into visionOS, still in alpha

> Ensemble is a Swift project that brings macOS windows into a visionOS session so they can be moved, resized and interacted with like native apps, and the author is explicit that it is alpha software that may break under pressure. It is distributed through TestFlight rather than the App Store, and the README asks you to build it yourself if you want to change anything.

**saagarjha/Ensemble** — Cast Mac windows to visionOS

- Repository: https://github.com/saagarjha/Ensemble
- Website: https://testflight.apple.com/join/Pq1HzHqe
- Stars: 887 · Forks: 47
- Language: Swift
- License: AGPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/saagarjha-ensemble

## The point is to leave the flat plane behind

Ensemble bridges windows from your Mac directly into visionOS, letting you move, resize and interact with them just like you would with any other native app. That last phrase is the specification. The goal is not a remote desktop picture in a window, it is a Mac application window that behaves as though it belonged to the spatial environment around you.

The mechanism is described as wireless, and the comparison the project draws is with Mac Virtual Display, but without the limitations of resolution or working in a flat plane. Both of those limitations are the point. A virtual display gives you a rectangle of a screen, at a fixed resolution, which in a spatial environment means a flat rectangle floating in a room. Ensemble is described as wireless, so the Mac does not need to be physically attached to the headset, and the window contents are not bound to a screen-shaped rectangle.

The two verbs in the description, move and resize, are what separate this from screen sharing. A shared screen in a spatial environment is a plane. A window that can be moved and resized independently is an object with a position and a size, which is what a window in every other native application on the platform already has.

The project is written in Swift, the primary language on the project record, and the repository carries separate macOS and visionOS targets with a Shared directory between them, which is the structure you would expect for an application that ships on two platforms and shares a protocol layer between a Mac side that captures windows and a visionOS side that renders them.

The README is the whole of the public description, and it is short, which is itself a signal about the project's stage. There is no documentation site, no architecture write-up and no feature matrix, just the description of what the app does and a status paragraph about what state it is in.

## Alpha status, and the author tells you not to lean on it

The status section of the README is short and unusually direct. Ensemble is in alpha and not yet ready for daily use. If you would like to try it out, the easiest way to do so would be to join the TestFlight. However, there are a lot of things the author still needs to work on and it is likely that the app may break or crash if you push it too hard. Feel free to file bugs if you encounter anything that does not work as it should.

The last sentence has a parenthetical that says a lot about the project's maturity. The author notes that he is already tracking some limitations as issues. In other words, the known-broken behaviours are not hidden, they are in the issue tracker, and the expectation being set is that you will find them.

For an evaluation that is unusually usable information. Rather than inferring stability from a screenshot, you have the author telling you the failure model. And the distribution route matches the status. There is no App Store link, and the project home page is itself a TestFlight invitation link rather than a marketing site, which is the standard route for software that has not cleared review.

The release tags follow the same pattern. They are v25 with Build 25, v24 with Build 24 and v23 with Build 23, dated 2026-05-30, 2026-03-31 and 2026-01-01. A build number rather than a semantic version is what you would expect from a TestFlight-first project where the version only has to increase for the upload to be accepted, and it means the tags are not a compatibility contract in the way a semantic version would be.

The last push to the repository was on 2026-05-30 and the repository is not archived, so the work is continuing even though the tagged builds are a couple of months old relative to the present date.

## Building it yourself means Xcode and a signing configuration

There is no install command to copy, because this is a native Apple platform application, not a package. The documentation describes the route instead.

The app should be fairly straightforward to build yourself using Xcode, and it does not require any third-party dependencies, with some utility libraries pulled in using Swift Package Manager. So the build is a standard Xcode project with Swift Package Manager references rather than a dependency resolution step you might trip over.

The one thing you actually have to do is update the build settings with your signing information, and the documentation points at a specific file for it, the deployment xcconfig under the Configs directory. That directory in the repository listing, alongside Ensemble.xcodeproj, Release, Shared, macOS and visionOS, is the shape of the project: an Xcode project, a shared code directory used by both platform targets, separate macOS and visionOS application directories, a Configs directory holding the build configuration, and a Release directory.

The .xcconfig approach is worth a note. Putting the signing settings in a configuration file rather than in the project file means a contributor can point at their own team and provisioning profile without touching the shared project settings, and it keeps the identity out of a file that people would otherwise be tempted to commit with real credentials in it.

The Windows and Linux situation is the opposite of a cross platform project, and that is by design: the whole premise is that a Mac is driving the content and visionOS is displaying it, so the two Apple platforms are the only two that exist.

## Contributing is explicitly closed, for now

One sentence in the README decides who should and should not approach this project, and it is worth quoting in substance because it is unusual to see it stated so plainly.

It is unlikely that the author will take any code contributions at the moment, as the codebase is not really ready for them.

The reason given is about the state of the code rather than about the author's willingness, and the alternative is offered in the same paragraph. If you want to try out your own changes locally, or test a recent commit that is not in the release builds yet, that is there as an option. The expectation stated is that GitHub and TestFlight will not diverge too much, and the reason given is a CI pipeline that synchronizes them.

That pipeline detail is the practically important one. If you build from a commit that has not reached TestFlight, you are ahead of what users have, and if you build from a commit behind the current TestFlight build you are behind. The synchronisation pipeline means the two move together, which keeps a fork's divergence small.

So the sensible model of engagement is: run the TestFlight build, report what breaks, and if you want to change something, do it in your own fork and do not expect a merge. The MIT-style collaboration most GitHub projects advertise does not apply here, and that is a fact about the project rather than about the code.

The licence is AGPL-3.0, which the repository record lists, with a LICENSE file in the repository root. That matters more than usual for a project whose whole mechanism involves capturing and re-rendering one machine's windows on another device, because the AGPL is the licence chosen to require that modifications be shared when the software is used over a network.

## The name change is a trademark story, not a technical one

The README contains a parenthetical that explains the project's history better than a changelog would. Ensemble was formerly MacCast, before the lawyers had something to say about it.

That is the entire explanation, and it tells you two things. The first is that the project works, which is what prompted a name objection from someone else, and the second is that the objection was legal rather than technical, so renaming was a sufficient response and no functionality changed.

It also tells you something about the ecosystem this app sits in. A tool that bridges Mac windows into another Apple platform occupies a name that is close to what a company would want for its own casting product, and the author chose to rename rather than to fight. The current name, Ensemble, and the repository's new URL both reflect that decision.

For an adopter the practical consequence is minor but worth knowing: search for the old name and you will find the earlier project identity, and the TestFlight link in the current README is the entry point that matters.

There is also a demo video linked in the repository, hosted on YouTube, which for a project with this little documentation is the best available answer to what the thing actually looks like when it is working. The README also links a roadmap and an issue tracker for the limitations the author is already tracking, which for an alpha project is where the honest detail lives.

## Where Ensemble is the wrong choice

Three situations rule it out, and the project itself rules out the first two.

The first is daily work. The documentation says in alpha and not yet ready for daily use, and warns that the app may break or crash if you push it too hard. That is the author's own assessment, so there is little value in adding to it. A tool that bridges windows between two Apple devices is exactly the kind of software that has to survive long sessions, and an alpha build that might crash is a tool for an afternoon of exploration rather than for a working day.

The second is upstream contribution. If your reason for looking at the source is to fix something or add a feature, the README is explicit that the codebase is not ready for contributions. You can fork it and work locally, but the project will not take the change, and you should not plan around a merge.

The third is a non-Apple setup, and here the answer is structural rather than a matter of maturity. The repository has macOS and visionOS targets and nothing else, the premise is a Mac producing the windows, and the distribution is a TestFlight build for Apple platforms. There is no path from this codebase to a Windows or Linux workstation driving the display.

There is also a question the README does not address, and it is the one a prospective user should think about. The mechanism involves capturing window contents from one machine and rendering them in a spatial environment on another. What that implies about latency, about resolution, and about what happens when the source application changes size mid-interaction is exactly the kind of thing the documentation for an alpha project leaves open, and the Build 23 to Build 25 numbering suggests those details are still moving. The video is the honest way to judge that, and the issue tracker is where the honest complaints are.

## Conclusion

Ensemble fits a developer with both a Mac and a visionOS device who wants to use Mac applications in a spatial environment and is willing to run alpha software, because the alternative today is a virtual display that is limited by resolution and by working in a flat plane. It is the wrong choice if you need something stable for daily work, since the author says so himself, and it is the wrong choice if you intend to contribute upstream, since the README states that code contributions are unlikely at the moment because the codebase is not ready for them. Before you try it, join the TestFlight build, expect crashes, and if you build from source, set your signing information in the deployment xcconfig and be aware that a CI pipeline keeps GitHub and TestFlight in step.

## FAQ

### What does Ensemble do?

Ensemble bridges windows from your Mac directly into visionOS, letting you move, resize and interact with them as you would with any other native app. It is wireless, in the way Mac Virtual Display is, but without the limitations of resolution or of working in a flat plane.

### Is Ensemble ready for daily use?

No. The documentation states that Ensemble is in alpha and not yet ready for daily use, warns that the app may break or crash if you push it too hard, and notes that the author is already tracking some limitations as issues.

### How do I try Ensemble and how do I build it myself?

The easiest way to try it is to join the TestFlight. To build it yourself, use Xcode, where it needs no third-party dependencies beyond some utility libraries pulled in with Swift Package Manager, and set your signing information in the deployment xcconfig under the Configs directory.

### Can I contribute code to Ensemble?

Not at the moment. The documentation says it is unlikely the author will take any code contributions because the codebase is not really ready for them, though you can try changes locally or test a recent commit, and a CI pipeline keeps GitHub and TestFlight in step.

### Why was Ensemble renamed from MacCast?

The README puts it in a parenthetical: the project was formerly MacCast, before the lawyers had something to say about it. The rename was a trademark response rather than a technical change, and no functionality was affected.

## Sources

- [License: AGPL-3.0](https://github.com/saagarjha/Ensemble/blob/main/LICENSE)
- [Project website](https://testflight.apple.com/join/Pq1HzHqe)
- [README](https://github.com/saagarjha/Ensemble/blob/main/README.md)
- [Releases](https://github.com/saagarjha/Ensemble/releases)
- [saagarjha/Ensemble on GitHub](https://github.com/saagarjha/Ensemble)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/saagarjha-ensemble