Expo Orbit: launching React Native builds and simulators from the menu bar

The repetitive loop it removes

Expo Orbit is described as accelerating your development workflow with one-click build launches and simulator management from the menu bar, and the feature highlights describe a specific set of tasks.

You can install and launch apps from local files using the file explorer, or by dragging a file into the app. Orbit supports any Android .apk, any iOS Simulator compatible .app on macOS, or ad hoc signed apps. Install and launch builds from EAS to your simulators and real devices in one click. Install updates on simulators and real Android devices in one click.

Then the simulator management side. You can list and launch simulators, including running Android emulators without audio, which matters more than it sounds when you are running several emulators at once and do not want them all playing the same sound. Launch Snack projects in your simulators in one click. And you can see pinned projects from your EAS dashboard and quickly launch your latest builds.

So the tool sits between two things that usually do not talk to each other well. The build artefact lives in EAS or on your disk, and the target is a simulator or a device that has to be picked, booted and installed to. Orbit is the adapter between them, and it lives in the menu bar so it is a click away rather than a command you have to remember.

That is a narrow problem, and the tool is narrow on purpose. It is not a build tool, it does not compile your code, and it does not replace EAS. It is the last mile of the loop: getting the artefact you already have onto the machine you want to run it on.

Downloads, Homebrew and the launch on login switch

Installation is a download for most people, with a package manager route on macOS.

You can download the latest version of Orbit for macOS, Linux and Windows from the releases page, and the readme links it as orbit/releases on the eas-menu-bar repository.

brew install expo-orbit

On macOS you can also install Orbit via Homebrew, and there is one setting worth knowing about straight away. If you want Orbit to automatically start when you log in, click on the Orbit icon in the menu bar or task bar, then select Settings and check the Launch on Login option.

That setting matters because of how the tool is used. Orbit is a resident menu bar utility, so if it does not start with the session you are opening the browser and the terminal to find the thing that saves you from opening the terminal.

The task bar wording is worth noting for Windows users, since the readme says menu bar or task bar rather than assuming macOS.

For developers who want to work on Orbit itself, the repository is a Yarn workspaces monorepo. The root package.json defines apps/* and packages/* as the workspace globs, and the scripts delegate to lerna.

    "build": "lerna run build",
    "lint": "lerna run lint",
    "watch": "lerna run watch --stream --parallel",

There is a postinstall step running patch-package, and a patches/ directory at the root, so upstream dependency patches are applied automatically on install rather than being applied by hand.

The engines field requires Node 20.0.0 or newer, the package manager is pinned to [email protected], and the resolutions block pins typescript to a tilde range of 6.0.3, which is the kind of control a monorepo needs to keep the build reproducible.

The release process has its own scripts, node scripts/release.mjs for the release and node scripts/release-metadata.mjs for the metadata, alongside an appcast.xml and an electron-updates.json, which are the manifests that drive automatic updates for an Electron application.

What the repository layout says about the product

The top level entries describe a desktop application with a supporting library layer, plus the automation around it.

There is an apps/ directory and a packages/ directory under the yarn workspaces, with a lerna.json coordinating them and a tsconfig.base.json plus a ts-declarations/ directory for the TypeScript setup. The primary language of the repository is listed as TypeScript.

There is a scripts/ directory holding the release tooling, a patches/ directory for patch-package, an eas.json for EAS configuration, an appcast.xml, an electron-updates.json, a releases.md, a CHANGELOG.md, and both CONTRIBUTING.md and CLAUDE.md at the root.

The presence of appcast.xml and electron-updates.json together is a clue about the update story. An appcast is the Sparkle format used by macOS applications for self-updating, and electron-updates.json is the manifest the Electron auto-updater reads. Shipping both suggests the update channel is handled natively on macOS and through the Electron updater elsewhere, rather than relying on one mechanism for all platforms.

The .prettierrc.js and the general shape of the tooling suggest a conventional JavaScript monorepo, with prettier for formatting, lerna for orchestration and per-package lint, build, watch and typecheck scripts. The watch script runs in parallel across packages with streaming output, which is the standard arrangement for a monorepo where several packages rebuild as you edit.

The .github directory holds the workflows and the banner resources used in the readme, which are split into a light and a dark variant so the readme header follows the reader's colour scheme.

None of this is unusual on its own. What it tells you is that Orbit is a real product with release automation rather than a script, and that the desktop shell is not the whole story, since there is a packages layer underneath it.

What Orbit does not do

The limitations here are mostly about scope and platform, and the readme is reasonably clear about the edges.

The first is that this is a React Native and Expo tool. Every feature listed is about builds, simulators, emulators, Snack and EAS. If you are building something else, an Android studio launcher would serve you and Orbit adds nothing.

The second is that iOS Simulator support is macOS only, stated as part of the support for iOS Simulator compatible .app files. The downloads cover macOS, Linux and Windows, but a meaningful subset of the features depends on the platform.

The third is that Orbit does not build anything. It installs and launches what already exists. The builds come from EAS, from your local files, or from Snack, and Orbit is the delivery step. If your pain point is that builds are slow, this is the wrong tool; if your pain point is that you are picking the wrong simulator for the fifth time this morning, it is exactly the right one.

The fourth is the drag and drop and ad hoc signing path. The support for ad hoc signed apps is useful for local development builds, but it also means Orbit can install things that are not from a store, so on a machine where the applications you install matter, it is worth being deliberate about what you point it at.

One thing the documentation does not describe is how Orbit behaves when it is talking to a device that is not reachable, or how it handles a build that fails to install. The readme does not cover failure modes or diagnostics, so expect to fall back on the Expo CLI for anything the menu bar cannot do.

Licence, cadence and who builds it

The licence position is clear and conventional. The Expo source code is made available under the MIT license, and the readme notes that some of the dependencies are licensed differently, with the BSD license as an example. That is the honest way to state it, because an Electron application pulls in a large tree and the licence of the whole bundle is not the licence of the source you can read.

The release cadence is steady. The listed releases are v2.7.0 on 2026-06-15, v2.8.0 on 2026-06-24 and v2.8.1 on 2026-08-17, with the last push on 2026-10-21. A jump from 2.7 to 2.8 within about ten days followed by a patch release, then a quieter period, is the shape of a tool that responds to platform changes rather than adding large features.

The changelog is at the repository root, so the details of what changed in each version are available before you upgrade.

Two final points about the project itself. The readme invites feedback and says the input will shape the future of the tool and guide where it is taken next, which is a statement about the project's direction rather than a commitment to a particular roadmap.

And it comes from the Expo team, which matters for a practical reason. The build, the Snack project and the EAS dashboard that Orbit talks to are all Expo services, so the integration is first party rather than a third party scraping an API. The cost of that is a tighter coupling to Expo's own model. If your pipeline uses EAS for builds and Snack for sharing, that coupling is exactly what you want. If you build with Gradle directly and deploy to the app stores yourself, Orbit still installs your local artefacts, but you are using maybe a third of what it does.

Editorial conclusion

Expo Orbit suits a React Native developer who ships through EAS and juggles simulators, emulators and physical devices, because it removes the repeated sequence of finding the right simulator, installing a build and waiting for it to boot. It does not suit a developer working only with the Expo Go client, since the value is in handling builds rather than projects, and it does not help anyone whose workflow is not React Native at all. Before adopting it, check that your platform is covered, since the iOS Simulator support is macOS only, and read the release notes for the version you install, because the release history shows a steady stream of version bumps through v2.8.1.

Frequently asked questions

Official sources

1. expo/orbit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases