Der Entwickler ist weg: Erste-Hilfe-Protokoll für verwaiste iOS-Apps

Der Entwickler antwortet nicht mehr. Die App läuft noch, aber niemand im Haus kann sie bauen, und das nächste erzwungene SDK-Update steht im Kalender. Die erste Frage, die mir Geschäftsführer in dieser Lage stellen, ist fast immer die falsche: "Können Sie den Code übernehmen?" Die richtige lautet: Wem gehören eigentlich die Konten?

Denn Code ist reproduzierbar. Ein Apple-Developer-Account, den eine Privatperson auf ihren Namen angelegt hat, ist es nicht.

Warum die Reihenfolge über den Schaden entscheidet

Eine verwaiste App stirbt selten am Code. Sie stirbt an Zugängen, die auf einen Namen laufen, der nicht mehr abhebt, und an Fristen, die weiterlaufen, während intern noch diskutiert wird.

Zwei Uhren ticken dabei unabhängig voneinander. Die erste ist die Mitgliedschaft im Apple Developer Program: Sie ist jährlich zu verlängern. Läuft sie aus, verschwindet die App aus dem App Store. Die zweite ist Apples Mindestanforderung an das SDK, mit dem eingereichte Builds gebaut sein müssen — sie wird regelmäßig angehoben. Wer bis dahin nicht bauen kann, kann nicht mehr releasen, auch keinen Ein-Zeilen-Bugfix.

Beide Uhren interessiert es nicht, ob Sie gerade einen Nachfolger suchen. Deshalb sind die ersten Schritte administrativ, nicht technisch.

Schritt 1: Prüfen, wer Inhaber des Apple-Kontos ist

Melden Sie sich in App Store Connect an und sehen Sie nach, welche Rolle Ihr Zugang hat und wer als Account Holder eingetragen ist. Diese Rolle ist die einzige, die Verträge unterschreiben, Bankdaten ändern und Rechte vergeben kann. Alles andere lässt sich davon ableiten, sie selbst nicht.

Prüfen Sie außerdem den Typ der Mitgliedschaft. Ein Organization-Account läuft auf die Firma und ist an eine D-U-N-S-Nummer gebunden — hier ist eine Übertragung ein Verwaltungsvorgang. Ein Individual-Account läuft auf eine Privatperson. Steht die App in einem Individual-Account des verschwundenen Entwicklers, ist das der ernsteste Befund des gesamten Protokolls, und er gehört an den Anfang, nicht ans Ende der Woche.

Was in diesem Fall bleibt, ist der von Apple vorgesehene Weg der App-Übertragung zwischen Accounts — der die Mitwirkung der Gegenseite voraussetzt — oder eine Neuveröffentlichung unter Ihrem eigenen Account. Neuveröffentlichung heißt: neue App-ID, verlorene Bewertungen, verlorene Ranking-Historie, und Bestandsnutzer, die kein Update bekommen, sondern eine zweite App installieren müssten. Das ist kein technisches Problem. Es ist der teuerste Posten in der Rechnung, und er entsteht Monate vor dem ersten Meeting mit einem neuen Entwickler.

Schritt 2: Zugänge einfrieren, bevor sie verfallen

Sammeln Sie in einem einzigen Dokument, was existiert und wem es gehört: App Store Connect, das Code-Repository samt Hosting-Anbieter, den Signaturschlüssel für Push-Benachrichtigungen, die Backend-Umgebung, Domains, Analytics- und Crash-Reporting-Konten sowie alle Drittanbieter-Dienste, die die App zur Laufzeit braucht.

Für jede Position notieren Sie nur zwei Dinge: auf welche E-Mail-Adresse sie läuft, und ob jemand im Unternehmen dort heute administrativen Zugriff hat. Eine Adresse auf einer Firmendomain ist zurückholbar. Eine private Adresse ist es nicht.

Der Punkt, der dabei am häufigsten übersehen wird, ist die Zahlungsmethode. Verlängerungen laufen oft über eine Kreditkarte, die dem Entwickler gehörte. Wenn die Abbuchung scheitert, fällt nicht nur ein Dienst aus, sondern still und ohne Vorwarnung mehrere gleichzeitig.

Schritt 3: Feststellen, ob sich die App überhaupt noch bauen lässt

Erst jetzt wird es technisch, und die Frage ist enger, als sie klingt. Nicht "ist der Code gut", sondern: Entsteht aus dem, was vorliegt, ein installierbarer Build?

Das scheitert erfahrungsgemäß an drei Stellen. Der Code ist unvollständig, weil Teile nur auf dem Rechner des Entwicklers lagen und nie im Repository ankamen. Die Abhängigkeiten lassen sich nicht mehr auflösen, weil externe Bibliotheken verschwunden oder in inkompatiblen Versionen nachgerückt sind. Oder die Signierung fehlt — Zertifikate und Profile hingen am persönlichen Konto und laufen aus.

Für dieses Ergebnis brauchen Sie keinen Wochenvertrag. Es ist eine klar begrenzte Frage, die sich in ein bis zwei Tagen beantworten lässt, und sie ist die Grundlage jeder seriösen Aufwandsschätzung. Genau deshalb steht in meiner Notfall-Stabilisierung eine 48-Stunden-Analyse vor dem Festpreis: Vorher wäre jede Zahl geraten.

Schritt 4: Den Zustand im Store lesen, bevor Sie etwas einreichen

Sehen Sie in App Store Connect nach, ob Einreichungen offen oder abgelehnt sind, ob Hinweise zu veralteten SDK-Anforderungen vorliegen und ob die Datenschutzangaben zur aktuellen Realität der App passen. Prüfen Sie die Bewertungen der letzten Wochen auf Absturzmuster nach einem iOS-Update.

Reichen Sie in dieser Phase nichts ein. Eine Ablehnung durch das App Review ist harmlos, wenn man sie erwartet hat, und ein Zeitverlust von Tagen, wenn man mit ihr die Lage sondieren wollte.

Der Teil, der wehtut

Dieses Protokoll priorisiert Verwaltung vor Technik, und dafür zahlen Sie mit Nerven. Die ersten Tage fühlen sich nach Stillstand an: Es wird nichts repariert, während die App weiter abstürzt. Ich habe das mehrfach als unbefriedigend erlebt, und es bleibt trotzdem die richtige Reihenfolge — eine perfekt stabilisierte App in einem Account, den Sie nicht kontrollieren, ist ein Vermögenswert, der jemand anderem gehört.

Der zweite Preis: Ein Teil dieser Arbeit ist unbezahlte Archäologie. Rekonstruieren, wem was gehört, ist mühsam und erzeugt kein sichtbares Ergebnis. Es lässt sich nur schwer als Fortschritt verkaufen, und niemand bekommt dafür Applaus.

Wo das Protokoll nicht greift

Es setzt voraus, dass mindestens ein Zugang mit administrativen Rechten im Unternehmen existiert — irgendein Weg hinein. Ist auch der weg und läuft der Account auf eine Privatperson, die nicht kooperiert, ist das kein Engineering-Fall mehr, sondern ein juristischer. Dann ist der erste Anruf der beim Anwalt, nicht bei mir.

Ebenso wenig greift es, wenn die App nur noch intern verteilt wird oder ohnehin abgekündigt ist. Dann gibt es kein Store-Risiko, das eine Eile rechtfertigt, und aus dem Notfall wird eine ruhige Migrationsentscheidung.

Der eigentliche Befund

Wenn ein Entwickler verschwindet und die App dadurch in Gefahr gerät, war der Fehler nicht der Weggang. Der Fehler war, dass ein einzelner Mensch Zugänge hielt, die dem Unternehmen gehören.

Deshalb endet die Stabilisierung bei mir mit einer dokumentierten Übergabe: Änderungen nachvollziehbar, Projekt lauffähig, Zugänge dort, wo sie hingehören. Nicht als Service-Argument, sondern weil sonst genau dieselbe Woche in zwei Jahren noch einmal stattfindet.