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
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions