Ist die WWDC eine strategische Investition?

2016 hatte ich einen Apple-Pay-Webfehler, der mich seit Wochen aufhielt. Er ließ sich kaum zuverlässig reproduzieren, die Dokumentation war dünn und die Foren halfen nicht weiter. Jede Stunde Debugging war eine verlorene abrechenbare Stunde, eine verspätete Lieferung und ein ungeduldiger werdender Kunde.

Ich schilderte das Problem in einem WWDC-Lab. 45 Sekunden. Der Ingenieur zeigte direkt auf die Ursache: ein undokumentiertes SDK-Verhalten, das niemand außerhalb von Apple hätte kennen können.

Wochenlang blockiert. 45 Sekunden.

Das ist die eigentliche Frage zur WWDC. Nicht: „Lohnen sich die Sessions die Reise?“ Sie sind seit Jahren kostenlos online, das wissen wir. Sondern: Was kostet es dich an Zeit, Geld und verpassten Chancen, im richtigen Moment keinen Zugang zu diesem Wissen zu haben?

Und wie oft im Jahr blockiert dich ein Problem, dessen Lösung irgendwo bei Apple existiert – und sonst nirgends?

Seit 2016 besuche ich nur selten Sessions. Ich suche gezielt die aus, die zu meinen aktuellen Projekten passen – außer Freunde halten einen Vortrag. Hier ist Sanaa, damals Teil des Photos-Teams.

Juni, nicht September

Jeden Juni mischt Apple die Karten im eigenen Ökosystem neu. Neue APIs, eingestellte Frameworks, veränderte Paradigmen. Manche Änderungen sind spektakulär – SwiftUI 2019, Apple Intelligence 2024. Andere sind leiser, aber genauso folgenreich: ein verändertes Verhalten bei Benachrichtigungen, eine neue Einschränkung für Extensions oder eine Deprecation, die in 18 Monaten eine teilweise Neuentwicklung erzwingt.

Wer diese Änderungen im Juni versteht – am Tag der Keynote, in den Sessions am Dienstag, im Gespräch auf dem Flur mit Apple-Ingenieuren –, hat drei Monate Vorsprung vor denen, die erst im September zur Veröffentlichung die offizielle Dokumentation lesen.

Drei Monate, um einen Prototyp zu bauen, bevor die Konkurrenz weiß, dass es möglich ist.
Drei Monate, um herauszufinden, was im bestehenden Code kaputtgehen wird, bevor es in der Produktion und vor den Nutzern passiert – zum denkbar schlechtesten Zeitpunkt.
Drei Monate, um die Architektur anzupassen, während andere noch mitten in ihren Sommer-Sprints stecken.

Ich habe Teams erlebt, die ganze Zeitfenster verpasst haben, weil sie eine wichtige Änderung erst im Oktober entdeckten – genau dann, wenn sie ein Update einreichen wollten. Sie hatten ein ganzes Feature auf einer API-Annahme aufgebaut, die sich im Juni geändert hatte. Niemand hatte es ihnen gesagt.

Andere Teams waren am ersten Tag der öffentlichen Releases bereit, weil sie im Juli Prototypen gebaut, im August angepasst und im September getestet hatten. Zwischen beiden liegt oft eine Woche im Juni.

Das ist keine passive Marktbeobachtung. Es ist ein struktureller Wettbewerbsvorteil – und den kann man nicht mit einem Newsletter-Abo kaufen.

Was Labs bieten, das kein Dokument kann

Der Apple-Pay-Fehler von 2016 ist nur ein Beispiel. Das Prinzip ist immer dasselbe.

20 oder 30 Minuten mit einem Apple-Ingenieur, der den Code geschrieben hat – nicht nur die Dokumentation gelesen, sondern den Code geschrieben –, sind eine Ressource, die es nirgendwo sonst auf der Welt gibt. Nicht auf Stack Overflow, ganz sicher nicht bei ChatGPT. Nicht in den Release Notes. Nicht in den Apple-Developer-Foren. Nirgends.

Du kommst mit einem konkreten Problem: einer Architektur-Einschränkung, für die du keine Lösung findest; einer Frage nach der Absicht hinter einer API, deren Verhalten du nicht verstehst; einem sporadischen Absturz, den du nicht reproduzieren kannst, der aber in den Crash-Reports immer wieder auftaucht. Du gehst mit einer direkten Antwort – oft nach wenigen Minuten. Manchmal bekommst du einen Namen für die Rückfrage. Und manchmal erfährst du, dass etwas, das du für unmöglich gehalten hast, doch geht oder dass die Einschränkung, mit der du seit sechs Monaten arbeitest, in der nächsten Version verschwindet.

Remote-Labs gibt es seit COVID. Sie sind wertvoll, vor allem mit gut vorbereiteten, konkreten Fragen. Vor Ort entwickelt sich das Gespräch natürlicher weiter. Der Ingenieur zeigt etwas auf seinem Bildschirm, erwähnt einen angrenzenden Fall, an den du nicht gedacht hast. Du gehst mit Erkenntnissen, nach denen du gar nicht hättest fragen können, weil du nicht wusstest, dass es sie gibt. Das ist ein qualitativer Unterschied, kein gradueller.

Die goldene Regel: Komm mit konkreten Fragen.

Labs sind keine Brainstorming-Sessions (mit Ausnahme vielleicht der sehr begehrten UI/UX-Labs). Es sind chirurgische Beratungen. Am meisten holen diejenigen heraus, die mit einem gut formulierten Problem und klaren Rahmenbedingungen kommen. Wer vage auf Inspiration hofft, geht meist enttäuscht wieder.

Download Station auf der WWDC19

Reputation entsteht dort, wo andere sie sehen

Für ein Start-up oder eine Agentur, die erfahrene iOS-Entwickler sucht, ist die WWDC einer der seltenen Orte, an denen sich Reputation vor den richtigen Leuten aufbaut.

Die besten Apple-Entwickler – die, die du im Team haben willst – suchen nicht auf LinkedIn nach Jobs. Sie knüpfen ihre Kontakte im Ökosystem und wissen genau, wer dazugehört. Welche Teams sich jedes Jahr die Mühe machen zu kommen. Wer Side-Events organisiert, Open-Source-Projekte unterstützt und Erkenntnisse in Sessions oder Blogbeiträgen teilt. Wer regelmäßig da ist und nicht nur, wenn es gerade bequem passt.

Diese Präsenz führt nicht in derselben Woche zu Einstellungen – dafür ist die WWDC nicht da. Aber über mehrere Ausgaben hinweg sammelt sie sich an und zählt, wenn ein talentierter Entwickler zwischen deinem Angebot und dem eines anderen wählen muss. „Ich kenne die, ich bin ihnen in Cupertino begegnet, die sind ernst zu nehmen“ – solche informellen Signale beeinflussen Entscheidungen, auf die kein HR-Prozess Zugriff hat.

Für unabhängige Entwickler ist es noch direkter. Das Netzwerk auf der WWDC besteht nicht aus LinkedIn-Kontakten, die man nie anruft. Es sind Beziehungen zu Menschen mit denselben Qualitätsansprüchen, technischen Referenzen und derselben Begeisterung für ein anspruchsvolles Ökosystem. Die interessantesten Aufträge, an denen ich gearbeitet habe, begannen mit ungeplanten Gesprächen – in einem Flur des McEnery Convention Center oder beim Abendessen in San José. Keine Agenda, kein Pitch, nur zwei Entwickler, die über ihre Projekte sprechen.

Das Argument, an das kaum jemand denkt

Auf der WWDC dabei zu sein, ist ein Positionierungssignal, das nur wenige Entwickler ihren Kunden gegenüber bewusst einsetzen – obwohl es eines der stärksten ist.

Was ändert sich konkret? Wenn du einem Kunden eine Architekturentscheidung empfiehlst und sagen kannst: „Im Lab wurde mir bestätigt, dass sich diese API nächstes Jahr anders entwickeln wird. Das habe ich erfahren“, bist du nicht mehr irgendein technischer Dienstleister, der Branchenbeiträge liest. Du hast Zugang zu Informationen, die das interne Team des Kunden nicht hat – und wahrscheinlich auch seine anderen Anbieter nicht.

Das ist besonders wertvoll bei Architekturentscheidungen, die mehrere Jahre tragen müssen. Ein CTO, der zwischen zwei Ansätzen für eine App wählen muss, die 2027 in Produktion geht, braucht jemanden, der weiß, wohin Apple steuert – nicht nur, was in der letzten WWDC-Wiederholung zu sehen war. Der Unterschied zwischen Rat auf Basis öffentlicher Dokumentation und Rat nach einem direkten Gespräch mit den Ingenieuren, die die Plattform weiterentwickeln, ist der Unterschied zwischen Dienstleister und Partner.

Und das schafft Wert. Nicht, indem man „WWDC-Teilnehmer“ auf die Website schreibt, sondern indem man die Person wird, an die andere denken, wenn eine wichtige technische Entscheidung ansteht.

Die echte Rechnung

Legen wir die Zahlen auf den Tisch. Eine WWDC-Woche für einen Entwickler aus Europa: Hin- und Rückflug Paris–San Francisco (700 € mit FrenchBee bis 5.000 € in der Business Class von Air France – je nachdem, wann man bucht), Hotel in Cupertino (1.300 bis 1.700 € für die Woche; Hotels beim Apple Park sind knapp und schnell ausgebucht), tägliche Ausgaben. Dazu kommt eine Woche möglicher abrechenbarer Arbeit, die pausiert. Insgesamt: zwischen 3.500 und 5.000 €, je nach Umständen.

Das ist viel Geld. So kann es sich je nach Profil lohnen.

Für Selbstständige: Die Frage ist nicht „Kann ich mir das leisten?“, sondern „Wie hoch ist der Ertrag über die nächsten fünf Jahre?“ Ein einziger Auftrag, der aus den Kontakten dieser Woche entsteht – und das passiert regelmäßig, wenn man gut vorbereitet ist –, bezahlt die Reise und meist noch deutlich mehr. Das Netzwerk aus mehreren Ausgaben ist ein beruflicher Vermögenswert, der mit der Zeit wächst, kein einmaliger Kostenpunkt.

Für ein Produktteam: Die Rechnung sieht anders aus, geht aber ebenso auf. Ein oder zwei Entwickler zur WWDC zu schicken bedeutet: drei Monate Vorsprung vor der Konkurrenz, weniger teure Migrationsfehler im Oktober bei Teams, die den Betas seit Juni nicht gefolgt sind, und ein Verständnis von Apples Roadmap, das kein öffentliches Dokument vermittelt. Verglichen mit den Kosten eines Monats Entwicklungszeit, der wegen einer falschen API-Annahme verloren geht – und solche Annahmen habe ich oft genug gesehen –, ist das WWDC-Budget eine klare Sache.

Für ein Start-up: Es ist auch ein Signal nach außen. Die besten iOS-Teams am Markt – die, die du einstellen oder als Partner gewinnen willst und die deine Dienste empfehlen könnten – wissen, wer zur WWDC fährt und wer nicht. Das sagt niemand ausdrücklich, aber es gilt als Zeichen dafür, wie ernst jemand das Ökosystem nimmt.

Wenn Kunden mich danach fragen, sage ich immer: Als Weiterbildung mit messbarem ROI innerhalb von drei Monaten rechnet sich die WWDC nicht. Sie rechnet sich als Investition in Netzwerk, strategische Informationen und Positionierung – mit einem Horizont von mindestens zwei bis drei Jahren. Wer einmal hingeht, um „zu sehen, wie es ist“, nimmt weniger mit als jemand, der regelmäßig kommt und sich Schritt für Schritt im Ökosystem etabliert.

Eine unvorbereitete Woche bringt fast nichts

Das muss man klar sagen, denn viele Teams tappen beim ersten Mal in diese Falle.

Ich habe Teams gesehen, die jedes Jahr zur WWDC fahren und kaum etwas Konkretes mit nach Hause bringen. Nicht, weil die Konferenz wertlos wäre, sondern weil sie keine gezielten Fragen und technischen Probleme für die Labs vorbereitet hatten und ohne klares Wochenziel ankamen. Sie schauten Sessions, die sie auch am Schreibtisch hätten sehen können, tranken Bier im Duke of Edinburgh und kamen mit einer schönen Erinnerung und einer Spesenabrechnung zurück.

Gute Vorbereitung beginnt Wochen vor der Abreise. Sessions priorisieren – denn Dutzende laufen parallel und man kann nicht alles sehen. Labs buchen, sobald die Anmeldung am ersten Morgen öffnet, denn die gefragtesten Termine sind in Minuten weg. Community-Events vorher auswählen, denn die besten Abende sind nicht unbedingt die lautesten. Und eine Liste konkreter Fragen und Probleme erstellen, die man während der Woche lösen will – am besten gemeinsam als Team.

Eine gut vorbereitete WWDC-Woche ist eine der fachlich dichtesten und produktivsten Wochen des Jahres. Eine improvisierte Woche ist teurer Tech-Tourismus mit gutem kalifornischem Wetter als Bonus.

Die Frage, die du dir wirklich stellen solltest

Nicht: „Lohnt sich die WWDC?“ Das ist die falsche Frage.

Die bessere lautet: Welche technische Entscheidung hast du dieses Jahr auf Basis einer Annahme getroffen, die sich mit der Veröffentlichung des neuen iOS als falsch herausgestellt hat? Wie viele Entwicklungstage hat dich dieser Fehler gekostet? Wie oft hingst du an einem Bug fest, dessen Antwort es gab – irgendwo, in einem WWDC-Lab, in dem du nicht warst?

Denn das sind die tatsächlichen Kosten des Fernbleibens. Nicht das Flugticket, das du nicht gekauft hast. Sondern die Wochen, die du mit Problemen verloren hast, für die es eine direkte Lösung gab. Die Features, die du drei Monate später ausgeliefert hast, als es möglich gewesen wäre. Die Architekturentscheidungen im Nebel, obwohl Klarheit existierte – 9.000 Kilometer entfernt, für alle, die hingefahren sind.

Du willst eine außergewöhnliche App bauen – nicht durchschnittlich, nicht nur „gut genug“, sondern eine, die die App-Store-Charts anführt, weil sie Apples neueste Standards sofort nutzt und von jemandem entwickelt wird, der das Ökosystem bis ins Detail versteht? Dann melde dich.

Ich arbeite mit ambitionierten Gründern und talentierten Teams an iOS- und macOS-Apps, die etwas bewegen – seit 2011, seit der WWDC. Schreib mir direkt.