Semantics
Apple Wallet semantic tags for boarding passes and events
Use structured semantic information while preserving compatible visible fields across Wallet versions and pass layouts.
What you’ll leave with
- Semantic tags describe meaning; visible fields preserve layout and backward compatibility.
- Only add tags that accurately represent the pass and selected style.
- Validate value types, availability, and fallback behavior on supported OS versions.
What semantic tags add
Traditional Wallet fields tell the system where text appears. Semantic tags tell the system what a value means—a flight number, venue, performer, seat, departure location, or another recognized concept. Wallet can use that meaning for system experiences and evolving layouts without depending on your field labels.
Semantics complement rather than replace visual fields. Keep a clear field hierarchy so the pass remains useful on OS versions and layouts that do not consume a particular semantic tag.
Boarding pass semantics
Boarding-pass semantics should reflect the actual journey and transit mode. Supply structured origin and destination information, carrier and trip identifiers, times, boarding details, and seat information only when they are known and correct. Do not force an airline concept onto train or bus data merely because the field names look similar.
Pair machine-readable dates, airport or station codes, and transit-specific identifiers with concise visible fields. Test missed, delayed, overnight, and timezone-crossing journeys rather than only a same-day happy path.
- Use stable identifiers when data may update.
- Preserve timezone information in date values.
- Keep origin and destination roles unambiguous.
- Treat gate, platform, group, and seat as separate concepts.
Event ticket semantics
Event semantics can describe the event, venue, performer or participant, start and end times, and seating details. Match the tag set to the actual event category. A concert, sporting event, conference, and screening may share visible labels while needing different semantic concepts.
Use semantic data to clarify rather than duplicate. The visible event title still belongs in a prominent field; the semantic entry gives Wallet structured context for supported experiences.
Validate types, availability, and fallbacks
Semantic tag catalogs evolve with Wallet releases. Check the platform version associated with each tag, use the documented value shape, and omit unsupported or unknown guesses. Invalid semantics should not be allowed to compromise an otherwise valid pass.
Test with and without semantic rendering. A person should still understand the pass from the classic fields, barcode, artwork, and back information. That fallback discipline makes the pass resilient across devices and future system changes.
Put it into practice
Build the JSON, then verify the package.
Use the free browser tools to turn the rules in this guide into a clean starting file and an actionable validation report.
Skip the hand-assembly.
PassMaker does every step on this page on your iPhone — field editor, artwork, manifest, PKCS#7 signing and Add to Wallet — without wiring up a signing environment.
Download on the App StorePrimary references
Related guides
pass.json
pass.json reference with working examplesUnderstand required keys, pass styles, fields, colors, barcodes, relevance, and common pass.json validation failures.
10 min readBarcodes
Apple Wallet barcode formats and compatibilityChoose between QR, PDF417, Aztec, and Code 128, set message encodings, and design barcodes that scan reliably from an iPhone display.
8 min readGetting started
How to create an Apple Wallet passA practical end-to-end guide to designing, packaging, signing, testing, and distributing a real Apple Wallet pass.
8 min read