House Control, a 3D floor plan in the macOS menu bar

A menu bar app with no window and no Dock icon

House Control by 0xProbabillity is a native macOS and iOS application that presents your home as a live 3D model. The Mac app lives entirely in the menu bar: click the house icon and a panel drops down, click anywhere else and it disappears. There is no Dock icon and no main window, so finding it for the first time can be confusing, which is why the project documentation spends a line on exactly that.

The visual idea is the differentiator. Rooms, walls, doors, windows and furniture are built from a single JSON file, and the 3D scene is not decorative. Lamps light the scene the way they light the room, and an air conditioner that is running blows visible air in the model. So the 3D view is the primary control surface, not a preview of something happening in a separate app.

Interaction is designed around the display. Tap toggles a light, dragging across a tile dims, and opening a light gives you brightness, white temperature and colour. Air conditioners expose power, target temperature, mode and fan speed, and the room temperature shown comes from a real sensor if one is available. Scenes apply a whole configuration in one tap, and the project ships named presets such as Cozy, Movie and Night alongside the option to define your own.

The audience is a person who already owns smart lights and air conditioners and is annoyed by having four different vendor apps on their phone. The app is a renderer and a controller, not a hub.

One Three.js UI inside a Swift shell, shared as a package

The architecture is stated plainly in the project documentation and it is the most interesting technical decision in the repository. Both apps are a small native Swift shell, AppKit on the Mac and SwiftUI on the iPhone, around one Three.js web UI, and they share their device clients and sync as a Swift package. The documentation adds the constraints: no frameworks, no Electron, no server, and no account of its own.

That last point has a direct consequence for a user. There is no backend to sign up for, which means no company holds a copy of your floor plan or your device credentials, and it also means the credentials live on your devices. The trade is that nothing is synchronized through a third party, and the local data has a path on disk that you can delete, which the documentation does spell out.

The repository layout matches that design. There are macos/ and ios/ directories for the two native shells, a web/ directory for the shared Three.js interface, a core/ directory that holds the device clients and sync logic, widgets/ for the Home Screen and Lock Screen widgets, scripts/ for the build automation, tools/ and docs/ for supporting material, and .github/ for the release workflow.

The Three.js choice is the main trade in the design. It gives one implementation of the 3D scene for two platforms and a browser-grade rendering pipeline, at the cost of running a web view inside a native app. A pure SwiftUI scene would be more native in feel, and the shell is small enough that the web view is most of the app.

Four device ecosystems mixed in one home

The bridge story is where the project differentiates itself from a single-vendor app. The documentation lists Smart Life and Tuya, Home Assistant along with the many brands it runs, Philips Hue, and Apple Home, and states they can be mixed freely in one home. A house with Hue bulbs in the living room, a Tuya air conditioner in the bedroom and a Home Assistant instance in the hallway is the case the project is designed around.

Underneath, the per-ecosystem clients live in the shared core/ package, so a lamp from one ecosystem and an air conditioner from another sit in the same floor plan and respond to the same scene. Scenes are the mechanism that makes this useful: one tap sets every light and air conditioner, regardless of which system each device belongs to, which is exactly the operation that is painful with four separate vendor apps.

The iPhone app is a full participant rather than a remote control. You can draw the home, connect the four ecosystems and link the devices entirely on the phone, and pairing a Mac later keeps both in sync, whichever one you edit. The Mac additionally has the notch island, where resting the pointer on a MacBook's notch drops out a small live model of the home with scenes and every device one click away, and the widget layer puts the 3D home on the iPhone Home Screen and the Mac desktop with Lock Screen and Control Center controls.

For a developer, there is also an AI Access path. The documentation describes giving an assistant such as ChatGPT or Claude a private link, or connecting it over MCP, so that it runs lights and air conditioners and rebuilds rooms in the 3D model from your photos, served by your Mac, with a Stop control. That is a notable exposure decision for a home network, and it is the part of the feature set to read the documentation on before enabling.

Building from source because the app is not notarized

The distribution story is unusual and deliberate. House Control ships signed ad hoc rather than notarized, and the documentation explains why: notarizing needs an Apple Developer ID, and that certificate carries a person's legal name inside every copy of the app. The project's answer is that the code is public, the release is built in public, and you can build it yourself in a couple of minutes.

The requirements table sets the floor. macOS 13 Ventura or newer, Xcode Command Line Tools with Swift 5.9 or newer, and Node.js 20.19 or 22.12 or newer. For the iPhone app you additionally need Xcode 16 or newer, XcodeGen installed with `brew install xcodegen`, and iOS 17 or newer.

The build itself is three commands.

git clone https://github.com/0xProbabillity/house-control.git
cd house-control
./scripts/build-app.sh
open build/HouseControl.app

The script builds the web UI with Vite, the native shell with SwiftPM, and assembles an ad-hoc signed `build/HouseControl.app`. The first build downloads the npm packages and later builds take a few seconds, according to the documentation. There is also a documented escape hatch for developers who rebuild often and use iPhone sync: signing with your own certificate, `CODESIGN_IDENTITY="Apple Development: [email protected] (ABCDE12345)" ./scripts/build-app.sh`, so that macOS does not ask for the Local Network permission after every build.

Building yourself is therefore not a fallback, it is the primary path for anyone who cares about the signing story. Dragging `build/HouseControl.app` into Applications installs it, and Open at Login in the menu bar icon's right-click menu makes it start with the Mac.

The unsigned download and how to check what you got

Installing the release build is a different experience from building it, and the documentation is unusually direct about the friction. You fetch `HouseControl-<version>.dmg` from Releases, and it runs on macOS 13 or newer on both Apple silicon and Intel. Dragging it into Applications is step two. Step three is the part that trips people up: the first launch, macOS stops the app because it is not signed with a paid Apple Developer ID, showing a message that Apple could not verify the app.

The documented ways past it differ by macOS version. On macOS 15 Sequoia and newer you click Done, open System Settings, go to Privacy and Security, scroll to the blocked message and choose Open Anyway, then confirm with your password. On macOS 13 and 14 you control-click the app in Applications, choose Open, and choose Open again. There is also a Terminal option, `xattr -dr com.apple.quarantine "/Applications/House Control.app"`.

What makes this acceptable rather than alarming is the verification story, which the project spells out. Every release image is built by GitHub Actions from the tagged commit rather than on someone's Mac, and it ships with a SHA-256 and a signed build provenance attestation, which you check with two commands.

shasum -a 256 -c HouseControl-<version>.dmg.sha256
gh attestation verify HouseControl-<version>.dmg --repo 0xProbabillity/house-control

The second command proves the image was built by that repository's workflow and shows from which commit. The documentation is careful about the exception: images from 1.0.0 on carry an attestation, while 0.1.0 was built while the repository was still private, when GitHub does not store attestations for free accounts, so for that one only the SHA-256 can be checked.

The app starts with a bundled demo plan, so you can try every feature before connecting anything, and every device is simulated until you sign in to a real ecosystem. Removing it later means quitting from the menu bar icon, deleting the app, and removing `~/Library/Application Support/HouseControl/` if you also want the plan and connections gone.

The visual editor is where the effort goes

Everything about the app presumes a floor plan, and the project provides a visual editor to produce one: draw the rooms, drop in furniture, place lamps and air conditioners, and link each one to a real device. The rooms, walls, doors, windows and furniture all come from one JSON file, which is a sensible design for a project that has to describe a physical space to software.

That single source has a side effect worth naming. Because the model is a JSON document, the editing experience is not the only way to produce one, and a hand-written file is possible for anyone who prefers to describe a flat rather than draw it. The documentation does not document the JSON schema in detail, so that route is a matter of reading the file the app writes rather than a supported import path, and it is worth confirming the structure before planning around it.

The editor is also where the real time cost sits for a new user. Laying out a flat accurately enough that the 3D model is useful, placing each lamp and air conditioner, and then linking each placed object to the right device in the right ecosystem is a multi-hour task for anything larger than a studio apartment. None of that is a defect, since the fidelity of the model is the entire point of the product, but it means the value of the app arrives after setup rather than at first launch.

Once the plan exists, the payoff is the part that is genuinely hard to get elsewhere: a single screen where the state of every light and air conditioner in the house is visible at once, with scenes that span ecosystems.

Version 1.0.0, MIT licensed, and a young release history

The release history is short. Version 0.1.0 shipped on 2026-10-14 and 1.0.0 on 2026-10-15, so the project reached its first stable label within a day of each other, and the last push to the repository was on 2026-10-16. The changelog at CHANGELOG.md is where the project documents what changed in each release.

What that dates mean for an adopter is that this is a young project with a young public history. The 0.1.0 image, as noted, was built while the repository was private and carries no attestation, so the first release with a build attestation is 1.0.0. Expect the interface and the JSON plan format to move, and expect documentation to lag behind features, since the visible documentation here is a summary with the deeper detail in the docs/ directory.

The licence is MIT. You can use, modify and redistribute it, including commercially, provided you keep the copyright notice and the licence text with it. There is no copyleft obligation that would reach your own code, and the fact that the app is ad hoc signed rather than distributed through the Mac App Store means there is no sandboxing or signing review standing between the source and the binary you run.

The removal path is unusually complete for a project this small, and it is worth noting for anyone evaluating it on a machine that also does other things. The plan and the stored connections live under `~/Library/Application Support/HouseControl/`, so a full uninstall is the app in Applications plus that directory, and the app has no server component and no account, so there is nothing remote to revoke.

Editorial conclusion

House Control suits a smart home owner on macOS who already runs Home Assistant, Hue, Smart Life or Apple Home and wants a single visual surface for lights and air conditioners, especially anyone willing to build the app from source and sign it with their own certificate. It does not suit a household that needs a signed and notarized app without doing that work, nor a Linux or Windows user, since only the macOS and iOS apps exist. Verify first that your devices are reachable through one of the four supported ecosystems, that the floor plan JSON you author matches the physical layout closely enough for a 3D model to be useful, and that the ad hoc signing path on your machine behaves as the documentation describes before you connect a real hub.

Frequently asked questions

Official sources

1. 0xProbabillity/house-control on GitHub
2. Issues
3. License: MIT
4. README
5. Releases