¿Es la WWDC una inversión estratégica?

En 2016, llevaba semanas bloqueado por un error de Apple Pay en la web. Era imposible reproducirlo de forma fiable, la documentación era escasa y los foros no servían de nada. Cada hora dedicada a depurarlo era una hora facturable perdida, una entrega retrasada y un cliente cada vez más impaciente.

Expuse el problema en un laboratorio de la WWDC. Cuarenta y cinco segundos. El ingeniero señaló directamente la causa: un comportamiento no documentado del SDK que nadie ajeno a Apple podía conocer.

Semanas bloqueado. Cuarenta y cinco segundos.

Esa es la verdadera pregunta que hay que hacerse sobre la WWDC. No «¿merecen las sesiones el viaje?» —llevan años disponibles gratis en internet, eso ya está claro—, sino cuánto te cuesta, en tiempo, dinero y oportunidades perdidas, no tener acceso a ese nivel de información en el momento adecuado.

¿Y cuántas veces al año te bloquea un problema cuya respuesta existe —en algún lugar, dentro de Apple— y no está disponible en ningún otro sitio?

Desde 2016, rara vez he asistido a las sesiones; elegía cuidadosamente a cuáles ir en función de mis proyectos del momento, salvo cuando presentaban amigos. Aquí está Sanaa, que por entonces formaba parte del equipo de Photos.

Junio, no septiembre

Cada junio, Apple vuelve a barajar las cartas de su ecosistema. Nuevas API, frameworks obsoletos, paradigmas cambiantes. Algunos cambios son espectaculares —SwiftUI en 2019, Apple Intelligence en 2024—. Otros son más discretos, pero igual de trascendentes: un cambio de comportamiento en las notificaciones, una nueva restricción para las extensiones o una obsolescencia que obligará a reescribir parcialmente el código en un plazo de dieciocho meses.

Quienes entienden estos cambios en junio —el día de la keynote, en las sesiones del martes, en conversaciones de pasillo con ingenieros de Apple— llevan tres meses de ventaja a quienes leerán la documentación oficial en septiembre, cuando se publiquen las versiones públicas.

Tres meses para crear un prototipo antes de que la competencia sepa que es posible.
Tres meses para detectar qué va a fallar en el código existente antes de que falle en producción, ante los usuarios y en el peor momento posible.
Tres meses para adaptar la arquitectura mientras los demás siguen enfrascados en sus sprints de verano.

He visto a equipos perder oportunidades enteras porque descubrieron un cambio crítico en octubre, justo cuando intentaban enviar una actualización. Habían desarrollado toda una funcionalidad basándose en una suposición sobre una API que había cambiado en junio, y nadie se lo había dicho.

También he trabajado con otros que estaban preparados desde el primer día de las versiones públicas porque habían creado prototipos en julio, realizado adaptaciones en agosto y hecho pruebas en septiembre. La diferencia entre ambos suele reducirse a una semana de junio.

Esto no es un seguimiento pasivo del sector. Es una ventaja competitiva estructural, de las que no se pueden comprar con una suscripción a una newsletter.

Lo que te ofrecen los laboratorios y ningún documento puede darte

El error de Apple Pay de 2016 es solo un caso entre muchos. El principio es siempre el mismo.

Veinte o treinta minutos con un ingeniero de Apple que escribió el código —no alguien que leyó la documentación, sino alguien que escribió el código— son un recurso que no existe en ningún otro lugar del mundo. Ni en Stack Overflow ni, desde luego, en ChatGPT. Ni en las notas de la versión. Ni en los foros de Apple Developer. En ninguna parte.

Llegas con un problema concreto. Una restricción arquitectónica para la que no encuentras una solución alternativa. Una pregunta sobre la intención que hay detrás de una API cuyo comportamiento no logras comprender. Un fallo intermitente que no puedes reproducir, pero que sigue apareciendo en tus informes de errores. Y sales con una respuesta directa, a menudo en cuestión de minutos; a veces, con un nombre por si necesitas hacer un seguimiento; y, en ocasiones, con la confirmación de que aquello que creías imposible no lo es, de que la limitación que llevas seis meses intentando sortear desaparecerá en la próxima versión.

Los laboratorios remotos existen desde la COVID y aportan un valor real, sobre todo para preguntas concretas y bien preparadas. Pero, en persona, la conversación se amplía de forma natural. El ingeniero te enseña algo en su pantalla. Menciona un caso relacionado que no se te había ocurrido plantear. Sales de allí con información que no habrías sabido pedir porque ni siquiera sabías que existía. Es una diferencia cualitativa, no cuantitativa.

La regla de oro: acude con preguntas concretas.

Los laboratorios no son sesiones de lluvia de ideas (salvo quizá los muy solicitados UI/UX Labs). Son consultas quirúrgicas. Quienes más partido les sacan son quienes llegan con un problema bien formulado y un contexto claro. Quienes llegan con la vaga esperanza de encontrar inspiración suelen marcharse decepcionados.

Download Station en la WWDC19

La reputación se construye donde la gente está mirando

Para una startup o una agencia que busca contratar a desarrolladores de iOS de primer nivel, la WWDC es uno de los pocos lugares del mundo donde la reputación se construye ante las personas que importan.

Los mejores desarrolladores de Apple —los que quieres en tu equipo— no buscan trabajo en LinkedIn. Construyen su red dentro del ecosistema y saben perfectamente quién es quién. Qué equipos hacen el esfuerzo de acudir cada año. Cuáles organizan eventos paralelos, contribuyen a proyectos de código abierto y comparten lo aprendido en sesiones o publicaciones de blog. Cuáles están presentes de forma constante y no solo cuando les conviene.

Esa presencia no se traduce en contrataciones esa misma semana —no es para eso para lo que sirve la WWDC—. Pero se acumula a lo largo de varias ediciones y tiene un peso real cuando un desarrollador con talento debe elegir entre una oferta tuya y otra de otra empresa. «Los conozco, me he cruzado con ellos en Cupertino, van en serio»: ese tipo de señal informal influye en decisiones en las que ningún proceso de RR. HH. puede influir.

Para un desarrollador independiente, es aún más directo. La red que construyes en la WWDC no es una red de contactos de LinkedIn a los que nunca llamas. Es un entramado de relaciones con personas que comparten el mismo nivel de exigencia, los mismos referentes técnicos y la misma obsesión por un ecosistema exigente. Los encargos más interesantes en los que he trabajado comenzaron con conversaciones que no estaban previstas: en un pasillo del McEnery Convention Center, durante una cena en San José... Sin agenda ni discurso comercial, solo dos desarrolladores hablando de lo que están creando.

El argumento que a nadie se le ocurre utilizar

Estar en la WWDC es una señal de posicionamiento que pocos desarrolladores piensan en aprovechar explícitamente ante sus clientes y, sin embargo, es una de las más poderosas que existen.

Esto es lo que cambia en la práctica. Cuando asesoras a un cliente sobre una decisión de arquitectura y puedes decir «En un laboratorio me confirmaron que esta API cambiará de rumbo el año que viene; esto es lo que aprendí», dejas de ser un proveedor técnico más que investiga el sector a través de blogs. Eres alguien con acceso a información que su equipo interno no tiene y que probablemente tampoco tienen sus otros proveedores.

Esto resulta especialmente valioso para las decisiones de arquitectura que abarcan varios años. Un CTO que necesita elegir entre dos enfoques para una app que estará en producción en 2027 necesita a alguien que sepa hacia dónde se dirige Apple, no solo dónde estaba Apple en la última WWDC que vio en diferido. La diferencia entre un asesoramiento basado en documentación pública y otro basado en una conversación directa con los ingenieros que hacen evolucionar la plataforma es exactamente la diferencia entre un proveedor y un socio.

Y eso se traduce en valor. No por poner «Asistente a la WWDC» en tu sitio web, sino por ser la persona en la que todos piensan cuando hay que tomar una decisión técnica importante.

Las cifras reales

Pongamos las cifras sobre la mesa. Una semana de WWDC para un desarrollador europeo: vuelo de ida y vuelta París–San Francisco (700 € con FrenchBee o hasta 5000 € en clase Business con Air France, según cuándo reserves), hotel en Cupertino (entre 1300 y 1700 € por la semana; los hoteles cerca de Apple Park son escasos y se llenan rápido) y gastos diarios. A eso hay que sumar una semana sin facturar. En total: entre 3500 y 5000 €, según las circunstancias.

Es una cantidad considerable. Así se justifica, según el perfil.

Para un profesional independiente: la pregunta no es «¿puedo permitírmelo?», sino «¿qué rentabilidad obtendré durante los próximos cinco años?». Un solo proyecto surgido de los contactos de esa semana —y ocurre con frecuencia entre quienes preparan bien su semana— cubre el viaje y, por lo general, mucho más. La red de contactos construida a lo largo de varias ediciones es un activo profesional que se revaloriza con el tiempo, no un gasto puntual que amortizar.

Para un equipo de producto: las cifras son distintas, pero igual de favorables. Enviar a uno o dos desarrolladores a la WWDC significa comprar tres meses de ventaja sobre la competencia, evitar los costosos errores de migración que inevitablemente aparecen en octubre para quienes no siguieron las betas desde junio y volver con un conocimiento de la hoja de ruta de Apple que ningún documento público ofrece. Comparado con el coste de desperdiciar un mes de desarrollo por una suposición errónea sobre una API —y he visto muchas suposiciones erróneas sobre API—, el presupuesto para la WWDC es una decisión obvia.

Para una startup: también es una señal que se envía al exterior. Los mejores equipos de iOS del mercado —aquellos a los que quieres contratar, con los que quieres colaborar y que recomendarán tus servicios— saben quién va a la WWDC y quién no. No se dice de forma explícita, pero es un indicador del compromiso con el ecosistema que la gente observa y tiene en cuenta.

Lo que siempre digo a los clientes cuando surge la pregunta es esto: la WWDC no se justifica como una formación con un ROI medible a tres meses. Se justifica como una inversión en contactos, inteligencia estratégica y posicionamiento, con un horizonte mínimo de dos o tres años. Quienes van una vez para «ver cómo es» sacan menos partido que quienes asisten con regularidad y consolidan su presencia en el ecosistema con el tiempo.

Una semana sin preparar no aporta casi nada

Hay que decirlo con claridad, porque es una trampa en la que caen muchos equipos la primera vez.

He visto equipos asistir a la WWDC todos los años y volver con pocas cosas concretas. No porque la conferencia no fuera valiosa, sino porque no tenían preguntas específicas que resolver, problemas técnicos preparados para los laboratorios ni una intención clara para la semana. Vieron sesiones que podrían haber visto desde sus escritorios, bebieron cervezas en el Duke of Edinburgh y volvieron a casa con un bonito recuerdo y un informe de gastos.

La preparación eficaz de la WWDC comienza semanas antes de partir. Hay que priorizar las sesiones, porque hay decenas en paralelo y no puedes verlo todo. Hay que reservar los laboratorios la primera mañana, en cuanto se abra el plazo de inscripción, porque las plazas más solicitadas se agotan en cuestión de minutos. Hay que identificar de antemano los eventos de la comunidad, porque las mejores veladas no son necesariamente las más ruidosas. Y hay que preparar una lista de preguntas y problemas concretos que resolver durante la semana, el tipo de lista que elaboráis en equipo antes de salir.

Una semana de WWDC bien preparada es una de las semanas más intensas y productivas del año en el ámbito profesional. Una improvisada es turismo tecnológico caro, con el buen tiempo de California como extra.

La pregunta que realmente deberías hacerte

No «¿merece la pena ir a la WWDC?». Esa pregunta está mal planteada.

La pregunta correcta es: ¿qué decisión técnica tomaste este año basándote en una suposición que resultó ser errónea cuando se lanzó iOS? ¿Cuántos días de desarrollo te costó ese error? ¿Cuántas veces te bloqueó un error cuya solución existía en algún lugar, en un laboratorio de la WWDC en el que no estabas?

Porque ese es el verdadero coste de no ir. No el billete de avión que no compraste. Las semanas perdidas en problemas que tenían una solución directa. Las funcionalidades entregadas tres meses después de que fueran posibles. Las decisiones de arquitectura tomadas a ciegas cuando la claridad existía, a 9000 kilómetros de distancia, para quienes hicieron el esfuerzo de estar allí.

¿Quieres una app increíble —no una del montón, no una que «cumple su función», sino una que encabece las listas de la App Store porque adopta los últimos estándares de Apple en cuanto se presentan y está creada por alguien que conoce el ecosistema hasta el más mínimo detalle—? Ponte en contacto conmigo.

Trabajo con emprendedores ambiciosos y equipos con talento para crear apps para iOS y macOS que importan, desde 2011, desde la WWDC. Escríbeme directamente.