Stop Opening Android Studio Just to Launch a Simulator — This Terminal Tool Fixed My Entire Flutter Workflow 🖥️
“I wrote a whole post about widgets I kept rebuilding by hand before finding out Flutter already had them. Turns out my terminal workflow had the exact same blind spot.”
Same pattern as my last post, different layer of the stack. Someone pointed me toward a tool called SimUtil after I mentioned an old habit of unfiltered adb logcat grabbing everything running on the device instead of just my app — and it turns out filtered logcat is literally one of its built-in features. Slightly annoyed I didn't find this sooner. Genuinely glad I have it now.
If you’re a Flutter or native mobile developer and you’ve never questioned why launching an emulator requires opening an entire IDE first, this one’s going to bother you a little once you see the alternative. Let’s actually go deep on it.
The Habit Nobody Questions 🔁
“Open Android Studio. Wait for it to load. Click through to the device manager. Click launch. Every single time.”
Here’s the workflow most Flutter developers never think twice about: open Android Studio or Xcode, wait for it to fully boot up just to reach the device picker buried a couple of clicks deep, select a device, hit launch, and then finally get back to the code you actually wanted to write thirty seconds ago. Need to switch to a different device mid-session — testing a layout on both a compact phone and a tablet emulator, say — the entire sequence repeats from scratch.
Nobody questions this because it’s just always been the way. It’s the default, so it stops feeling like friction and starts feeling like “how development works.” It isn’t. It’s just the workflow nobody’s bothered to challenge.
SimUtil is a free, open source terminal UI that quietly deletes that entire routine. Built by developer dungngminh, MIT licensed, sitting at nearly 500 GitHub stars and 55 forks — small, but clearly not an abandoned weekend project either. Run it, see every available Android emulator and iOS simulator listed side by side in one screen, hit Enter. No IDE required to be open at all. Your editor stays the only heavyweight thing running.
What Makes This Actually Different From “Just Use Android Studio” 🆚
“If the built-in device manager already exists, why does a third-party terminal tool matter at all?”
Fair question, and worth answering honestly instead of assuming the value is obvious. Here’s roughly how the three common approaches stack up for the stuff you actually do dozens of times a day:
Task Android Studio / Xcode Raw ADB commands SimUtil Launch a known device IDE must be open, 3–4 clicks deep Requires memorizing the AVD name One keypress, list already visible Cold boot a specific emulator Buried in AVD Manager settings Manual flag, easy to forget Selectable option, same screen View filtered logcat Separate Logcat panel, IDE required adb logcat | grep <tag>, manual every time Built-in, filter included Connect a physical device wirelessly Manual IP pairing dance Multi-step manual adb pair/adb connect Guided flow, QR or 6-digit code Run a custom tool (scrcpy, Maestro) against a device Separate terminal window, manual device ID Separate terminal window, manual device ID One keypress, device ID auto-filled
None of these individual tasks are hard the old way. They’re just death by a thousand small clicks and a few seconds of dead time between each one, repeated dozens of times across a working day. SimUtil doesn’t do anything an experienced developer couldn’t already do manually — it just removes the ceremony around doing it.
Worth noting too: it’s built on Nocterm, a terminal UI framework for Dart with a widget syntax deliberately close to Flutter’s own. If you already think in Flutter’s declarative widget model, reading SimUtil’s source feels oddly familiar — which probably explains why a Flutter-adjacent developer reached for this instead of a general-purpose terminal UI library from a completely different ecosystem.
Everything It Actually Does, Broken Down 📋
One-key launch. Select a device, hit Enter, done. The single biggest time-saver if you regularly test across multiple device profiles instead of always defaulting to whatever emulator happens to already be running because switching feels like too much friction.
Android launch options, picked from the same screen: Normal, Cold Boot, No Audio, or Cold Boot + No Audio. Cold Boot matters more than it sounds like — it’s what you actually want when debugging app first-launch behavior, or when you suspect a stale emulator snapshot is quietly masking a real bug. Most devs skip it because it’s buried deep in AVD Manager; here it’s one keypress away, which means people actually use it instead of settling for whatever’s faster.
Shutdown control, directly from the interface — no alt-tabbing to a separate window or manually running adb emu kill to close a device you're done testing.
Filtered logcat, built in. The exact gap I hit the hard way, covered in more detail in my last post — unfiltered adb logcat dumping every single process running on the device into one interleaved stream, yours included among everything else. SimUtil's logcat view supports real filtering out of the box, so you're actually looking at your own app's output instead of scrolling through a device-wide firehose.
Wireless ADB tools — connect to a physical Android device over its IP address, pair using the Android 11+ six-digit code flow, or pair via QR code. If you test on real hardware more than occasionally, cutting the USB cable entirely out of that loop is a genuinely underrated quality-of-life change — especially if your test device lives across the room, charging, while you’re at your desk.
Custom plugins — the feature that actually surprised me most. Wire in external tools like scrcpy or Maestro through a plain YAML config file. No code changes, no forking the repo, no waiting on a feature request that may never land. Press p on a selected device, pick a plugin, pick a command, and it runs — scoped automatically to whichever device is currently selected.
Editable config, one keypress away. Press e and it opens ~/.simutil/settings.yaml directly in your default editor across macOS, Linux, or Windows — no hunting through documentation to find where the config actually lives.
Setting Up the Plugin System, Properly 🔌
“Wire up scrcpy once, and screen mirroring is a single keypress away from that point forward, forever.”
This is worth walking through in real detail, because it’s the difference between SimUtil being “a nicer launcher” and becoming the actual hub for your entire device-testing toolkit.
# ~/.simutil/settings.yaml
theme: dark
last_selected_device_id: ~
plugins:
- id: scrcpy
label: scrcpy
description: Screen mirroring and control for Android
availability:
command: scrcpy
args: [--version]
commands:- id: mirror
label: Screen Mirror
command: scrcpy
args: [-s, "{device.id}"]
platforms: [android] # android | ios; empty = any
requires_running: true # only show when the device is running
mode: detached # detached (default) | inherit
shortcut: s # optional single key to run directly
- id: mirror
Worth actually understanding each field, not just copy-pasting it blind:
- availability lets SimUtil quietly check whether scrcpy is even installed before offering it as an option — so you're not stuck staring at a confusing failure the first time you try it.
- requires_running: true means the command only appears when the selected device is actually powered on. No point offering to mirror a screen that isn't rendering anything.
- {device.id} and {device.name} are template variables SimUtil substitutes automatically for whichever device is currently selected — one plugin definition covers every device you own, instead of a hardcoded entry per device.
- shortcut: s means mirroring is a single keypress away once configured — no separate terminal window, no remembering exact scrcpy flags, no manually copying a device ID first.
The exact same pattern works for Maestro (mobile UI testing), your own shell scripts, or genuinely any CLI tool already living in your workflow. If you’ve got a personal script you run against a device regularly, this is where it stops living buried in your shell history and starts living as an actual part of your toolkit.
Getting It Installed, However You Manage Your Tools 📥
# macOS / Linux, direct install script
curl -fsSL https://raw.githubusercontent.com/dungngminh/simutil/main/install.sh | bash
# Windows PowerShell
powershell -ExecutionPolicy Bypass -Command "iwr -useb https://raw.githubusercontent.com/dungngminh/simutil/main/install.ps1 | iex"
# Homebrew, macOS/Linux
brew tap dungngminh/simutil
brew install simutil
# Directly through Dart's own package manager
dart pub global activate simutil
Run simutil from anywhere afterward. Fully cross-platform — macOS, Linux, and Windows — though iOS simulator support naturally only applies where Xcode itself is available, meaning macOS for that half of the feature set.
Who This Actually Makes Sense For 🎯
Being straight about this instead of overselling it: if you almost always work with a single emulator you rarely close, and you’re not doing wireless physical-device testing, the day-to-day time savings here are real but modest. The value scales hard with how often you’re switching contexts — multiple device profiles, physical hardware testing, frequent logcat digging, or a personal toolkit of scripts you already run against devices regularly. If that’s genuinely your day, this earns its place in your terminal fast. If it’s not, it’s still a nice-to-have — just a smaller one.
Also worth knowing going in: it’s a small, community-maintained project — 494 stars, a handful of watchers, active but not massive. That’s not a red flag by itself; plenty of genuinely excellent developer tools live at exactly this scale. It does mean you’re not getting enterprise-grade support if something breaks on an unusual setup, so check the open issues before you lean on it for anything workflow-critical.
Why a Tool This Small Actually Matters 💭
Small developer tools like this rarely get the credit they deserve, because “launches a simulator faster” doesn’t sound impressive as a headline on its own. But stack a saved 20–30 seconds against however many times a day you’re actually switching devices during active Flutter development, and it adds up to a real, recoverable chunk of your day — plus one less context switch pulling your attention out of your editor and into an IDE’s device manager just to do something this mechanical.
The filtered logcat feature alone would’ve saved me the entire situation from my last post. Sometimes the fix for a bad habit isn’t more discipline. It’s just discovering the right tool was already built for the exact problem you didn’t even have a name for yet.
If you’re a Flutter developer who still opens Android Studio just to launch a simulator, this is genuinely worth the two minutes it takes to install.
Tags: Flutter, Android Development, Developer Tools, CLI, Dart, Mobile Development, Open Source
Stop Opening Android Studio Just to Launch a Simulator — This Terminal Tool Fixed My Entire Flutter… was originally published in Never Stop Writing on Medium, where people are continuing the conversation by highlighting and responding to this story.