Every term you will meet building an Apple Wallet or Google Wallet integration, with the primary source next to each definition.
A .pkpass is the file format Apple Wallet installs. It is a ZIP archive containing pass.json, image assets, a manifest.json listing a hash of every file, and a signature over that manifest. Apple Wallet refuses to install the pass unless all four parts verify.
Because the signature covers the manifest and the manifest covers every file, changing a single pixel of a logo after signing invalidates the whole archive.
pass.json is the manifest of a pass's content: its type, the fields shown on the front and back, colours, barcode payload, and the identifiers that tie it to your Pass Type ID. Every other file in a .pkpass archive exists to support or verify it.
manifest.json maps every filename in a .pkpass archive to a SHA-1 hash of its contents. It is the document that actually gets signed, which is how one signature can guarantee the integrity of an entire multi-file archive.
Google Wallet splits a pass in two. The class is the template shared by every pass of a type: branding, layout, issuer. The object is one person's instance of it, holding their barcode, balance, and name. Updating a class changes every pass built on it.
The strip image is the wide banner across the top of an Apple Wallet pass, behind the primary fields. It runs 375×144pt on the standard spec and 375×123pt on newer layouts, and Apple crops or rejects passes whose strip deviates.
A pass style is the layout family Apple Wallet renders a pass in: boarding pass, coupon, event ticket, store card, or generic. The style fixes the field arrangement and cannot be changed after a pass is issued.
A Pass Type ID is the Apple identifier that says who issued a pass, paired with a certificate used to sign it. Apple Wallet checks the signature against this certificate on install, so without a valid, unexpired one you cannot issue passes at all.
Pass Type ID certificates expire and must be renewed. A lapsed certificate does not break already-installed passes, but every new pass silently stops signing.
The Apple Worldwide Developer Relations intermediate certificate sits between Apple's root and your Pass Type ID certificate. It must be included in the signature chain for a pass to validate, and it has its own expiry independent of your own certificate.
A WWDR expiry is a common cause of passes that sign fine one day and fail the next, because the failure has nothing to do with your certificate.
The pass update web service is an HTTP endpoint you host that Apple Wallet calls to fetch a fresh copy of a pass. Devices register with it when a pass is installed, and it returns the updated pass after you signal that something changed.
This is the piece most tutorials skip. Without it a pass is a static file, and a changed gate number or balance never reaches the phone.
APNs is Apple's push service. For wallet passes it carries a silent, alert-free push that tells a device one of its passes has changed. The device then calls your pass update web service to fetch the new version.
The push carries no pass data itself. It is a signal to go and look, which is why the update web service is mandatory rather than optional.
A save link is a signed JWT encoded into a URL that adds a pass to Google Wallet when opened. It carries the pass class and object, so a single link both defines the pass and installs it, with no file for the user to download.
This is the structural difference from Apple: Apple distributes a signed file, Google distributes a signed claim about a server-side object.
Relevance is the set of conditions (a time, a location, or a beacon) that make a pass appear on the lock screen without the user opening Wallet. It is the mechanism behind a boarding pass surfacing when you reach the airport.
Voiding marks a pass as no longer valid. Apple Wallet renders a voided pass with a struck-through appearance and stops surfacing it on the lock screen. The pass stays on the device, so voiding is a status change rather than a deletion.
Voiding is the correct response to a refunded ticket or a cancelled membership, and it is also what an erasure request should trigger alongside deleting the underlying record.
A rotating barcode changes its value on a schedule rather than staying fixed. Google Wallet generates the new value on the device from a shared secret using a TOTP-style algorithm, so a screenshot captures a code that has already expired.
Because rotation happens on-device, it keeps working with no network, which is why it suits transit gates where connectivity is unreliable.
Smart Tap is Google's NFC protocol for passes. It lets a terminal read a loyalty or ticket pass by tap rather than by scanning a barcode, and it requires both an NFC-capable terminal and a collector ID registered with Google.
PDF417 is a stacked 2D barcode used widely for boarding passes and ID documents. It holds far more data than a 1D barcode and stays readable when partially damaged, which is why airline scanners standardised on it.
Aztec is a 2D barcode that needs no quiet zone around its edges, so it packs more data into less screen area. Transit and rail ticketing favour it because it scans reliably from a phone screen held at an angle.
An active pass is one that currently exists and can be installed or updated. It is the unit most wallet-pass platforms price on, including Passmint. Voiding or deleting a pass removes it from the count immediately.
An install fires when a pass is added to a wallet; a removal fires when it is deleted. Together they are the only honest measure of whether a pass programme is growing, because issuing a pass says nothing about whether anyone kept it.