Apple Wallet vs Google Wallet Passes: What's Different?

Your members carry both kinds of phones, so your pass program has to speak both wallets. Here's what actually differs — and what it means for your templates.

Format and layout

Apple Wallet uses signed .pkpass files with five fixed layouts and label-over-value fields. Google Wallet passes are cloud objects defined through Google's API, with rounded cards, a circular logo, and a hero image at the bottom. The same content fits both, but image sizes and field placement differ — Kemicard's Kemicard Studio maintains one design and renders each wallet correctly.

Delivery and installation

Apple installs a file; Google saves a link. In practice both are one tap, and a smart add-to-wallet link detects the device: iPhones get Add to Apple Wallet, Android gets Save to Google Wallet. One link per member covers everyone.

Updates and notifications

Both wallets support silent content updates and lock-screen messages, with quirks: Apple suppresses a push whose text matches the previous one and shows messages on the back of the card if Wallet is open; Google surfaces update notifications with its own timing. Location-triggered lock-screen reminders are an Apple strength; Google support is more limited today.

Sharing and fraud controls

Google Wallet can restrict a pass to the device that first saved it, auto-invalidating shared copies. On Apple, sharing is controlled at the template level. Either way, unique identifiers plus scan-time validation in Salesforce catch duplicates at the door.

The practical answer

Don't pick a wallet — design once and issue both. That's exactly what Kemicard does from a Salesforce record: one template, both formats, one add-to-wallet link, updates flowing to each platform's rules. See the full feature set.