Publication transparency

The proposed log would let Apple or another reviewer inspect what was published to a view address and when. Every accepted publication would remain in the history, including versions later replaced or withdrawn.

Record each publicationCopy Anchor Link

Each record would identify the full view address used by flkr, such as:

apple:bundle-id:com.acme.myapp/myApp#views/card

Each entry must identify:

The publication service must record all accepted publications, including those made outside flkr. Updating or withdrawing a view must preserve earlier entries.

Reviewers need access to the content committed to by each hash. Its exact artifact coverage and retrieval policy remain design decisions.

Verify the historyCopy Anchor Link

The log must be append-only and tamper-evident, following the model used by Certificate Transparency.

An inclusion proof would verify that a publication belongs to the log. A consistency proof would verify that a later checkpoint extends an earlier history without rewriting its entries.

Detecting conflicting histories shown to different readers also requires independently comparing checkpoints. Hashes and timestamps alone cannot establish tamper-evidence.

Design work remainingCopy Anchor Link

1. Content: which artifacts, manifests, and referenced dependencies the hash covers, and how reviewers retrieve them.
2. Time: how publication acceptance time is recorded and distinguished from log integration time.
3. Verification: entry, checkpoint, and proof formats; independent checkpoint comparison; and how a query proves it returned every publication for a view address.
4. Publication integration: how failures, retries, and outages are handled while ensuring every accepted publication reaches the log.

This proposal supports an audit trail; it does not certify the published content or establish App Store approval.

See Sandbox and App Store review for the native capability boundary and Apple’s review requirements.