Apple Wallet vs Google Wallet: What Is the Difference for Businesses?

Apple Wallet and Google Wallet both let businesses issue digital loyalty cards, event tickets, membership cards and coupons directly to a customer's smartphone. The customer experience on the surface looks similar: save a pass, see it on the lock screen, receive push notifications. Under the hood, the two platforms use entirely different technical models, distribution mechanisms and design systems. If you're building a wallet pass programme, you need to understand both.

In the UK and Europe, smartphone market share runs roughly 55% iOS to 45% Android. That split means issuing passes on only one platform leaves a significant portion of your audience unreachable. The practical answer for most businesses is to issue both — and a single Issuepass template generates passes for both platforms simultaneously.

Platform Overview

Apple Wallet is pre-installed on every iPhone and Apple Watch. It has been available since iOS 6 in 2012, which means the user base is mature and the habit of saving passes is well-established among iPhone users. Apple Wallet supports loyalty cards (store cards), event tickets, boarding passes, coupons and generic passes.

Google Wallet is Google's unified wallet app for Android, replacing Google Pay for non-payment use cases. It is pre-installed on most Android devices and available on the Play Store for others. Google Wallet supports loyalty, event tickets, boarding passes, offers and generic passes. In 2025 Google expanded wallet pass support to 50+ new countries, making it a genuinely global channel.

Technical Model: Files vs REST API

This is the most significant difference between the two platforms, and it shapes everything downstream.

Apple Wallet uses a file-based model. A pass is a .pkpass file — a ZIP archive containing a pass.json (the data and layout definition), image assets, a manifest.json (SHA1 hashes of all files) and a PKCS7 cryptographic signature. You generate this file on your server, sign it with a certificate issued by Apple, and serve it at a URL. The customer downloads the file and it is stored locally on their device.

Because the pass is a file on the device, updating it requires Apple's Push Notification Service (APNS). When you want to update a pass — change a points balance, push a notification — your server sends an APNS silent push to the device. The device wakes up, calls your server to check for updates, and downloads a fresh .pkpass file if the pass has changed. This architecture means you need to operate a web service that implements Apple's PassKit web service specification.

Google Wallet uses a REST API model. Passes are not files — they are server-hosted objects stored in Google's infrastructure. You create a pass class (template) and pass objects (instances) by making API calls to Google. Distribution is via a JWT-signed "Save to Google Wallet" URL. When the customer taps the URL, Google validates the token and associates the pass object with their Google account.

Updating a Google Wallet pass is simpler from an infrastructure perspective: you PATCH the pass object via the API and the change propagates to every device that has saved that pass automatically. You don't need to manage a push notification service for data updates — though you can send push messages via the addMessageRequest endpoint.

Design Differences

Apple Wallet passes have tightly defined layouts. Each pass type (store card, event ticket, boarding pass, coupon, generic) has prescribed image slots — a strip image across the top (store card, coupon), a thumbnail image (event ticket, boarding pass, generic), a logo, and an icon for notifications. You specify between one and four data fields in defined positions (primary, secondary, auxiliary, back). Customisation is possible within the template but you can't reposition elements or alter the fundamental layout.

Google Wallet passes give designers more flexibility, particularly for generic passes. The generic pass type supports a header, a hero image that spans the full width of the card, multiple text modules and a barcode. Loyalty passes have a defined structure but Google has extended the schema over time to allow richer branding. The overall aesthetic tends toward a card-like layout with more visual breathing room than Apple's denser formats.

Update Mechanism

Apple: Server pushes silent APNS notification → device polls your PassKit web service endpoint → server returns updated .pkpass if the pass has changed. This requires you to maintain a database of registered devices and push tokens.

Google: PATCH the pass object via REST API → change propagates to all devices holding that pass object automatically. No push token management required for data updates.

For businesses that need real-time pass updates (loyalty point balances, live event information), Google's model is architecturally simpler. Apple's model adds a layer of complexity but the result is equivalent from the customer's perspective.

Distribution Comparison

Apple Wallet passes are distributed as .pkpass file links. You can serve these in emails, as QR codes, via SMS or via a "Add to Apple Wallet" button on your website. Safari on iOS handles .pkpass files natively — tapping the link shows a pass preview.

Google Wallet passes are distributed via a "Save to Google Wallet" URL or button. Google provides a branded button asset. The URL contains the JWT payload that Google validates on the server side before saving the pass.

In practice, both platforms deliver a one-tap save experience from the customer's perspective. The distribution mechanics are different but the result is the same: a pass saved to the customer's wallet in under ten seconds.

Which Should You Choose?

Both. The only scenario in which you might choose one over the other is if your customer base is demonstrably concentrated on one platform. A business that serves exclusively iPhone users (rare but possible in certain demographics or geographies) might prioritise Apple Wallet. A business deploying passes in markets where Android dominates overwhelmingly might start with Google Wallet.

For most businesses — particularly those in the UK and Europe where the 55/45 iOS/Android split applies — issuing on both platforms is the correct decision. The incremental effort of supporting both is marginal when you use a platform that generates both pass types from a single template.

We built Issuepass to handle exactly this. Design your pass once in our editor. We generate and distribute both Apple Wallet .pkpass files and Google Wallet pass objects from that single source of truth. Updates, push notifications and analytics work across both platforms through the same dashboard.

Start free and issue passes to both Apple Wallet and Google Wallet from day one.