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

Original Article ↗ Hacker News Discussion ↗

Apple is reportedly adding a “Create a Pass” feature to iOS 27’s Wallet app, letting users turn arbitrary barcodes and QR codes—like gym memberships, library cards, and event tickets—into Wallet passes without needing a supporting app or developer-signed .pkpass file. Commenters welcome the convenience, especially for organizing everyday passes and getting auto-bright, easy-to-scan codes, but note Apple is only now matching long‑standing Google Wallet capabilities and effectively “sherlocking” a small ecosystem of third‑party pass-creator apps. The change also renews debate over Apple’s restrictive Wallet and NFC policies, developer lock‑in via certificates, and how much control big platforms should have over digital identity and tickets.

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.