Locara

15 — Distribution

How a published Locara app gets onto a user’s Mac. Standard Mac app distribution patterns, with Locara-specific trust mechanics layered in.

The user-facing flow

  1. User browses locara.app (a static website).
  2. Clicks “Install Transcribe.”
  3. Browser downloads Transcribe-0.1.0.dmg from Locara’s CDN.
  4. User opens the DMG, drags Transcribe.app to /Applications.
  5. macOS Gatekeeper verifies the signature + notarization stapled to the bundle.
  6. User double-clicks the app; first-run consent UI appears (capability summary).
  7. User accepts; app launches.

Total time on broadband: ~30 seconds for a small app, longer for one with multi-GB models.

No “install Locara client first” step. No proprietary store app. Each Locara app is a standalone signed Mac app, distributed via the same channels as any other Mac app.

What locara.app (the website) does

The website is a static Astro/HTML site. It:

  • Renders the catalog from registry data (build-time generated + periodically rebuilt).
  • Shows app pages (manifest data, screenshots, capability badges, reviews).
  • Provides direct download links to signed .dmg files served from R2.
  • Hosts blog, manifesto, docs, legal.
  • Doesn’t require an account to browse or download.
  • Doesn’t run JavaScript that talks to your installed Locara apps.
  • Doesn’t run analytics or tracking.

That’s it. It’s a website. The intelligence lives in the apps themselves.

App download

Each published app version has a permanent download URL:

https://cdn.locara.app/apps/<publisher>/<name>/<version>.dmg

DMGs are:

  • Built by Locara CI from source by commit hash.
  • Signed with Locara’s single Apple Developer ID.
  • Notarized by Apple; ticket stapled to the bundle.
  • SHA-256 published in the manifest API (verifiable on download).
  • Cached via Cloudflare R2 (no egress fees, multi-region).

The website’s “Install” button is a direct download link to the latest version’s DMG. No JavaScript indirection, no auth required.

For developers / power users: the manifest API exposes all versions, hashes, and direct URLs. Anyone can write a tool that bulk-downloads, verifies signatures, etc.

Install flow (what happens after download)

1. User opens Transcribe-0.1.0.dmg
2. macOS verifies signature + notarization
3. User drags Transcribe.app to /Applications
4. macOS registers app with Launch Services
5. App appears in Spotlight, Dock, Launchpad
6. User double-clicks the app
7. macOS allocates App Sandbox container at ~/Library/Containers/<bundle-id>/
8. App reads embedded manifest
9. First-run consent UI shows the capability summary
10. User accepts; app fetches any missing models (to shared cache) and starts

This is identical to how any other Mac app installs. The only Locara-specific step is the first-run consent UI, which the app’s own first-launch code presents.

When a Locara app launches for the first time, before doing anything else, it shows:

┌──────────────────────────────────────────────────┐
│ Welcome to Transcribe                            │
│ by kingtongchoo (Domain-verified)                │
│                                                  │
│ This app can:                                    │
│   ✓ Use your microphone                         │
│   ✓ Read files you select                       │
│   ✓ Use Whisper (1.4 GB local model)            │
│                                                  │
│ This app cannot:                                 │
│   ✗ Access the network                          │
│   ✗ Read other files on your Mac                │
│   ✗ Phone home or send telemetry                 │
│                                                  │
│ Built and signed by Locara CI.                   │
│ Source: github.com/kingtongchoo/transcribe       │
│                                                  │
│       [ Continue ]   [ Quit ]                    │
└──────────────────────────────────────────────────┘

User clicks Continue → app proceeds to its main UI. Quit → app exits cleanly.

This UI is rendered by the app’s own first-launch code (using @locara/components). The capability declarations are read from the app’s embedded manifest; the user can verify what they’re agreeing to before any sensitive operation.

Updates

Each Locara app handles its own updates via Tauri’s standard updater plugin, configured to point at Locara’s manifest API:

1. App checks the registry's manifest API on launch (and periodically)
2. If a new version is available:
   a. Compare manifest capabilities (old vs new)
   b. If no capability changes: download in background, prompt to restart
   c. If new capabilities: cool-down period (see 14-trust-safety.md)
3. New .app downloaded; signature + provenance verified
4. On user-triggered restart:
   - Run any DB migrations (transactional, with backup)
   - Replace .app in /Applications
   - Relaunch
5. If migration fails: roll back DB, refuse update

Updates are per-app. There’s no “update everything” central client. Users disable auto-updates per-app via the app’s Settings if they want.

A future optional Locara Manager menubar utility (phase 3+) could provide unified “all your Locara apps” update visibility, but isn’t required.

Off-registry distribution

Because each app is a standard signed Mac app, distribution outside Locara’s registry is just normal Mac app distribution:

  • Developer’s own website — host the .dmg themselves; users download directly.
  • Homebrew Cask — submit a Cask formula referencing the developer’s .dmg. Same install UX as brew install --cask transcribe.
  • Internal company mirror — corporate IT mirrors the .dmg for offline installs.
  • Email or USB — the .app is just a folder; copy it anywhere.

All of these work because there’s nothing Locara-proprietary about distribution. The app is a Mac app.

The trust mechanics travel with the artifact regardless of source:

  • macOS Gatekeeper still checks Apple notarization + Locara’s developer signature.
  • The runtime still enforces capabilities.
  • The Sigstore provenance attestation is still verifiable.

What’s lost off-registry:

  • Catalog discovery — off-registry apps don’t appear on locara.app.
  • Automated review — off-registry apps haven’t passed Locara’s review pipeline. Users see “not from Locara registry” banner on first launch.
  • Fresh kill-switch updates — apps cache the revocation list; without network access to the registry, the cache goes stale.

Multi-registry / federated discovery (future)

The locara.app website queries Locara’s official registry. There’s nothing preventing a third party from running their own catalog site that serves a different selection of apps.

For example, an enterprise might run apps.acme-internal.com listing only company-internal Locara apps. Same architecture as locara.app; just pointed at a private manifest API.

End-user UX: the user just downloads .app files from whichever website they trust. No client config needed; the apps themselves are standalone.

This is intentionally informal in v1. Multi-registry coordination tooling (a unified browse-multiple-sources surface) is phase 4+ if there’s demand.

Uninstall

Standard Mac app uninstall:

1. User drags Transcribe.app from /Applications to Trash
2. macOS removes the bundle
3. App data persists at ~/Library/Containers/<bundle-id>/ (in case of reinstall)

To fully clean up:

  • The app can offer a “Reset / clear data” option in its Settings.
  • Or the user manually removes ~/Library/Containers/<bundle-id>/.
  • Or third-party uninstaller tools (AppCleaner) handle it.

Models in the shared cache (~/Library/Caches/Locara/models/) stay; refcount-zero models become eligible for cleanup after 30 days idle.

Backups + data export

Each Locara app handles its own data export via the SDK:

import { db } from '@locara/sdk'

// User-triggered export
const archive = await db.export.zip({
  formats: { transcripts: 'markdown', settings: 'json' }
})
// archive: a Blob the user can save anywhere

Apps surface this through their own UI (“Export → Save as…”). No central Locara backup mechanism.

For OS-level backups: Time Machine + iCloud Drive backup the app’s container directory like any other Mac app’s data.

Device-fit advisor (on the website)

When viewing an app page on locara.app, the user can paste their Mac’s specs (or use a small JS snippet that reads system info from the browser, with permission) to see:

Transcribe requires 16 GB RAM.
Your Mac: M2 Pro, 32 GB. ✓ Fits "high" profile.

Helps prevent “downloaded an app that can’t run on my Mac.” Browser-side computation; no data sent to Locara.

If the device is below the lowest declared profile, the app page warns:

Transcribe requires at least 8 GB RAM.
Your Mac has 4 GB. This app may not work well on your device.

User can still download; warning is for awareness.

Catalog filtering (on the website)

Users can filter the catalog by:

  • Privacy badge: fully local | uses network
  • Device fit: works on my Mac | low-tier | mid-tier | high-tier
  • Category: productivity | developer | creative | research | etc.
  • Verified: domain-verified publishers only | all publishers
  • Last updated: any | last 30 days | last 90 days

The capability summary shows on every app card:

  • Yes/no for each major capability
  • Models used (with sizes)
  • Tools used
  • Disk + RAM requirements

What we deliberately don’t do

  • No proprietary “Locara client” app. The website + standalone apps are sufficient.
  • No required user account. Browse, download, install — all anonymous.
  • No centralized analytics. Aggregate install counts come from anonymous version-check pings, not user tracking.
  • No app-store-style payment processing. Apps that charge users do so via their own commerce (Stripe, Lemon Squeezy, MAS).
  • No “store-only” distribution. Apps can always be sideloaded — the registry isn’t a gatekeeper, it’s a curated discovery surface.

Open questions

  • (open) Should the install consent UI be standardized via a Locara framework component, or each app’s own decision? Probably standardized — @locara/components ships a <FirstRunConsent> widget that reads the manifest.
  • (open) Should there be a tiny system-tray utility (the optional “Locara Manager”) that helps users see installed apps + updates in one place? Useful but not required. Phase 3+.
  • (open) Beta channel — should publishers be able to publish “beta” versions of their apps that opt-in users can install? Yes; phase 3+.

Cross-references