You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
docs(mobile): association file tooling and per platform setup #39
This is the largest difference between a mobile template and the web templates, and it
is onboarding cost rather than code.
Browser WebAuthn treats localhost as a secure context, so the web templates work
immediately after seamless init. Native passkey APIs have no such exemption. Before a
passkey works at all, including on a simulator, an adopter must publish an association
file over HTTPS on a domain they control.
Per platform:
iOS needs an Apple Developer team (a free Personal Team is enough), a bundle
identifier, an associatedDomains entitlement, and an apple-app-site-association
file served as application/json with no redirect, listing <TeamID>.<BundleID>.
Android needs a Google account signed in on the device, a device screen lock, and an assetlinks.json carrying the package name and signing certificate fingerprint.
Scope
Ship a small static server for the two association files, parameterised by team id,
bundle id, package name, and certificate fingerprint.
Ship a helper that derives both required Android encodings from one digest: colon
separated hex for assetlinks.json, and base64url of the same raw bytes for the auth
server ORIGINS entry. Converting one to the other by hand is a common failure.
Document the prerequisites honestly, including that they cannot be removed.
Traps worth documenting
The Apple Team ID is the OU field of the signing certificate. The value in
parentheses in the certificate common name is the certificate id, not the team. An
association file built with the wrong team fails validation silently.
Simulator builds keep entitlements in the Mach-O __TEXT,__entitlements section, not
in the code signature, so codesign -d --entitlements reports an empty dict that looks
exactly like a missing entitlement. Inspect with otool instead, and do not re-sign a
simulator build by hand to "fix" it.
Acceptance
A new adopter can get a passkey working by following the docs, without reading source.
Shipped in #90 (templates v0.15.0): templates/mobile/expo/tools/associations/generate.mjs writes apple-app-site-association and assetlinks.json from one set of inputs and prints the matching android:apk-key-hash: origin, so the hex fingerprint and its base64url form cannot drift apart. The starter's README carries the prerequisites per platform and the two traps recorded here (Team ID is the certificate OU; simulator entitlements live in __TEXT,__entitlements). The docs site has the same material at build/mobile-passkeys (fells-code/seamless-auth-docs#43).
Activity
Bccorb commentedon Aug 1, 2026
Part of the React Native mobile template epic: #40
feat(mobile): add the Expo starter and the mobile template kind
Bccorb commentedon Sep 13, 2026
Shipped in #90 (templates v0.15.0):
templates/mobile/expo/tools/associations/generate.mjswritesapple-app-site-associationandassetlinks.jsonfrom one set of inputs and prints the matchingandroid:apk-key-hash:origin, so the hex fingerprint and its base64url form cannot drift apart. The starter's README carries the prerequisites per platform and the two traps recorded here (Team ID is the certificate OU; simulator entitlements live in__TEXT,__entitlements). The docs site has the same material at build/mobile-passkeys (fells-code/seamless-auth-docs#43).