If you spend time in the terminal, you've probably wished you could launch apps without navigating to the Applications folder or typing the full .app bundle name. The Mac open command solves this with a single flag.
The -a flag is all you need
Typing `open -a Cyberduck` launches the app regardless of your current directory. Case doesn't matter either—`open -a CyBeRdUcK` works the same way. The shell resolves the app name and fires it up.
That's it. No cd into /Applications, no adding the .app extension, no hunting through Finder. Just the app's display name as you'd recognize it in the Dock or Applications folder.
This isn't some obscure hack buried in documentation. It's a built-in argument that ships with every Mac and somehow stays under the radar for many developers who would benefit from it daily.
Why this matters for developers
Developers spend significant time switching between editors, browsers, simulators, and terminal sessions. The ability to launch any app by name from wherever you're working keeps context intact. You stay in the terminal, run your command, and the app appears without breaking focus.
For Android developers specifically, this comes in handy when you need to quickly open Android Studio, the emulator, Chrome DevTools, or any other tool without leaving your command-line workflow. Imagine you're debugging an API issue in the terminal. You spot a problem, fix it, and immediately need to test in the browser. A quick `open -a Chrome` gets you there without your hands ever leaving the keyboard.
The workflow improvement is modest per command, but it adds up over hundreds of daily interactions. Any friction between thought and action disrupts flow. This removes one small friction point from the development experience.
Common use cases and examples
Here are scenarios where this command proves useful throughout a typical development day:
- You finish a git commit and want to verify changes in your diff tool. Run `open -a "SourceTree"` or whatever your preferred Git client is called.
- You need to open the iOS simulator for testing. `open -a Simulator` handles it instantly.
- You want to check something in Safari while debugging in Chrome. `open -a Safari` is faster than switching windows.
- You need to pull up the design file in Figma while implementing a feature. `open -a Figma` gets you there.
- You want to open a specific URL in a non-default browser for testing. Combine the flag with a URL: `open -a "Google Chrome" https://tiptipa.com`
The open command also handles app names with spaces correctly. Wrap multi-word names in quotes: `open -a "Visual Studio Code"` works without issue. Without quotes, the shell interprets the space as an argument separator and gets confused.
Our analysis
The traditional approach to opening apps from the terminal required either adding the Applications directory to your shell PATH, using the full bundle path like `/Applications/Cyberduck.app/Contents/MacOS/Cyberduck`, or relying on shell aliases you'd have to maintain manually.
The `-a` flag eliminates all that complexity. It searches the system-wide Applications folder automatically, matches by display name (which is what humans think in), and handles case-insensitivity. This is exactly how a user-friendly CLI should work.
What makes this more useful than it first appears is how it composes with other commands. You can chain it with git hooks, build scripts, or automation tools. A post-commit hook could automatically open your CI dashboard. A build script could launch the simulator when compilation finishes. The possibilities scale with your workflow.
Not every developer needs this. If you primarily use your mouse or rarely touch the terminal, the benefit is minimal. But for engineers who live in the command line—and many Android developers fit this profile—every second saved compounds across thousands of daily interactions.
What to watch next
Apple has gradually improved macOS automation over the years, but command-line app launching remains most powerful through the open command. If you want to extend this further, look into shell aliases that map short commands to common apps. Something like alias c="open -a Chrome" in your dotfiles gives you a single-character shortcut for launching your browser.
The underlying lesson here is to periodically review your daily friction points. Most developers accept small inefficiencies without questioning them. That app you open three dozen times a day from a hardcoded path? There might be a better way.
Takeaways:
- Use `open -a AppName` to launch any installed application by its display name from any directory
- The flag is case-insensitive and requires no .app extension or full path
- Wrap app names with spaces in quotes to handle the space character correctly
- Combine with URLs to open specific pages: `open -a Safari https://example.com`
- Add shell aliases for your most-used apps to speed up repeated launches
Frequently asked questions
Does the app name need to match exactly?
No. The command resolves app names case-insensitively and matches partial names when there's no ambiguity. Cyberduck, CYBERDUCK, and Cyberduck all work.
Can I open files in specific apps this way?
Yes. `open -a "App Name" /path/to/file.txt` opens the file in the specified application rather than the default handler.
Does this work with URLs?
Yes. `open -a Safari https://example.com` opens the URL in Safari specifically. You can also use `open https://example.com` without the -a flag to open in your default browser.
Is there a way to see all installed apps from the terminal?
The command doesn't have a built-in list function. You can run `ls /Applications` or `ls /Applications/Utilities` to see what's installed, or browse the folders in Finder.
What if two apps have similar names?
When there's ambiguity, the command may fail or open the wrong app. Use the full display name in those cases to be explicit about which application you intend to launch.