La WWDC è un investimento strategico?

Nel 2016 avevo un bug di Apple Pay sul web che mi bloccava da settimane. Era quasi impossibile riprodurlo con costanza, la documentazione scarseggiava e i forum non servivano a nulla. Ogni ora di debug era un’ora fatturabile persa, una consegna in ritardo e un cliente sempre più impaziente.

Ho portato il problema in un lab della WWDC. Quarantacinque secondi. L’ingegnere ha indicato subito la causa: un comportamento dell’SDK non documentato, che nessuno al di fuori di Apple avrebbe potuto conoscere.

Settimane bloccato. Quarantacinque secondi.

È questa la vera domanda sulla WWDC. Non «valgono il viaggio le sessioni?» — sono gratuite online da anni, questo lo abbiamo chiarito. La domanda è: quanto ti costa, in tempo, denaro e opportunità perse, non poter accedere a quel livello di informazioni al momento giusto?

E quante volte all’anno ti blocca un problema la cui risposta esiste — da qualche parte, in Apple — e in nessun altro posto?

Dal 2016 partecipo raramente alle sessioni: scelgo quelle che servono ai miei progetti, salvo quando presentano degli amici. Qui c’è Sanaa, che all’epoca faceva parte del team Photos.

A giugno, non a settembre

Ogni giugno Apple rimescola le carte del suo ecosistema. Nuove API, framework deprecati, paradigmi che cambiano. Alcune novità sono spettacolari — SwiftUI nel 2019, Apple Intelligence nel 2024. Altre fanno meno rumore, ma contano altrettanto: un cambiamento nel comportamento delle notifiche, un nuovo vincolo per le estensioni, una deprecazione che costringerà a riscrivere una parte dell’app entro diciotto mesi.

Chi capisce questi cambiamenti a giugno — il giorno del keynote, nelle sessioni del martedì, parlando nei corridoi con gli ingegneri Apple — ha tre mesi di vantaggio su chi leggerà la documentazione ufficiale a settembre, quando usciranno le versioni pubbliche.

Tre mesi per prototipare prima che la concorrenza sappia cosa è possibile.
Tre mesi per individuare ciò che si romperà nel codebase esistente prima che succeda in produzione, davanti agli utenti, nel momento peggiore.
Tre mesi per adattare l’architettura mentre gli altri sono ancora immersi negli sprint estivi.

Ho visto team perdere intere finestre perché avevano scoperto un cambiamento fondamentale a ottobre, proprio mentre cercavano di inviare un aggiornamento. Avevano costruito una funzionalità basandosi su un’ipotesi relativa a un’API che era cambiata a giugno. E nessuno li aveva avvertiti.

Altri erano pronti dal primo giorno delle release pubbliche, perché avevano prototipato a luglio, adattato ad agosto e testato a settembre. Tra le due situazioni spesso c’è solo una settimana di giugno.

Non è semplice monitoraggio del settore. È un vantaggio competitivo strutturale, che non si compra con un abbonamento a una newsletter.

Cosa ti danno i lab che nessun documento può darti

Il bug di Apple Pay del 2016 è solo uno dei tanti esempi. Il principio è sempre lo stesso.

Venti o trenta minuti con l’ingegnere Apple che ha scritto il codice — non chi ha letto la documentazione, chi lo ha scritto davvero — sono una risorsa che non esiste in nessun altro posto al mondo. Non su Stack Overflow, e di certo non su ChatGPT. Non nelle note di rilascio. Non nei forum Apple Developer. Da nessuna parte.

Arrivi con un problema specifico: un vincolo architetturale che non sai come aggirare, una domanda sull’intento di un’API il cui comportamento ti sfugge, un crash intermittente che non riesci a riprodurre ma che continua a comparire nei report. Esci con una risposta diretta, spesso in pochi minuti. A volte con un contatto a cui scrivere per approfondire. E a volte con la conferma che ciò che ritenevi impossibile si può fare, oppure che il limite contro cui lavori da sei mesi sparirà nella prossima versione.

I lab da remoto esistono dal COVID e sono davvero utili, soprattutto per domande specifiche preparate con cura. Ma in presenza la conversazione si allarga spontaneamente. L’ingegnere ti mostra qualcosa sullo schermo, cita un caso correlato che non avevi pensato di chiedere. Esci con informazioni che non avresti saputo cercare, perché non sapevi che esistessero. È una differenza di natura, non di grado.

La regola d’oro: porta domande specifiche.

I lab non sono sessioni di brainstorming (tranne forse i richiestissimi UI/UX Lab). Sono consulti chirurgici. Chi ne ricava di più arriva con un problema formulato bene e un contesto chiaro. Chi arriva vagamente in cerca di ispirazione, di solito esce deluso.

Download Station alla WWDC19

La reputazione si costruisce sotto gli occhi degli altri

Per una startup o un’agenzia che cerca sviluppatori iOS di livello, la WWDC è uno dei pochi posti al mondo in cui la reputazione si costruisce davanti alle persone giuste.

I migliori sviluppatori Apple — quelli che vuoi nel tuo team — non cercano lavoro su LinkedIn. Costruiscono relazioni nell’ecosistema e sanno benissimo chi è chi. Quali team si impegnano a esserci ogni anno, organizzano eventi collaterali, contribuiscono all’open source e condividono ciò che imparano in sessioni o articoli. Chi c’è con costanza e chi compare solo quando fa comodo.

Quella presenza non si trasforma in un’assunzione nella stessa settimana: non è questo lo scopo della WWDC. Ma si accumula nel corso delle edizioni e pesa davvero quando uno sviluppatore di talento deve scegliere tra la tua offerta e quella di qualcun altro. «Li conosco, li ho incontrati a Cupertino, sono seri»: segnali informali di questo tipo orientano decisioni su cui nessun processo HR può intervenire.

Per uno sviluppatore indipendente il meccanismo è ancora più diretto. La rete che costruisci alla WWDC non è un insieme di contatti LinkedIn che non chiamerai mai. È una trama di rapporti con persone che condividono gli stessi standard, gli stessi riferimenti tecnici e la stessa ossessione per un ecosistema esigente. Le collaborazioni più interessanti a cui ho lavorato sono nate da conversazioni non pianificate: in un corridoio del McEnery Convention Center, a cena a San José. Niente agenda, niente pitch, solo due sviluppatori che parlano di ciò che stanno costruendo.

L’argomento a cui pochi pensano

Essere alla WWDC è un segnale di posizionamento che pochi sviluppatori pensano di usare in modo esplicito con i clienti, eppure è uno dei più potenti.

In pratica, cosa cambia? Quando consigli un’architettura a un cliente e puoi dirgli «in un lab mi hanno confermato che questa API cambierà direzione l’anno prossimo; ecco cosa ho scoperto», non sei più un fornitore tecnico che ha letto qualche articolo. Hai accesso a informazioni che il team interno del cliente non possiede e probabilmente nemmeno gli altri suoi fornitori.

Questo vale soprattutto per le decisioni architetturali che devono durare anni. Un CTO che deve scegliere tra due approcci per un’app destinata alla produzione nel 2027 ha bisogno di qualcuno che sappia dove sta andando Apple, non solo dove si trovava all’ultima WWDC guardata in replica. La differenza tra un consiglio basato sulla documentazione pubblica e uno basato su una conversazione diretta con gli ingegneri che fanno evolvere la piattaforma è la differenza tra un fornitore e un partner.

E questo si traduce in valore. Non scrivendo «partecipante alla WWDC» sul sito, ma diventando la persona a cui pensano quando devono prendere una decisione tecnica importante.

I conti veri

Mettiamo i numeri sul tavolo. Una settimana alla WWDC per uno sviluppatore europeo: volo andata e ritorno Parigi–San Francisco (700 € con FrenchBee, fino a 5.000 € in business con Air France, a seconda di quando prenoti), hotel a Cupertino (da 1.300 a 1.700 € per la settimana: gli hotel vicino all’Apple Park sono pochi e si riempiono in fretta), spese quotidiane. Aggiungi una settimana di potenziale lavoro fatturabile sospeso. Totale: tra 3.500 e 5.000 €, secondo le condizioni.

È una cifra importante. Ecco come può avere senso, a seconda del profilo.

Per un freelance: la domanda non è «posso permettermelo?», ma «qual è il ritorno nei prossimi cinque anni?». Un solo incarico nato dai contatti della settimana — e succede regolarmente a chi si prepara bene — ripaga il viaggio e spesso anche molto di più. La rete costruita in più edizioni è un patrimonio professionale che aumenta di valore, non una spesa una tantum da mettere a bilancio.

Per un team di prodotto: il calcolo è diverso ma altrettanto favorevole. Mandare uno o due sviluppatori alla WWDC significa avere tre mesi di vantaggio sulla concorrenza, evitare i costosi bug di migrazione che colpiscono a ottobre chi non ha seguito le beta da giugno e tornare con una comprensione della roadmap Apple che nessun documento pubblico può offrire. Rispetto al costo di un mese di sviluppo buttato su un’ipotesi API sbagliata — e ne ho viste tante — il budget della WWDC è una scelta ovvia.

Per una startup: è anche un segnale verso l’esterno. I migliori team iOS sul mercato — quelli che vuoi assumere, con cui vuoi collaborare o che potrebbero consigliarti — sanno chi va alla WWDC e chi no. Non lo dicono apertamente, ma è un indicatore di quanto prendi sul serio l’ecosistema.

Ai clienti dico sempre questo: la WWDC non si giustifica come formazione con un ROI misurabile in tre mesi. È un investimento in relazioni, informazioni strategiche e posizionamento, con un orizzonte minimo di due o tre anni. Chi ci va una volta per «vedere com’è» ne ricava meno di chi partecipa regolarmente e costruisce nel tempo la propria presenza nell’ecosistema.

Una settimana senza preparazione rende quasi nulla

Va detto chiaramente, perché molte squadre cadono in questa trappola la prima volta.

Ho visto team andare alla WWDC ogni anno e tornare con pochi risultati concreti. Non perché la conferenza non valga la pena, ma perché non avevano domande precise da risolvere, problemi tecnici da portare ai lab o un obiettivo chiaro per la settimana. Seguivano sessioni che avrebbero potuto guardare dalla scrivania, bevevano birra al Duke of Edinburgh e tornavano con un bel ricordo e una nota spese.

La preparazione efficace comincia settimane prima della partenza. Bisogna scegliere le sessioni prioritarie — ce ne sono decine in contemporanea e non si può vedere tutto. Prenotare i lab la mattina stessa in cui aprono le iscrizioni: quelli più richiesti finiscono in pochi minuti. Individuare prima gli eventi della community, perché le serate migliori non sono necessariamente le più rumorose. E preparare una lista di problemi e domande specifici da risolvere durante la settimana, idealmente come team.

Una settimana alla WWDC ben preparata è una delle settimane più dense e produttive dell’anno. Una improvvisata è turismo tecnologico costoso, con il bel tempo californiano come bonus.

La domanda che dovresti farti davvero

Non «vale la pena andare alla WWDC?». È formulata male.

La domanda giusta è: quale decisione tecnica hai preso quest’anno basandoti su un’ipotesi rivelatasi sbagliata quando è arrivata la nuova versione di iOS? Quanti giorni di sviluppo ti è costata? Quante volte sei rimasto bloccato su un bug la cui soluzione esisteva — da qualche parte, in un lab della WWDC a cui non hai partecipato?

Perché questo è il costo reale del non andarci. Non il biglietto aereo che non hai comprato, ma le settimane perse su problemi che avevano una soluzione diretta. Le funzionalità consegnate tre mesi dopo rispetto al possibile. Le decisioni architetturali prese senza chiarezza, mentre la risposta esisteva a 9.000 chilometri di distanza, per chi aveva fatto lo sforzo di esserci.

Vuoi un’app incredibile — non media, non solo «fa il suo dovere», ma capace di arrivare in cima alle classifiche dell’App Store perché usa gli standard Apple più recenti fin dal giorno in cui vengono presentati ed è costruita da chi conosce l’ecosistema fin nei dettagli? Contattami.

Lavoro con imprenditori ambiziosi e team di talento per creare app iOS e macOS che contano. Dal 2011, dalla WWDC. Scrivimi direttamente.