Un cliente, prima o poi, te lo chiede così: “Ma il badge su Apple Wallet, quanto ci mette il vostro sviluppatore a farlo?”
Pausa.
Ecco, questa è la domanda che mi fa capire in due secondi se davanti ho qualcuno che ha già provato a farlo o qualcuno che l’ha solo visto fare a un altro. Perché la risposta onesta è: nessun tempo, se lo sviluppatore lavora da solo. Zero. Non perché sia impossibile, ma perché la parte difficile non è mai stata lo sviluppo.
Ti spiego il motivo, che poi è la cosa che trovo davvero interessante di tutto questo tema.
Un biglietto e una chiave sembrano la stessa icona, non lo sono
Su Apple Wallet un biglietto del cinema e un badge che apre il tornello dell’ufficio hanno più o meno lo stesso aspetto: un rettangolo colorato, un logo, un tap. Da fuori, stessa famiglia. Da dentro, due mondi.
Il biglietto è un file firmato che il telefono mostra come un barcode. Fine della storia. Lo apri, lo scansioni, qualcuno lo convalida con un lettore ottico che potrebbe leggere anche un pezzo di carta stampato.
Il badge no. Il badge deve dialogare con una porta, in un tempo di reazione che l’utente percepisce come istantaneo, usando una chiave che nessuno, nemmeno chi ha scritto l’app, può leggere o copiare. Quella chiave vive isolata in un chip dedicato del telefono, non esce mai da lì, e il lettore fisico deve dimostrare ad Apple, prima ancora di essere venduto, di sapersi comportare bene con quel chip. Non è una differenza di dettaglio implementativo. È proprio un’altra categoria di prodotto, con un altro tipo di certificato e un altro processo di approvazione, completamente separato da quello che chiunque può ottenere aprendo un account sviluppatore in dieci minuti.
Il vero collo di bottiglia non si vede su Xcode
E qui arriva la parte da pre-sales, quella che mi tocca professionalmente. Quando qualcuno mette in cronoprogramma “integrazione Apple Wallet” come una riga di sviluppo tra le altre, sta sottovalutando esattamente la parte che richiede più tempo: non scrivere codice, ma passare per un processo di ammissione che Apple gestisce a mano, caso per caso, con tanto di verifica del modello di business prima ancora di guardare l’architettura tecnica.
E non basta nemmeno finire lì. Perché in parallelo c’è un secondo attore, spesso dimenticato nelle proposte commerciali: il produttore del lettore fisico installato sulla porta. Quel pezzo di hardware deve avere la sua certificazione, indipendente da chi emette il badge software. Due percorsi, due tempistiche, due interlocutori diversi che devono incastrarsi.
Se non sai che esistono entrambi, prometti una data che non reggerà. L’ho visto succedere. Non a me, per fortuna, ma l’ho visto.
Nemmeno essere gli stessi ti fa saltare la fila
E qui c’è un caso reale che puoi verificare da solo con una ricerca di due minuti, ed è anche il motivo per cui questo tema mi tocca più da vicino di altri: Zucchetti Axess, l’azienda per cui lavoro, è sia chi emette il badge software sia chi produce alcuni dei lettori certificati per leggerlo. Stessa azienda, due ruoli.
Ti aspetteresti che, internamente, questo tagli la burocrazia a metà. Stesso tetto, stesso team legale, stesso interlocutore commerciale verso il cliente finale: perché mai dovrebbero servire due permessi separati?
Perché Apple non certifica un’azienda. Certifica un ruolo. Il fatto che software e hardware escano dalla stessa sede non fonde i due processi di approvazione in uno: restano due percorsi distinti, con due verifiche distinte, anche quando dall’altra parte del tavolo Apple si trova sempre lo stesso interlocutore. È una scelta di processo che trovo onestamente sensata: la certificazione valuta cosa fa quel pezzo di software o quel pezzo di hardware, non chi lo possiede.
La parte che mi piace di più, da tecnico prestato al commerciale
C’è un dettaglio tecnico che trovo elegante, ed è questo: lo stesso identico principio di sicurezza (chiave generata in un chip isolato, mai esportabile, mai leggibile nemmeno dal sistema operativo) vale sia per il badge che ti apre l’ufficio sia per la chiave dell’auto che apri con lo stesso telefono. Stessa architettura, stesso ragionamento di fondo, applicato a un tornello o a una portiera. Chi ha progettato questo sistema non ha inventato una soluzione diversa per ogni caso d’uso: ha costruito un’unica base solida e ci ha appoggiato sopra tutto il resto.
È il tipo di scelta architetturale che, quando la spieghi bene a un cliente, cambia la conversazione. Non stai più vendendo “un badge digitale carino da mostrare”. Stai vendendo un modello di sicurezza che qualcun altro ha già stress-testato su scala globale, e che tu stai semplicemente configurando per il caso specifico di chi hai davanti. È una differenza enorme, in termini di fiducia, ed è anche il motivo per cui questi progetti, quando li spieghi con i tempi giusti, li vendi meglio.
Quindi, quanto ci mette davvero
Non lo so con esattezza, e onestamente diffido di chi te lo dice a scatola chiusa. Dipende da chi produce i lettori già installati, da quanto sono pronti a certificarsi, da quanto tempo Apple impiega a valutare il caso specifico. Quello che so è che il tempo vero si gioca prima ancora che qualcuno apra un editor di codice.
E se un domani qualcuno me lo richiede in ascensore, con quella faccia da “quindi quanto ci mette il vostro sviluppatore”, almeno ora so da dove iniziare a spiegarglielo.
Meno male.