Apple Pass Designer

Artigo original ↗ Discussão no Hacker News ↗

A nova ferramenta Pass Designer da Apple para criar passes do Wallet provoca reações mistas sobre conveniência, bloqueio e timing. Muitos saúdam uma forma mais fácil de pequenas empresas e locais emitirem bilhetes digitais e cartões de fidelização seguros — potencialmente reduzindo a dependência de apps proprietárias desajeitadas — enquanto outros criticam o requisito de macOS apenas e de versão mais recente, bem como o formato específico da Apple, por reforçarem o controlo do ecossistema em vez de promoverem padrões multiplataforma. Surgem preocupações mais amplas sobre a crescente dependência de acesso apenas por smartphone a eventos e serviços, bem como frustrações contínuas com usabilidade, privacidade e comportamento monopolista na bilhética digital.

Bilhética digital e experiência do utilizador

  • Muitos comentadores descrevem bilhetes apenas digitais a tornarem-se obrigatórios para concertos, desporto, transportes, etc., muitas vezes exigindo apps proprietárias.
  • Queixas: as apps são lentas, sobrecarregadas com rastreamento e má UX, e muitas vezes falham com pouca conectividade; passes do Wallet com capacidade offline são vistos como melhores.
  • Alguns locais recusam-se a imprimir bilhetes mesmo nas bilheteiras, empurrando tudo através da Ticketmaster ou semelhante.
  • Outros observam que PDFs e capturas de ecrã de códigos de barras normalmente funcionam bem e são mais simples.

Segurança, fraude e códigos dinâmicos

  • Vários discutem códigos QR/códigos de barras “animados” ou rolantes usados pela Ticketmaster e outros:
    • O objetivo: impedir capturas de ecrã estáticas, impor o uso na app e restringir transferências/revendas não autorizadas.
    • Faz-se uma comparação com códigos do tipo TOTP/2FA que usam chaves específicas do dispositivo.
  • Passes COVID e IDs digitais são citados como exemplos anteriores em que capturas de ecrã foram abusadas e depois contrariadas com códigos em movimento/rolantes.
  • Alguns perguntam por que é necessário um código em movimento se os sistemas de entrada podem simplesmente acompanhar se um bilhete foi usado; as respostas observam que muitos leitores estão offline ou minimamente ligados à rede.

Público-alvo e casos de uso

  • O Pass Designer é visto como destinado a pequenas empresas, locais, transportes, companhias aéreas e programas de fidelização que querem integração com o Wallet sem construir apps completas.
  • Divisão entre urbano e rural: pessoas em grandes cidades relatam passes do Wallet omnipresentes; outras dizem que ainda recebem sobretudo PDFs e opções de impressão.
  • Alguns utilizadores gostam de poder substituir apps desajeitadas “apenas com código de barras” (bibliotecas, cartões de fidelização) por passes do Wallet.

Bloqueio de plataforma, monopólio e padrões

  • Debate sobre se isto “reforça” o ecossistema da Apple:
    • Críticos argumentam que a Apple controla de forma apertada o acesso aos utilizadores de iOS e que os passes do Wallet são apenas da Apple, forçando trabalho paralelo com o Google Wallet e outros.
    • Defensores dizem que cada plataforma tem a sua própria wallet (Apple, Google, Samsung), e que isto é apenas a implementação da Apple.
  • Alguns gostariam de um padrão de passes multiplataforma promovido em conjunto pela Apple e pela Google; outros brincam que isso criaria apenas “mais um padrão”.

Design da ferramenta, requisitos do sistema operativo e acessibilidade

  • A beta do Pass Designer requer macOS 27; os comentadores questionam porquê:
    • Alguns sugerem que é sobretudo conveniência interna de bibliotecas partilhadas/QA e o desejo de apontar para as APIs mais recentes.
    • Outros veem isso como uma forma de empurrar atualizações de hardware/SO e ignorar Macs mais antigos.
  • Frustração por ferramentas para empresas (por exemplo, bibliotecas locais, pequenos locais) estarem limitadas a Macs modernos em vez de serem uma simples app web ou uma ferramenta multiplataforma.

Ferramentas existentes, funcionalidades do iOS 27 e alternativas

  • São mencionadas várias soluções já existentes:
    • Geradores PKPASS baseados na web e apps de terceiros que criam passes do Wallet a partir de códigos de barras.
    • A nova capacidade integrada do iOS 27 para utilizadores finais criarem passes simples diretamente no Wallet, embora com controlos de design limitados.
  • O Pass Designer ainda parece exigir um certificado de assinatura de Wallet/pass do Apple Developer Program, limitando o uso verdadeiramente “sem conta de developer”.

Detalhes da UX do Wallet: NFC, brilho e semântica

  • Alguns querem melhor controlo sobre áreas de código de barras:
    • Desejo de que o Wallet aumente apenas o brilho do retângulo do código de barras, usando HDR para evitar um brilho de ecrã inteiro “cegante”.
  • O uso de NFC para passes é referido como restrito e disponível apenas para parceiros selecionados; algumas lojas pequenas têm-no, mas muitas não.
  • Outros pedem suporte para códigos baseados em tempo (por exemplo, comportamento do tipo TOTP) e melhores definições semânticas das regiões do código de barras.

Importância percebida e momento

  • As opiniões divergem bastante:
    • Os apoiantes veem isto como uma ferramenta há muito necessária que pode aumentar a adoção do Wallet e reduzir a dependência de apps proprietárias horríveis.
    • Os céticos chamam-lhe algo trivial, “10 anos atrasado”, ou uma distração para uma empresa de um bilião de dólares que deveria focar-se na qualidade do software principal, pesquisa e IA.
  • Alguns notam que o desenvolvimento na era dos LLM torna este tipo de ferramenta de design semelhante a CRUD barato e simples, o que pode explicar a sua chegada agora.