Apple Wallet vs Google Wallet: the differences that affect your card

The five differences that cost you time

Both wallets hold the same object: one card, one barcode, one balance you change from your server. The differences that will actually cost you a day are narrow. Image geometry, how many fields render on the front, which barcode symbologies scan, how an update turns into a notification, and which properties are per-customer instead of per-program.

The plumbing differs more than the pixels do. Apple Wallet consumes a signed .pkpass bundle that you build and host, plus a small web service your server exposes so devices can pull new versions. Google Wallet consumes a JSON object you create and then PATCH over a REST API, and the Add to Google Wallet button is a signed JWT.

Everything below is something that breaks when you assume parity. These are the compromises we make in production at Waya, which mints both formats from one merchant design, plus a plain web card for phones that have neither wallet.

Image geometry: one export will not fit both

Apple's store card style draws a wide strip image behind the top of the card. The documented size is 375 x 123 points, which is 1,125 x 369 pixels at @3x. The logo is a rectangle in the top-left corner at 160 x 50 points (480 x 150 at @3x), and the icon is square at 29, 58, and 87 pixels. A store card renders strip.png and ignores thumbnail.png entirely, which is easy to lose an afternoon to.

Apple validates those numbers strictly. An image whose dimensions don't match makes iOS refuse the whole pass with "this card is not available" and nothing else. We resize every merchant upload server-side into each required slot rather than trusting the file we were handed.

Google's geometry differs in kind, not just in size. The logo is square and rendered as a circle, so a horizontal wordmark gets cropped to its middle. The hero image is a separate band of roughly 3:1 (Google's guidance has sat around 1,032 x 336) and it never sits behind text, so Google scale-fits your art and may crop the sides.

The compromise that survives both: no text baked into artwork, the meaningful part centered, and two logo files, a wide wordmark for Apple and a square mark for Google. Both vendors have revised their image guidance more than once, so check the current developer docs before you cut final art.

Fields: Apple counts slots, Google counts modules

An Apple pass has named slots: headerFields, primaryFields, secondaryFields, auxiliaryFields, and backFields on the reverse. A store card gets one primary value and, in practice, about four short fields around it before Apple truncates with an ellipsis. You don't get to decide what gets cut.

Google's loyalty object speaks a different vocabulary. There is loyaltyPoints (one balance with a short label), secondaryLoyaltyPoints, and textModulesData for everything else. There is no back of the card to hide detail behind; the extra modules scroll below the pass.

Color is the sharpest difference. Apple takes backgroundColor, foregroundColor, and labelColor as explicit values. Google takes one hexBackgroundColor and picks black or white text itself, from that color's luminance. Your brand color has to read well with whichever Google chooses, so test a mid-tone on a real phone before you commit; mid teals and oranges are where this goes wrong.

The practical answer is to pick the three things a customer needs at a glance, usually progress or balance, the reward, and their name, then let each platform place them. Anything longer belongs in Apple's back fields and Google's text modules, where truncation costs nothing.

Barcodes: Google's list is longer, so ship the intersection

Apple supports four formats: QR, PDF417, Aztec, and Code 128. They go in a barcodes array and the device uses the first one it supports. Apple's docs also flag that Code 128 isn't supported on Apple Watch, which matters if your regulars pay from a wrist.

Google supports those four plus the retail 1D symbologies Apple never added: EAN-8, EAN-13, UPC-A, ITF-14, Code 39, Codabar, and Data Matrix. It also has a text-only mode that shows a member number with no barcode at all. If your card has to scan at a supermarket lane, that gap is the whole story.

Unless a specific scanner forces your hand, use QR on both and stop thinking about it. That is what we do: the same QR payload on both platforms, read by an ordinary phone camera in the staff dashboard. No laser scanner, no POS integration, nothing wired into the till.

Put human-readable alt text under the code on both platforms (altText on Apple, alternateText on Google). A first name or a short member number lets a cashier finish the transaction by hand when a screen is cracked, dim, or buried in a thick case.

Updates and notifications: one lock screen, two mechanisms

Apple's update path is a pull, not a push of content. The pass carries a webServiceURL and an authenticationToken, the device registers with your server, you send an empty APNs push, and the device comes back to fetch the new .pkpass. You are running that web service, and it has to answer for every pass you have ever issued.

The lock-screen line comes from the pass, not from the push. A field with changeMessage: "%@" produces a banner when that field's value changes, and a field without one updates silently. If nothing in pass.json actually changed, iOS shows nothing at all, which is why the message text has to be written into a field on the new pass.

Google inverts this. You PATCH the loyalty object and the change lands without any push infrastructure of your own. To make noise, you POST a message to the object with messageType TEXT_AND_NOTIFY; we cap those at 80 characters of header and 240 of body because longer copy gets clipped.

Neither one is SMS. Both need wallet notifications enabled on the phone, and Google rate-limits notify-type messages, so treat wallet messages as high-quality best-effort reach rather than guaranteed delivery. For proximity reminders both accept up to 10 store locations, and on Waya those come from the Branches screen; a card's own address field is only text.

Per-customer or per-program: the asymmetry nobody warns you about

On Apple, nearly everything is per-pass. Each .pkpass is generated for one cardholder, so the background color, the strip image, and even a server-rendered picture of that customer's stamp row can be unique to them.

On Google, branding lives on the class and data lives on the object. hexBackgroundColor, programLogo, and heroImage are all class-level, shared by every cardholder in the program. Change one and you change it for all of them at once.

So a per-campaign color or a per-customer image is Apple-only unless you are willing to create a separate Google class per campaign. Dynamic state on Google has to be text instead: we render the stamp row as a string of glyphs inside the points balance, where Apple gets an actual image.

One more Google-only setting is worth knowing before launch: multipleDevicesAndHoldersAllowedStatus. Leave it unset and the first Google account to save an object owns it forever, so a second phone or a switched account hits a generic error screen. If your card is keyed to a phone number rather than a Google account, set MULTIPLE_HOLDERS. We learned that from a production incident, not from the docs.

Shipping one card to both, and the parts we don't do

Waya turns one merchant design into an Apple Wallet pass, a Google Wallet pass, and a web card for anything else. A customer scans the shop's QR code, types a first name and a mobile number, and taps once to add the card. No app download, no account, no password.

The limits, plainly: no POS or till integration and no hardware, so staff add stamps by scanning the customer's card on an ordinary phone. No SMS, because messages go out as wallet notifications only. The free plan stops at 100 customers and 100 wallet messages a month, and already-enrolled customers keep their cards and keep collecting after that stop. Growth is 85 SAR a month and Premium is 149 SAR a month.

Two calendar items no tutorial mentions. Apple's Pass Type ID certificate expires every year, and when it lapses, minting stops with no warning to anyone. Google requires an issuer account and puts your class through review before production traffic. Whoever owns your wallet integration should own both dates.