Wallet Pass vs Mobile App: When to Build and When to Issue a Pass

The instinct to build an app is understandable. Apps feel substantial. They are easy to describe to customers and easy to demo to stakeholders. But for most businesses considering a loyalty programme, membership card or event ticketing system, an app is the wrong tool — and the gap between what an app promises and what it costs to deliver is significant.

This article is a direct comparison. We will look at when you genuinely need an app, when a wallet pass does the job better and what the middle path looks like.

The real cost of building a mobile app

A native mobile app — meaning one that runs natively on iOS and Android, not a web wrapper — costs between £50,000 and £200,000 to build from scratch for a typical business application. That range reflects a two-platform build: you cannot ship an iOS app and leave Android customers out, or vice versa. You are effectively building and maintaining two separate codebases, or paying for a React Native or Flutter developer who can bridge both — which still carries a significant premium.

Before you ship a single line, App Store review takes one to three weeks for a first submission. Updates require review too — typically shorter, but Apple reserves the right to take its time. A time-sensitive feature change cannot go live the same day you write the code.

Push notification opt-in rates average around 60%. That means four in ten customers who download your app will never receive a push notification from it. For a channel you are spending £100,000 to build, that is a significant audience loss.

Ongoing maintenance is the cost that most projections understate. Every major iOS and Android release requires at minimum a test pass and often code changes. Deprecated APIs, new permission models, new screen sizes — each introduces maintenance work whether or not you are adding features. A realistic ongoing budget for a maintained native app is £10,000–£30,000 per year.

When a wallet pass is the right answer

Wallet passes are purpose-built for credentials. If what you are delivering to a customer is a card, a ticket, a voucher or a membership — something they hold and present — a wallet pass solves the problem better and faster than an app.

Loyalty cards. A customer adds a loyalty pass to their wallet once and it is there permanently. Points balance updates appear as push notifications. There is no app to download, no account to create, no barrier between the customer and the value you are offering.

Membership cards. Gym memberships, club cards, professional association credentials — any membership that requires the customer to present proof of status at a physical location is a natural wallet pass use case. The pass can display expiry date, tier and a unique barcode for scanning at the door.

Event tickets. QR code in Apple Wallet or Google Wallet, scannable at the gate, updateable if the event time changes. A push notification goes out the morning of the event with the venue address. No paper, no separate app.

Coupons and offers. A digital coupon in the wallet shows up automatically when the customer is near your store (via relevance-based location triggers). It can be updated with a new offer when the original expires. Redemption is tracked via barcode scan.

Appointment reminders. Healthcare providers, salons and service businesses can issue a pass for each appointment. A push notification fires the day before. Appointment details — time, location, clinician — live in the back fields of the pass.

In all these cases, the customer interaction is: receive pass, add to wallet, present when needed. There is no complex user journey. The wallet pass handles everything the use case requires.

When you genuinely need an app

There are use cases where a wallet pass is insufficient and an app is the right investment.

Complex multi-step user journeys. If customers need to browse a product catalogue, build a basket, enter delivery details and complete a payment — that is an ecommerce flow that belongs in an app or a responsive web application. A wallet pass does not have interactive UI elements beyond the information it displays and the links in its back fields.

Real-time communication. If your product requires a live chat interface, real-time booking availability or an interactive feed of content, a wallet pass cannot deliver that. It is a static document with a push notification channel — not a rich interactive surface.

Offline functionality. If your use case requires the app to work without a network connection — field service tools, offline maps, data capture in remote locations — a native app is necessary. Wallet passes update via the network; they do not execute logic offline.

Hardware access. Camera scanning, Bluetooth peripheral integration, biometric authentication flows, NFC writing — these require native app APIs. A wallet pass is read-only from a device perspective.

The middle path: wallet pass plus PWA

Many businesses find that their requirements split across these two columns. The credential use case — the loyalty card, the membership — is best served by a wallet pass. The transactional use case — browsing, booking, managing an account — belongs in a web interface.

A Progressive Web App (PWA) bridges this gap effectively. A PWA is a mobile-optimised website that can be added to the home screen, sends push notifications (via the Web Push API) and works offline via service workers. Build time is a fraction of a native app, and there is no App Store review. It is not identical to a native app — hardware access is limited and the home screen experience is slightly different — but for most business applications, it is sufficient.

The combined approach: issue a wallet pass for the credential and notification use case, link from the pass back fields to the PWA for account management and transactions. The customer gets the convenience of the wallet pass for the moment-of-need interactions and a full-featured web interface for everything else.

Cost comparison

The decision framework

Start with the question: what is the primary value your customer needs to carry with them? If the answer is a credential — a card, a ticket, a pass — start with a wallet pass. Build the app when you have proven demand for the interactive functionality it adds and a clear path to app store conversion.

Most businesses that come to Issuepass thinking they need an app discover that the wallet pass covers 80–90% of what their customers actually use. The remaining use cases can be handled with a link in the pass back fields to a web page.

Start free and have your first wallet pass live today — before an app build could even get through discovery.