Omarchy apps and development tools: choose, install and connect your workflow
Understand package sources, terminals, defaults and Web Apps, then verify each part of your everyday workflow.
Based on public documentation; not hardware-tested. Match the instructions to your version and hardware.
An application belongs in your setup because it completes a task. Omarchy combines desktop applications, terminal tools and integration helpers. Understanding their roles is more useful than installing every name in a package list.
This guide helps you choose a tool, identify its installation source and test how it joins your workflow. Use the package manifests for the source inventory and default apps and Web Apps for detailed link routing.
Organize applications by their work
Section titled “Organize applications by their work”| Work | What to consider | Continue here |
|---|---|---|
| Browse and sign in | Browser, profile and ordinary link handling | Default apps and Web Apps |
| Open files and documents | File manager, file type and association | Apps and packages layer |
| Write code and run commands | Terminal, shell, editor and runtime | Terminal basics and development layer |
| Capture or share a task | Screenshot/recording tool and target application | Screenshots and recording |
| Keep work running after closing a window | Session lifetime and background ownership | Terminal sessions and autostart |
These are roles, not a guarantee that every release installs the same applications. A manifest lists source choices; your actual installation may differ. Check what you already have before installing a second program to satisfy a tutorial’s assumed name.
Choose an installation source
Section titled “Choose an installation source”Start with the options in your Omarchy menu and the official package guide. Find the exact program, check its package identity and record its source before accepting installation.
Arch repositories, AUR build recipes and direct vendor downloads do not share identical update and removal paths. An AUR entry supplies a build recipe; a familiar name alone does not establish the publisher or maintenance quality. Read current package and upstream information. See Arch AUR documentation.
Before installing, answer:
- Does it support your architecture and the file or service you need?
- Which package or vendor supplies it?
- How will it receive updates, and how will you remove it?
- Does it need an account, license, plugin or system service?
Install one application and complete one real task before deciding to keep it. Package installation does not prove that a required plugin, runtime or online service is ready.
Terminal, shell, editor and Tmux
Section titled “Terminal, shell, editor and Tmux”Use the terminal comparison and Foot exercise for emulator choices, then the Tmux practice guide to split, detach, reconnect and stop a task in an independent practice server.
The terminal displays a command session. The shell interprets commands. Tmux manages sessions, windows and panes. An editor changes files, while a runtime manager selects language tools. Replacing one does not automatically replace the others.
Begin with terminal basics to navigate, read errors and interrupt a foreground command. The development layer explains the catalogued tools. If text looks wrong, inspect fonts and application theming before replacing your shell.
A first development test can be small: open an existing project, check its expected runtime, and run the project’s documented command. Keep the first useful error. Do not add administrator privileges just because the message is unfamiliar.
Test installation, defaults and shortcuts separately
Section titled “Test installation, defaults and shortcuts separately”| Test | What it establishes | If it fails |
|---|---|---|
| Launch from the menu | The app is discoverable and starts | Check installation and launcher |
| Open a known document | The app supports that document | Check file type, permissions and required support |
| Open an HTTPS link from another app | Ordinary links use the expected browser | Inspect default associations |
| Press your app shortcut | The binding launches the intended target | Inspect the actual binding command |
| Open an existing Web App | Its saved launcher uses the intended route | Inspect that entry separately |
Follow the default-app guide for the worked experiment. Keep the previous browser until links, authentication and Web Apps work. Changing a default does not migrate cookies, account profiles or every fixed launch command.
Appearance and startup come afterward
Section titled “Appearance and startup come afterward”Once the task works, check whether the app follows your theme. Some applications have separate appearance settings; application theming traces where a switch stopped taking effect.
Before adding startup, check whether the application already starts itself. Autostart and services helps you choose an owner and lifetime, inspect logs and verify a fresh login. An interactive shell alias may not exist in the launch environment.
Build a complete workflow
Section titled “Build a complete workflow”For a documentation task, open a browser, document and terminal. Arrange them with window layouts, check file and link handling, and capture a useful result with screenshots. For development, substitute your editor and project command.
Record what you installed, its source and changed settings. Before removal, consult that source’s instructions and decide whether to retain application data. Removing a package and deleting personal data are different operations. Protect your work with the backup guide.