Tap-to-Share Blueprint

2.1What carries over

• Universal/App Links are already verified end to end for skypie.com — adding a /s/* path is a one-line addition to the existing AASA/assetlinks.json arrays, not new infrastructure.
• The public Slice page is already Tier 0 of the zero-install ladder (§9) — SSR'd, unauthenticated, with OG tags and app-open/store-fallback JS already written in deepLink.ts. The web-renderer work in this blueprint is extension, not a new page.
• The App Clip parent-app prerequisite is already satisfied — the main SkyPie app ships. Adding an App Clip target is scoped work inside the existing Xcode project, not a sequencing blocker.
• react-native-qrcode-svg is already a dependency — the QR fallback screen reuses a library the app already ships, just pointed at a share token instead of a coupon ID.
• The shareSlice() recipient-lookup logic (email/phone, non-user handling via Invite) is a reasonable pattern to keep for bookkeeping "who was this Slice shared with" — only the link/token itself needs replacing.

2.2What has to be built

• NFC, entirely from zero — no packages, permissions, or entitlements exist anywhere in the three repos today. This is the single largest net-new surface (§8).
• A real share-token service (§5) — encodeId/decodeId is reversible base64, not a signature; it has no TTL and no single-use enforcement. Fine for today's low-sensitivity public fields (title/description/image only), but not fit to be broadcast over NFC/QR to a stranger, which this feature does by design.
• A /s/:token route — today's closest analog, /slice-details?id=, is query-param based and tied to the old encodeId scheme.
• Fix or replace the dead Share.share() code in gift-page.tsx — the iOS-sender share-sheet path (§7.3) is written but broken (missing import, commented out), not absent, so this is a repair, not a build.
• A PWA manifest/scope fix for the share landing page — today's manifest sends "Add to Home Screen" into /user/sign-in, not back to the Slice.
• The App Clip target itself — Xcode target, entitlements, and Advanced Experience registration in App Store Connect (§7.2).

3.1Components

3.2Receiver resolution logic

3.3Non-functional requirements

4.1Detail: Android sender → iPhone receiver

7.1Associated domain — one AASA, two keys

{
  "applinks": {
    "details": [{
      "appID": "Y4524DMM84.skypie",
      "components": [
        { "/": "/login/*" },
        { "/": "/slice-details/*" },
        { "/": "/slice-list" },
        { "/": "/s/*", "comment": "NEW — Slice share links" }
      ]
    }]
  },
  "appclips": {
    "apps": ["Y4524DMM84.skypie.Clip"]
  }
}

7.2App Clip target

• The parent-app prerequisite is already met — SkyPie.xcodeproj ships a live application-type target today. This is a new target added to that same project, not a new project.
• Binary budget: 15MB thinned (iOS 16+), 10MB on older devices still in the fleet. Fetch the Slice content over the network on launch — ship a viewer, not a bundle.
• Invocation types wired, in priority order: NFC tag (background, no unlock required), App Clip Code (QR-compatible artifact that also encodes NFC), Safari Smart App Banner (the existing apple-itunes-app meta tag on slice-details already proves this path is live — the App Clip just needs to register the same URL as an Advanced Experience), Messages link preview, Maps for venue-tied Slices.
• Each Advanced App Clip Experience is registered in App Store Connect against a specific URL pattern (/s/*) — this is account configuration, not code.
• Ephemeral by design — no durable local state. Authenticate off the token server-side; offer Sign in with Apple as the upgrade path so identity carries into the full app if they install it.

7.3iOS as sender

8.1HCE service — emulate a Type-4 NDEF tag

<service
    android:name=".nfc.SliceHceService"
    android:exported="true"
    android:permission="android.permission.BIND_NFC_SERVICE">
    <intent-filter>
        <action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
    </intent-filter>
    <meta-data
        android:name="android.nfc.cardemulation.host_apdu_service"
        android:resource="@xml/apduservice"/>
</service>

<host-apdu-service
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:description="@string/slice_tap"
    android:requireDeviceUnlock="false">
    <aid-group android:category="other">
        <!-- NFC Forum NDEF Application ID -->
        <aid-filter android:name="D2760000850101"/>
    </aid-group>
</host-apdu-service>

The service responds to SELECT / READ BINARY APDUs with a Capability Container and an NDEF file containing a single URI record (the minted skypie.app/s/:token link) — the exact exchange any Type-4 tag reader, including iPhone's background reader, expects.

8.2App Links

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.infra.SkyPie",
    "sha256_cert_fingerprints": [""]
  }
}]

This file is already deployed and verified for /slice-details and /login. Adding /s/* is an intentFilters entry in app.config.js, not a new asset-links deployment.

8.3PWA — the actual "zero install" ceiling on Android

if ('NDEFReader' in window) {
  const reader = new NDEFReader();
  await reader.scan();
  reader.onreading = (event) => {
    const record = event.message.records.find(r => r.recordType === 'url');
    const url = new TextDecoder().decode(record.data);
    window.location.href = url; // hand off to the resolver
  };
}

Useful for a fixed device — a host stand or box-office tablet with this page pinned open — not for the cold-tap case, since the tab has to already be foreground.

8.4AID routing conflicts

• TTL matches the UI session, not the Slice. A bump-minted token should expire in minutes (proposed: 5), independent of how long the underlying Slice itself is valid — a passerby scanning a phone left mid-flow shouldn't get a live link.
• View vs. redeem. GET /s/:token is idempotent and safe to hit repeatedly (preview, retries, App Clip re-launch). POST /s/:token/redeem must take a row lock or use a conditional update (WHERE state = 'active') so two near-simultaneous redemption attempts can't both succeed.
• Revocation. Sender can cancel an active token before redemption — this is why an opaque server-side token was chosen over both a JWT and the existing encodeId scheme in §5.
• Rate limiting. Per-token and per-IP limits on /redeem to blunt brute-force guessing of the 12-char token space. @nestjs/throttler is already wired app-wide — this is a route-level policy, not new infrastructure.
• NFC-specific. Mint a fresh token per "Share by Bump" tap rather than reusing a static NDEF payload — the HCE session is already ephemeral (ends when the sender leaves the screen), so token TTL should track that, not outlive it.