Control Room wraps simctl in a SwiftUI app for Mac developers

Every Control Room action goes through Apple's simctl

Control Room is a macOS app that sits on top of Apple's simctl command-line tool. It wraps that tool, so simctl has to be present on the machine before the app can do anything useful. The dependency is stated plainly: Xcode has to be installed and the simctl command has to be there. When the command is missing you get an error about the command line tools, and the fix lives in Xcode's own Preferences window, on the Locations tab, where Xcode itself must be selected for Command Line Tools. What you end up controlling spans simulators for iOS, tvOS, and watchOS, covering their UI appearance and status bar configuration among other things. The app is written in SwiftUI, and two floors are named for it: Xcode 14.0 or later to build and use it, macOS Big Sur or later to run it.

The clock, the status bar, and Apple's 9:41

System time and date can be set to any value you want, and the value named in the README is Apple's preferred 9:41, the time that appears in Apple's own screenshots. That control pays for itself when you are reproducing a layout that only breaks past midnight, or when a screen's timestamp matters to what you are looking at. Status bar configuration sits in the same group, next to the three states that send you back into the simulator's Settings app: WiFi, cellular service, and battery. Control Room controls the status of WiFi, cellular service, and battery without leaving the app you are testing. What it does not do is spell out the item by item coverage. The README lists status bar configuration as a feature and stops there, so which indicators can be rewritten is unstated.

Appearance, language, accessibility, and Dynamic Type

One group of overrides covers the settings that change how a screen reads rather than what it does. Dark mode and light mode can be forced either way. Language can be switched. Accessibility options can be overridden, and Dynamic Type content size can be set. Each of these costs a trip through the Settings app and a relaunch when done the long way, and here they sit together. Location lives next to them: a custom user location can be picked from anywhere in the world, so a map screen can be checked against a specific coordinate without typing a latitude by hand. The limit is that none of it is scriptable. The README describes no command line, no URL scheme, and no file format for replaying a configuration, so every override is something you set by hand in the interface, and nothing here can be handed to a continuous integration job.

Screenshots and movies with an optional device bezel

Screenshots and movies open the capture surface, and screenshots carry an option to add the device bezels around the image. A capture taken for review or documentation can show the hardware outline instead of a bare rectangle of pixels, which is the version you want for a store listing or a slide deck. The bezel is optional, so the same capture can be taken without the frame when the extra chrome is noise inside a bug report. Movies are recorded through the same surface. What Control Room does not document is any batch or scripted capture. Each screenshot and each recording is something you ask for one screen at a time, and no sequence file is described for running a longer flow unattended.

Opening the data folder and editing UserDefaults entries

Not every feature here is a control. Control Room opens the data folder for the app you are testing and lets you edit that app's `UserDefaults` entries directly, without hand assembling a Library path or writing a throwaway script to set a key before launch. For anything that reads a flag, a token, or an onboarding marker out of `UserDefaults`, that removes the slowest part of the loop. The other side is worth naming: this is the simulator's copy of your app, so what you change there affects that container and nothing else. The README does not say how a value written by hand is reconciled with the same key written by the app on its next launch, so treat the editor as a debugging aid rather than a place to keep lasting state.

Color picking that ends in UIKit or SwiftUI code

The color tool starts on a pixel in the simulator rather than on a color wheel. You pick a color from what the screen is actually showing, then convert it to UIKit code, to SwiftUI code, or drag it directly into your asset catalog. That last route is the one that changes your workflow, because the sampled value is not retyped by hand and lands in the catalog your build already reads. The conversion targets named in the README are UIKit and SwiftUI, which suits a SwiftUI app, but the format of the emitted snippet is left unspecified, so check what you get before pasting it into a view. The sampler reads the rendered screen, which means what it reports is the on-screen result after any dark or light mode override is already in force.

The menu bar icon repeats your last push notification

An optional menu bar icon sits above the main window. What it adds is quick actions such as re-sending the last push notification, and re-opening your last deep link. Both are repeats of the previous action rather than new inputs, so the menu bar is a shortcut backwards, not a second place to compose a payload. The lifecycle controls stay in the main window: starting, stopping, installing, and removing apps, and triggering the test push notifications or deep links in the first place. The icon being optional matters on a shared machine, or on any setup where one less item in the status area is preferred, since nothing forces it into the menu bar.

No release to download, so Control Room is built from source

Control Room ships as source. There is no tagged release to download, so getting it running means downloading the code and building it through Xcode, on a Mac with Xcode 14.0 or later and macOS Big Sur or later. What sits at the repository root is what you point Xcode at:

.editorconfig
.github/
.gitignore
.swiftlint.yml
CODE_OF_CONDUCT.md
ControlRoom.xcodeproj/
ControlRoom/
ControlRoomTests/
LICENSE
README.md
Working/

The project is `ControlRoom.xcodeproj`, the app source sits in `ControlRoom/`, and a `ControlRoomTests/` target sits alongside it. The `.swiftlint.yml` file is not incidental, because the contribution guide asks that SwiftLint return no errors or warnings before changes are sent in, which makes a lint run part of the definition of done. Two gaps are worth knowing first. There is no changelog file and no release history to check a behaviour change against, and the default branch `main` was last pushed to on 20 October 2026. The contribution guide invites contributors to add tests while noting that the underlying use of simctl might make that tricky, and meaningful error handling is listed as an open suggestion for contributors.

Editorial conclusion

Control Room earns its place if you build for iOS, tvOS, or watchOS on a Mac that already has Xcode, and if you keep losing time to the simulator's own Settings app. Skip it if you want a downloadable binary, a scripted and repeatable device configuration, or a release history to check a behaviour change against. Confirm your macOS and Xcode versions against the stated floors before you build, because the app is compiled from source on your machine.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. twostraws/ControlRoom on GitHub