Compatibility
Different apps expose different levels of desktop control.
Orvial's job is to make those differences visible rather than hide them. This page explains how compatibility is described — and why the per-application results are not here yet.
How compatibility is described
What do the compatibility levels mean?
Four levels, applied per capability rather than per application, because one application can be excellent at one and incapable of another.
- Supported
- The capability behaves predictably and the result can be verified afterwards.
- Best effort
- The capability usually works, but the outcome cannot be guaranteed or always proven. Orvial should say so rather than report a clean success.
- Unsupported
- The platform or the application does not permit the action here. Native fullscreen is the clearest example.
- Known limitation
- A specific, documented case where behaviour differs from the general rule.
What gets assessed
Which capabilities are measured?
Each one is assessed separately, per application, on tested macOS versions.
- Locate a window
- Move it
- Resize it
- Minimise and restore it
- Focus it
- Open a resource
- Identify a specific document or resource
- Restore internal Context
- Verify the final state
Orvial should never describe a fragile capability as deterministic.
Platforms
Where will Orvial run?
Platform intent, without dates that have not been set.
- macOS
- First release
- Apple silicon · macOS 26+
- Windows
- Planned later
- No release date has been announced.
- Linux
- Not currently planned
- The current product roadmap is focused elsewhere.
What Orvial does when a capability is missing — and how it reports that — is described on how it works.
Follow the build
Results publish when they are measured.
Compatibility findings arrive through the journal as Engine Lab evidence accumulates.