Apple Wallet gives businesses meaningful control over a loyalty pass, but it is not a blank canvas. You supply structured content and approved assets; Apple decides how Wallet arranges them on each device.
The best pass designs work with that constraint. They make the business recognizable, keep the current loyalty state easy to scan, and move detailed terms out of the way of the counter interaction.
Start with the pass style
Every Apple Wallet pass has a style that tells Wallet what kind of information it represents. Store cards are the natural fit for many loyalty and stored-value experiences. The style influences which fields and images are available and how Wallet prioritizes them.
Choosing the style is an information-architecture decision, not a visual preference. A pass that fights its style becomes harder to read and less predictable across iPhone and Apple Watch.
- Use a store-card structure for a reusable loyalty relationship
- Keep the most important live value in the field Wallet emphasizes
- Treat Wallet previews as approximations of platform-controlled rendering
Organize the visible fields
Wallet passes separate content into header, primary, secondary, auxiliary, back, and newer additional-information fields. The front should answer the counter questions quickly: whose program is this, what is the customer working toward, and what should staff scan?
For a store card, Apple documents a combined total of up to four secondary and auxiliary fields on the front. Text length still matters: Wallet can show fewer fields when values are too long. Field labels and values are separate, so keep both concise enough to survive smaller screens and localization.
| Field area | Good loyalty use | Common mistake |
|---|---|---|
| Header | A compact balance or status | A sentence that competes with the logo |
| Primary | Current progress or ready reward | Several unrelated metrics |
| Secondary | Customer or membership context | Repeating the primary value |
| Auxiliary | A concise supporting detail | Essential terms that may be de-emphasized |
| Back | Rules, support, links, and longer explanations | Hiding the only explanation of how to earn |
Use brand assets with restraint
Apple's store-card style supports an icon, logo, strip image, and barcode. It does not use the background-photo or thumbnail slots available to some other pass styles. Asset slots have defined roles, and Wallet can crop or omit imagery depending on device and context.
Use a simple, high-contrast logo and test it on a physical device. Do not bake essential text into an image: it will not localize, can become unreadable, and may not appear everywhere the pass appears.
- Choose foreground, background, and label colors with strong contrast
- Supply correctly scaled assets rather than relying on runtime resizing
- Keep logos away from the edges and verify transparent padding
- Test light and dark artwork against the actual pass background
Make the barcode operational
A loyalty barcode is only useful if staff can scan it reliably. Choose a supported barcode format and encode an identifier your system can validate. The human-readable fallback should help staff recover from a camera or screen problem without exposing a reusable secret.
Test the barcode on the devices and lighting conditions used at the counter. Screen brightness, damaged scanners, and small watch displays can change the real experience. Apple specifically notes that Code 128 is not displayed on Apple Watch, so it should not be the only format when watch scanning matters.
A visible membership number should not be treated as authorization for sensitive account recovery or ownership transfer. Keep scan identifiers scoped to the actions staff are allowed to perform.
Plan back fields and localization
Back fields are appropriate for reward rules, exclusions, support information, and useful links. They are not a substitute for clear front-of-pass progress. If a condition changes whether the customer receives a reward, surface it before the customer reaches the counter.
Pass packages can localize labels, values, and images. Write concise source copy first, then test translated strings rather than assuming they will fit the English layout.
Updates and relevance are separate decisions
Issued passes can be updated when loyalty state or supported program information changes. The pass should converge on the authoritative merchant record; a push is a signal to refresh, not the source of truth itself.
Wallet can also use locations to decide when a store card may be useful. Apple describes this relevance information as passive Lock Screen surfacing—not a promotional alert—and keeps the exact relevance radius platform-controlled. A location attached to a pass is therefore not a guarantee that a notification will appear.
Design for Apple Watch too
Compatible passes can appear on Apple Watch, but the watch presentation is more constrained than iPhone. Apple documents that the watch does not show a store card's strip image or back-of-pass information; Wallet rearranges the remaining fields and prioritizes the scannable code.
A pass is watch-ready when its identity, progress, and barcode still make sense after nonessential decoration disappears. Always test on supported hardware before advertising a specific watch layout.
What StayLoyal lets a merchant control
StayLoyal focuses merchant controls on program identity, Wallet-safe colors and logos, reward copy, stamp goals, customer-facing information, and lifecycle state. It maps those choices into supported Apple fields rather than promising unrestricted pixel-level design.
Apple controls the final Wallet interface. That distinction protects the design from depending on a rendering detail that can change across devices or platform releases.
Primary and supporting sources
Further reading
- Apple DeveloperWallet passes documentation
- Apple DesignWallet — Human Interface Guidelines
- Apple DeveloperCreating a store card pass
- Apple DeveloperPassKit package format reference
This guide explains product and platform behavior; it is not legal, financial, or accounting advice.