Appearance

Application Discovery ​

This page defines the Launcher’s cross‑platform Application Discovery model. The Launcher discovers installed applications using pluggable discovery providers, normalizes them to a common schema, filters them through policy, and exposes them in the Applications tab and context menus.

  • Provider‑based architecture with OS‑specific backends
  • Normalized application record shape across all providers
  • Live updates using filesystem/OS registries and background refresh
  • Declarative configuration for enabling/disabling providers, include/exclude filters, and priority ordering

What You'll Learn

  • How discovery providers enumerate applications
  • How the normalized application record is shaped and deduplicated
  • How to configure providers, filters, and priorities
  • How the Applications tab groups and refreshes discovery results

1. Overview ​

Discovery is performed by a configurable pipeline:

  1. Providers enumerate candidate applications from OS sources.
  2. Each candidate is mapped to a normalized application record.
  3. Policy filters determine visibility and authorization.
  4. The UI displays permitted applications grouped by provider/source.
  5. Changes are monitored in real‑time; a background refresh also runs on an interval.

2. Normalized Application Record ​

All providers emit the same shape. Fields not applicable to a provider are omitted.

For the full field list and example JSON, see the Application Discovery Schema.

Deduplication: If multiple providers discover the same logical app (e.g., an MSIX app also has a Start Menu shortcut, or a PWA is represented both as a PWA and a Start Menu/Desktop shortcut), the Launcher uses provider priority and heuristics (exact name match, icon match, target/URL/scope correlation) to keep the best record. When applicable, prefer PWA entries from web.pwa over OS shortcuts, unless overridden by provider priority.

3. Modern Package Managers and Containerized App Formats ​

The Launcher’s discovery pipeline focuses on OS‑level integration points (shortcuts, application bundles, .desktop files, and CLI tools on PATH) plus selected package and container catalogs. Dedicated providers for modern package managers and containerized application frameworks map those catalogs into the normalized application record so they can participate in policy, deduplication, and grouping alongside traditional desktop entries.

General rules

  • The Launcher does not query arbitrary internet catalogs. Package manager and container providers read the local installed package state only.
  • Discovery is always via installed artifacts: files on disk, application registrations, or CLI shims, not just catalog metadata.
  • GUI/desktop apps appear in the Applications tab under their OS grouping; CLI tools are surfaced under CLI TOOLS when enabled.

Common behavior

  • source.provider identifies the ecosystem (for example, windows.msix, macos.homebrew, linux.flatpak, linux.snap, container.dockerDesktop).
  • source.ref is a stable package identifier within that ecosystem (for example, an MSIX AUMID, Flatpak app id, Snap name/channel, Homebrew formula/cask name, or a Docker Desktop app identifier).
  • activation is resolved to a concrete launchable entry point:
    • GUI apps: type=file|desktopExec|bundleId depending on platform, using the installed executable or framework-specific run command.
    • CLI tools: type=file targeting the installed binary; entries can be classified as CLI for grouping under CLI TOOLS.
  • Providers emit metadata fields (name, description, categories, tags) from the package or container manifest in addition to OS metadata where available.

When the same logical app is discovered from both a package manager provider and an OS‑level provider (for example, a Homebrew cask that installs a .app bundle, or a Flatpak app that also registers a .desktop file), provider priority controls which record is canonical. Metadata from lower‑priority providers may still be merged into the winning record as tags.

4. Providers Catalog ​

Discovery uses pluggable providers to enumerate applications from OS registries, filesystem locations, package managers, container catalogs, web bookmarks, and SaaS identity catalogs.

For the complete provider list and per-provider details (sources, activation behavior, options, and update patterns), see the Discovery Providers Catalog.

For a provider-by-provider capability matrix (desktop vs CLI vs web/SaaS, live updates, deduplication), see the Capability matrix on the Discovery Providers Catalog.

5. Configuration ​

Discovery is configured under configuration.discovery.providers. Providers execute in order; earlier providers win dedupe conflicts.

Example (enable desktop, web, and SaaS providers with priorities)

json
{
  "configuration": {
    "discovery": {
      "providers": [
        { "type": "windows.msix", "enabled": true },
        { "type": "windows.shortcuts", "enabled": true },
        { "type": "macos.launchservices", "enabled": true },
        { "type": "linux.freedesktop", "enabled": true },
        {
          "type": "web.pwa",
          "enabled": true,
          "options": { "browsers": ["edge", "chrome"], "requireInstalled": true, "defaultBrowser": "edge" }
        },
        {
          "type": "web.bookmarks",
          "enabled": true,
          "options": {
            "browsers": ["edge", "chrome"],
            "includeProfiles": ["Default", "Profile *"],
            "importRules": { "allow": ["*.contoso.com/*", "*.microsoft.com/*"], "deny": ["*.example.net/private/*"] },
            "defaultBrowser": "edge"
          }
        },
        {
          "type": "saas.okta",
          "enabled": true,
          "options": { "domain": "contoso.okta.com", "preferDeepLink": true, "defaultBrowser": "edge" },
          "filters": { "include": ["Salesforce*", "Workday*"], "exclude": ["*Sandbox*"] }
        },
        {
          "type": "native.path",
          "enabled": true,
          "options": {
            "paths": ["C:\\Windows\\System32"],
            "patterns": [
              { "match": "notepad.exe", "displayName": "Corporate Notepad" }
            ]
          }
        },
        { "type": "cli.path", "enabled": true },
        { "type": "portable.apps", "enabled": true },
        {
          "type": "turbo.workspaces",
          "enabled": true,
          "options": { "domains": ["portal.example.com"], "requireLogin": true, "offlineMode": "subscribedOnly" }
        }
      ]
    }
  }
}

Filters

  • include/exclude: glob or regex patterns applied to canonical name, id, and provider ref.
  • Additional per‑provider filter options may be exposed (e.g., restrict to specific folders or web hosts/paths).

Policy gating

  • After discovery, the normalized records are filtered by policy. Only applications matching an allow rule are shown. See Authorization & Visibility.

6. Grouping and Presentation ​

The Applications tab groups entries by source:

  • Windows
    • START MENU (Start Menu shortcuts)
    • DESKTOP (Desktop shortcuts)
    • APPS (MSIX/UWP)
  • macOS
    • APPLICATIONS (System)
    • APPLICATIONS (User)
  • Linux
    • APPLICATIONS (System)
    • APPLICATIONS (User)
  • Web
    • PWAs (installed Progressive Web Apps)
    • SaaS (identity provider catalogs)
    • BOOKMARKS (enterprise/bookmark sources)

Folders in Start Menu are shown when they include multiple allowed apps; single‑app folders are flattened. Desktop entries are presented as a flat list. Bookmark folders may be represented as groups depending on configuration.

7. Refresh Behavior ​

  • Real‑time updates via OS watchers (filesystem, package registries, LaunchServices, inotify)
  • Periodic reconciliation every 5 minutes
  • Manual refresh: Press F5

8. Troubleshooting ​

General

  • Use F5 to force a refresh. Check policy if apps are missing.
  • Confirm provider enablement in configuration.discovery.providers.

Windows Shortcuts

  • Verify .lnk/.url exist under Start Menu or Desktop paths.
  • Check permissions to read %PROGRAMDATA% and %APPDATA%.

Windows MSIX/UWP

  • Confirm the app appears under shell:AppsFolder.
  • Ensure the user context has the package installed.
  • Verify AUMID mappings; re-register packages if necessary (Add-AppxPackage -Register).

macOS LaunchServices

  • Ensure the app exists in /Applications or ~/Applications.
  • Rebuild LaunchServices cache if entries are stale (lsregister rebuild).

Linux Freedesktop

  • Confirm .desktop files exist and are valid per the spec.
  • Check Exec field parsing; remove unsupported field codes.

Web / SaaS

  • Verify the browser/profile exists and is accessible by the Launcher.
  • Confirm the user is signed in to the identity provider or browser profile as required.
  • Review filters for host/path and provider include/exclude rules.

9. Security Notes ​

  • Discovery does not grant launch permission. Policy controls visibility and authorization.
  • For enterprise deployments, prefer deterministic filters and audit discovery results.
  • Identity/SSO artifacts and runtime security controls are configured separately. See Identity Access (SSO) and Runtime Configuration.
  • For URL and PWA activations, prefer constrained, policy‑managed browser profiles and apply Data Motion/DLP controls for web content.
  • When the same logical app exists across providers (e.g., bookmark vs SaaS catalog vs PWA vs OS shortcut), use provider priority to prefer the most secure/managed activation (often PWA or SaaS catalog with SSO) and avoid duplicates.

Turbo.net © 2025