iOS 27 is adding a 'Create a Pass' button to Apple Wallet

Original Article ↗ Hacker News Discussion ↗

Perceived benefits and use cases

  • Many see this as an obviously overdue feature; they’ve been using photos or screenshots of QR/barcodes for:
    • Event tickets, flights, buses/trains, museums, parks, gyms, libraries, grocery discounts, memberships, insurance, and IDs.
  • Being able to keep everything in Wallet reduces reliance on venue‑specific apps and clunky PDFs.
  • Some use Wallet mainly as a “double‑tap side button to pay or show ticket” workflow and want all scannable stuff there.

Why not just use photos/screenshots?

  • Wallet passes:
    • Are quickly accessible via the side‑button shortcut.
    • Auto‑brighten and show a crisp, in‑focus code.
    • Can surface proactively by time/location (e.g., at a venue or station).
  • Photos:
    • Get buried in the camera roll.
    • Can be awkward to open in front of others.
    • Work technically, but are seen as a clumsier UX.

Existing apps and platforms (“sherlocking”)

  • Multiple third‑party apps (Pass2U, Pass4Wallet, Wallet Creator, etc.) already create Wallet passes from barcodes/images, often with rich customization.
  • People expect those apps to be partially “sherlocked” but may still prefer them if Apple’s version is more limited.
  • Google Wallet has long supported generic cards/passes from barcodes; several commenters frame this as Apple merely catching up.

Apple’s constraints and developer experience

  • Historically, passes (.pkpass) had to be signed with an Apple Developer certificate, which:
    • Raised the bar for small venues, clubs, and libraries with no iOS devs.
    • Led to poor adoption despite passes being technically simple.
  • Some criticize Apple’s developer tooling and sparse PassKit/Wallet docs, and see this feature as Apple belatedly fixing its own UX/PKI choices.
  • NFC and some pass capabilities are gated behind special entitlements, which some devs find stifling.

Security, acceptance, and expiration issues

  • Concern: will businesses accept “homemade” passes?
    • Many note frontline staff and gates typically “just care if it scans.”
    • High‑value tickets (e.g., major concerts) often use rotating codes or NFC anyway.
  • Others worry about QR “sniping” from a distance, but this is already a risk with paper/standard QR tickets.
  • Auto‑archiving/expiration is widely disliked:
    • Passes (especially open returns and some rail/air tickets) often disappear early due to wrong timezones/expiries.
    • Users want manual control over archival and visibility.

Wallet UX: praise and criticism

  • Praise: tap‑to‑pay, real‑time updating boarding passes, public‑transport support, location‑aware surfacing, and helping reduce physical wallets.
  • Criticism:
    • Card stack UI makes multiple similar cards (e.g., same bank, different accounts/currencies) hard to distinguish; users want labels, icons, colors, or “stickers.”
    • No easy bulk removal of passes; animations feel slow.
    • Accessibility and gesture‑heavy navigation (no physical home button) are especially problematic for older or less tech‑savvy users.

Meta: AI article and framing

  • Some call the blog post obvious AI‑generated “slop” and link to a mainstream news source as the real origin.
  • The article’s framing—blaming developer inaction rather than Apple’s barriers—is criticized as misplacing responsibility.