Wallet Pass vs Mobile App: Which Should You Build?

For most loyalty cards, memberships, coupons and tickets, a wallet pass beats a custom mobile app: customers add it in two taps with nothing to download, it sits in the Apple Wallet or Google Wallet already on their phone, and you avoid building, publishing and maintaining an app. Build an app when the experience itself needs custom screens, in-app purchases, rich browsing or deep device features that a pass cannot do. This guide compares the two on the things that decide the choice: customer friction, what each can do, effort, upkeep and risk.

What each one is

A wallet pass is a card saved in the wallet that ships with the phone. It shows a design, a few fields and a barcode, can be updated after install, and can show lock-screen messages. You design it and issue it; Apple and Google provide the wallet.

A mobile app is software the customer must find in the App Store or Google Play, download, open and sign in to. You build it (or commission it), submit it for store review and maintain it for each operating system release.

Customer friction

The biggest practical difference is the path from "interested" to "has my card".

• Pass: scan a QR code or tap a link, fill in a short form, tap to add. No store visit, no account password, no storage space used for an app.
• App: open the store, search, download, open, register, then use. Each step loses people, and the customer must care enough about your brand to give it a home-screen slot.

A pass also lives where customers already look: the wallet, and the lock screen when you set it up that way. Our help article on wallet pass vs loyalty app and the page on whether customers need an app cover this from the buyer's side.

What each can do

Passes are deliberately narrow. Apple and Google define the fields, layout and behaviour, which is why they are fast to launch and consistent for customers. If you need something outside that frame, an app (or a web app) is the answer.

Effort and upkeep

Building a pass with a platform is a design task, not an engineering project: pick a template, upload a logo, set colours, publish. The first guide in this series walks through it. Building passes by hand is more work (certificates, signing, an update service) but still far smaller than an app.

Building an app includes design, development for iOS and Android, a backend, store listings, review cycles, crash monitoring and updates every time an operating system changes. Even a modest app is an ongoing commitment rather than a one-off purchase, and it needs someone who owns it long-term.

We do not quote figures here because costs vary widely by scope and supplier. Ask for a fixed-scope quote for both options and compare like with like, including the first two years of upkeep.

Risk and ownership

• Store dependency: an app lives under App Store and Google Play rules and review. A pass lives in the wallets under Apple's and Google's pass rules, which are narrower but stable.
• Data: with either, you hold customer data. Check where it is stored and whether you can export it. On Shakewell Wallet every plan includes a CSV export of passholders (help: export customer data).
• Lock-in: a pass is portable only if your platform lets you export customers and issue new passes elsewhere. Ask before you commit.

A worked example

Take a cafe with a ten-stamp card. As a pass: the owner picks a stamp-card template, uploads a logo, prints a QR code for the counter and staff scan the card to add each stamp. A customer who scans on Monday has a working card by Monday afternoon. As an app: the owner needs screens for sign-in, a card, a map and settings, a backend that stores stamps, two store listings and someone to fix it when a phone update breaks it. The customer has to leave the cafe's counter, go to a store and wait for a download. The app can do more, but nothing in a ten-stamp scheme needs more.

When a pass is the right choice

• You run a loyalty, stamp, membership, coupon, gift card or event ticket scheme.
• Customers use you in person, at a counter, door or event, and need to show a code.
• You want to launch in days or weeks and keep running costs predictable. Shakewell Wallet plans are flat monthly with no per-pass fees; see pricing.
• You have no engineering team, or you want yours working on your core product.

When an app is the right choice

• The product is the app: ordering, browsing a catalogue, booking, content.
• You need features passes do not support, such as in-app payments or custom workflows.
• You have the budget and team to run an app for years.

The option many businesses choose: both, in order

You do not have to pick once. A common path is to launch a pass first, learn what customers actually use, and add an app later only if the demand for custom features is real. A pass can also point customers to a web page or app for the parts it cannot do. Starting with a pass costs little and does not close off the app.

A quick decision test

Answer these three questions:

1. Is the customer's main task "show a code and collect or spend something"? If yes, lean towards a pass.
2. Do you need screens beyond a card (menus, checkout, search)? If yes, you need an app or web app as well.
3. Can you commit to maintaining software for years? If no, do not start with an app.

If you want to see what a pass looks like before deciding, the free templates are a quick way to preview one, and the features page lists what a pass can do on Shakewell Wallet.

Common questions

Will customers actually use a wallet pass? That depends on how you introduce it. A visible QR code at the counter and a staff member who mentions it make the difference. We do not publish usage statistics because they vary by business.

Is a pass less secure than an app? Neither is automatically more secure. A pass is signed, so tampering is detectable, and the barcode should encode an ID rather than sensitive data.

Can a pass replace a plastic loyalty card? Yes; see replace plastic cards.