Skip to content

Feature: expand associated-domain support beyond the demo domain #8

@jmcte

Description

@jmcte

Problem

The v2 native app currently supports only https://example.com as a demo associated domain. Real-world deployments require credentials for production domains, which means:

  1. The app's Associated Domains entitlement must list each target domain.
  2. Each domain must serve an apple-app-site-association (AASA) file at /.well-known/apple-app-site-association.
  3. After adding domains, the app must be re-signed and re-notarized.
  4. There is no current mechanism for operators to declare which domains they need without modifying the entitlement plist and rebuilding.

Proposed Fix

Short term:

  • Document the full domain expansion process (AASA file format, entitlement update, notarization) in docs/INSTALLATION.md or a new docs/DOMAIN_EXPANSION.md.

Medium term:

  • Define a supported_domains field in ~/.apw/config.json that is validated at runtime against the app's embedded entitlements (so the config cannot claim more domains than the app is entitled to).
  • Add a apw doctor check that verifies each configured domain has a reachable and valid AASA file.

Long term:

  • Investigate whether a multi-tenant entitlement approach (wildcard subdomain or managed capability) reduces the per-domain rebuild requirement.

Acceptance Criteria

  • Domain expansion process is documented end-to-end.
  • apw doctor reports a clear error for domains missing a valid AASA file.
  • Adding a new domain does not require source code changes — only config and entitlement updates.
  • At least one production domain is tested in the extended validation suite before shipping.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions