App-Übergabe: Schlüssel und Konten

Der Anruf kommt meist so: Die Agentur von damals gibt es nicht mehr, oder der Entwickler ist nicht mehr erreichbar, und die App soll ein Update bekommen. Der Quellcode ist da, im Vertrag stand ja, dass er dem Kunden gehört. Und dann stellt sich heraus, dass der Quellcode das kleinste Problem ist. Denn eine App besteht aus mehr als Code, und die anderen Teile stehen in keinem Vertrag: der Schlüssel, mit dem sie signiert wurde, das Konto, unter dem sie im Store liegt, der Push-Schlüssel, das Firebase-Projekt, die Zertifikate.

Dieser Beitrag ist die Liste dessen, was bei einer App dem Betrieb gehören muss, mit dem Grund, warum jedes einzelne Stück fehlen kann und was dann passiert. Und er beschreibt die Übergabemappe, die ich bei jedem Projekt anlege, damit der Betrieb nach meinem Ausfall in einer Stunde weiterarbeiten kann, mit wem auch immer.

Die wichtigste Übergabefrage lautet nicht: „Haben wir den Quellcode?" Sondern: „Kann morgen ein anderer Entwickler die App bauen, signieren, veröffentlichen und betreiben, ohne den bisherigen Dienstleister anzurufen?" Wenn die Antwort Nein ist, ist die Übergabe nicht vollständig.

Für Entscheider: Worum es geht

• Bei älteren Android-Apps ohne Play App Signing kann ein verlorener Signaturschlüssel bedeuten, dass die bestehende App nicht mehr aktualisiert werden kann. Bei Play App Signing verwaltet Google den eigentlichen App-Signing-Key; ein verlorener Upload-Key lässt sich ersetzen. Wer den alten Schlüssel heute noch hat, kann heute umstellen.
• Das Apple-Entwicklerkonto sollte dem Auftraggeber gehören, nicht der Agentur. Übertragungen zwischen Konten sind möglich, brauchen aber Vorlauf und bei manchen Diensten Nacharbeit.
• Zur App gehören außerdem: Push-Schlüssel, Firebase- oder Cloud-Projekte, Domain-Dateien, Zertifikate, Build-Umgebung, Drittdienst-Zugänge.
• Die Lösung ist keine Rechtsfrage, sondern eine Mappe: alle Zugänge und Schlüssel beim Betrieb, dokumentiert, getestet, mit einer Zweitperson, die sie kennt.
• Das gilt für jede Beauftragung, auch für meine. Ich baue die Mappe von Anfang an, weil sie der Beweis dafür ist, dass die App wirklich dem Kunden gehört.

Der Android-Schlüssel: Bei alten Apps kann ein Verlust endgültig sein

Jede Android-App ist mit einem kryptografischen Schlüssel signiert, der in einer Datei liegt, dem Keystore. Android installiert ein Update nur, wenn es mit demselben Schlüssel signiert ist wie die installierte Version. Das ist ein Sicherheitsmerkmal: Niemand kann eine fremde App durch ein Update ersetzen. Es hat aber eine Kehrseite, die Betrieben erst auffällt, wenn es zu spät ist: Ist bei einer App ohne Play App Signing der Signaturschlüssel weg, kann niemand mehr ein Update der bestehenden App bauen. Nicht die alte Agentur, nicht die neue, nicht Google. Die App im Store lässt sich dann nur noch ersetzen, durch eine neue App mit neuem Paketnamen, die alle Nutzer neu installieren müssen, ohne Bewertungen, ohne Historie, und auf den Geräten liegt die alte daneben.

Google hat dafür seit einigen Jahren einen Ausweg gebaut: Play App Signing. Dabei verwahrt Google den eigentlichen Signaturschlüssel, und die Entwicklerin lädt mit einem separaten Upload-Schlüssel hoch. Geht der Upload-Schlüssel verloren, kann Google ihn nach Identitätsprüfung zurücksetzen. Für neue Apps ist das seit 2021 Pflicht, für ältere Apps freiwillig, und genau die älteren sind das Problem: Eine App von 2018, die noch mit eigenem Keystore signiert wird, hängt an einer Datei und einem Passwort, die irgendwo auf dem Rechner eines Entwicklers liegen, der vielleicht nicht mehr da ist.

Daraus folgt die konkreteste Handlungsempfehlung dieses Beitrags: Der Umstieg einer bestehenden App auf Play App Signing geht nur, solange der alte Schlüssel noch existiert, denn er muss dabei an Google übergeben werden. Wer den Keystore von 2018 heute noch hat, sollte heute umstellen. Das ist überschaubarer Aufwand und verwandelt ein unumkehrbares Risiko in ein reparierbares.

Die erste Frage bei jeder Übernahme einer bestehenden Android-App ist deshalb: Läuft die App über Play App Signing? Wenn ja, ist der Verlust des Upload-Keystores in der Regel reparierbar. Wenn nein, ist die zweite Frage: Wo ist die Keystore-Datei, und wer kennt das Passwort? Und die dritte: Warum liegt sie nicht beim Betrieb?

Das Apple-Konto: Wem gehört der Eintrag im Store?

Bei Apple ist die Signatur an das Entwicklerkonto gebunden, und das Entwicklerkonto ist der Ort, an dem die App im App Store hängt. Die häufigste Fehlkonstruktion: Die Agentur legt die App unter ihrem Konto an, weil das schneller geht. Dann steht im Store der Name der Agentur als Anbieter, die Agentur bekommt die Bewertungen, die Agentur bekommt die Mails von Apple, und der Betrieb hat keinerlei Zugriff. Wenn die Agentur verschwindet, verschwindet der Zugang zur eigenen App.

Die richtige Konstruktion ist einfach, sie muss nur am Anfang passieren: Das Apple-Entwicklerkonto gehört dem Auftraggeber. Bei juristischen Personen wird es als Organisationskonto angelegt, dafür braucht es eine D-U-N-S-Nummer, kostenlos, aber mit einigen Werktagen Vorlauf; Einzelunternehmer registrieren sich bei Apple als Einzelperson. Für Organisationskonten verlangen inzwischen sowohl Apple als auch Google eine D-U-N-S-Nummer. Die Entwicklerin wird als Teammitglied eingeladen, mit den Rechten, die sie braucht, und kann jederzeit wieder entfernt werden. Der Betrieb bezahlt die 99 Dollar im Jahr selbst, bekommt die Mails selbst, und die App gehört sichtbar ihm.

Wenn die App schon unter dem Konto der Agentur liegt, gibt es eine Übertragung zwischen Konten. Bundle-ID, Bewertungen und Update-Pfad bleiben dabei erhalten. App-Transfers sind an Kriterien gebunden, beide Seiten müssen zustimmen, und bestimmte Dienste wie iCloud, Keychain Sharing, Sign in with Apple oder Push können zusätzliche Transfer- und Nacharbeiten erfordern. Es ist also ein Projekt mit Vorlauf, keine Klickstrecke, und es setzt voraus, dass die alte Agentur noch existiert und mitspielt. Bei Google ist die Übertragung zwischen Play-Konten einfacher, aber auch dort braucht es beide Seiten.

Was sonst noch zur App gehört

Schlüssel und Store-Konten sind die zwei großen Posten. Die Liste ist aber länger, und jeder Eintrag darauf kann eine App lahmlegen, wenn er fehlt:

Bestandteil	Was passiert, wenn er fehlt
Push-Schlüssel (APNs-Schlüssel bei Apple, FCM-Zugang bei Google)	Zunächst keine Push-Nachrichten mehr. Der private APNs-Schlüssel lässt sich nach der Erstellung nicht erneut aus dem Apple-Konto herunterladen; „steht doch im Apple-Konto" reicht deshalb nicht. Heilbar ist das nur, solange der Zugriff auf das Konto besteht: alten Schlüssel widerrufen, neuen erzeugen, Server umstellen. Ohne Kontozugriff wird es endgültig. Bei Google hängt der Zugang am Firebase-Projekt.
Firebase- oder Cloud-Projekt	Push, Crash-Reporting, manchmal Login und Datenbank hängen daran. Das Projekt gehört unter eine Organisation oder ein Unternehmenskonto mit mindestens zwei Administratoren. Ein persönliches Google-Konto eines Entwicklers darf nicht der einzige Inhaber sein.
Domain-Dateien (apple-app-site-association, assetlinks.json)	Passkeys, Deep-Links und App-Verknüpfungen funktionieren nicht mehr, wenn niemand die Website pflegen kann.
Signing-Konfiguration und Provisioning bei Apple	Für neue Builds müssen gültige Signing-Konfigurationen vorhanden sein. Ohne Zugriff auf das Entwicklerkonto kann ein neuer Dienstleister weder Zertifikate noch Profile erneuern oder neu erzeugen. Die veröffentlichte App läuft derweil weiter.
Build-Umgebung	Welche Version von Flutter, Xcode, Android Studio, welche Bibliotheksstände. Ohne Dokumentation dauert es Tage, bis ein neuer Entwickler die App überhaupt bauen kann.
Drittdienst-Zugänge (Karten, Zahlung, Scanner-SDK, Sentry)	Konten und Schlüssel, oft auf die Agentur registriert. Beim Wechsel läuft der Kartendienst aus, und die App zeigt graue Kacheln.
Backend-Zugänge	Server, Datenbank, Deployment. Der Beitrag über Backups beschreibt, was dazugehört.
Testgeräte und Testkonten	Wer die Store-Prüfung bestehen will, braucht die Testzugänge, die im Store hinterlegt sind.

Die Übergabemappe

Die Lösung für all das ist unspektakulär: eine Mappe, die beim Betrieb liegt, ab dem ersten Tag des Projekts, und die nach jeder Änderung aktualisiert wird. Bei mir ist das ein verschlüsselter Passwort-Tresor des Kunden mit einem Ordner pro App, plus ein Dokument mit fünf Seiten. Der Inhalt:

1. Konten: Apple-Entwicklerkonto und Google-Play-Konto auf den Betrieb, mit Zugang für mindestens zwei Personen. Zwei-Faktor-Authentifizierung so eingerichtet, dass sie nicht an einer einzigen Person oder einem einzigen privaten Gerät hängt; mindestens zwei autorisierte Personen müssen den Zugang wiederherstellen können. Die Entwicklerin ist Teammitglied, nicht Inhaberin.
2. Schlüssel: Android über Play App Signing, Upload-Keystore samt Passwort im Tresor. APNs-Schlüssel gleich bei der Erstellung im Tresor abgelegt, denn der private Teil lässt sich später nicht erneut herunterladen. Alle weiteren API-Schlüssel mit Angabe, wo sie erneuert werden.
3. Quellcode: Im Repository des Betriebs, nicht der Agentur. Die Entwicklerin arbeitet in einem Repository, das dem Kunden gehört, und hat dort einen Zugang, der entzogen werden kann.
4. Build-Anleitung: Von leerem Rechner bis zur signierten App in Schritten, mit Versionsnummern der Werkzeuge. Einmal im Jahr von jemandem durchgespielt, der es noch nie gemacht hat.
5. Dienste: Firebase-Projekt, Drittdienste, Backend, jeweils mit Konto, Inhaber, Kosten, Kündigungsfrist und Ort des Schlüssels.
6. Termine: Ablauf des Apple-Kontos, der Zertifikate, der Drittdienst-Verträge, im Kalender des Betriebs, nicht der Entwicklerin.

Die Übergabemappe ist erst dann vollständig, wenn sie praktisch getestet wurde. Der Test ist derselbe wie beim Backup: Einmal im Jahr baut jemand, der die App nicht kennt, aus der Mappe heraus eine Version und lädt sie in den internen Test-Track. Wenn das klappt, ist die App übergabefähig. Wenn nicht, fehlt etwas, und man findet es, solange die Entwicklerin noch erreichbar ist.

Was in den Vertrag gehört

Die Formulierung „der Quellcode geht in das Eigentum des Auftraggebers über" ist üblich und reicht nicht. Inhaltlich sollte der Vertrag mindestens Folgendes regeln (das sind Anforderungen, keine anwaltlich geprüften Klauseln):

• Alle Konten, Schlüssel und Zugänge, die für Bau, Signatur, Veröffentlichung und Betrieb der App nötig sind, werden auf den Auftraggeber angelegt oder ihm bei Projektstart übergeben.
• Der Auftragnehmer arbeitet in Repositories und Konten des Auftraggebers und erhält dort widerrufbare Zugänge.
• Eine Build-Anleitung ist Teil der Lieferung, und ihre Vollständigkeit wird durch einen Testbau vom Auftraggeber abgenommen.

Wer das einer Agentur vorlegt und ein Zögern spürt, hat eine wichtige Information bekommen. Ich lege es meinen Kunden selbst vor, weil ich weiß, dass Freiberuflerinnen ausfallen können, und weil ein Betrieb, der seine App wirklich besitzt, ein besserer Kunde ist als einer, der von mir abhängt. Was das für die Wahl bedeutet, steht im Beitrag über Agentur oder Freelancer.

Wenn es schon passiert ist

Für den Fall, dass Sie diesen Beitrag lesen, weil der Anruf vom Anfang gerade bei Ihnen eingegangen ist, in dieser Reihenfolge:

1. Play Console prüfen: Steht die App auf Play App Signing? Dann lässt sich der Upload-Schlüssel über Google zurücksetzen, und ein Update ist möglich.
2. Falls nicht, und der alte Schlüssel ist noch da: sofort auf Play App Signing umstellen, bevor irgendetwas anderes passiert. Danach ist der Verlust des Upload-Schlüssels reparierbar.
3. Apple-Konto prüfen: Wer ist Inhaber? Wenn es die Agentur ist und sie noch existiert, jetzt die Übertragung anstoßen, bevor das Konto ausläuft.
4. Quellcode bauen lassen: Kann ein neuer Entwickler aus dem vorhandenen Code eine lauffähige Version bauen? Das zeigt, ob die Build-Umgebung dokumentiert ist.
5. Firebase und Drittdienste: Unter wessen Konto? Übertragung anfragen oder neu anlegen und die App umkonfigurieren.
6. Wenn der App-Signing-Key wirklich verloren ist und Play App Signing nicht genutzt wird: bleibt nur eine neue App mit neuem Paketnamen. Ein Hinweis in der alten App, der Nutzer zur neuen führt, lässt sich nach dem Schlüsselverlust nicht mehr nachträglich einbauen; nur eine bereits vorhandene Hinweis- oder Migrationsfunktion kann noch genutzt werden. Wie die Ablösung selbst läuft, steht im Beitrag über das Ablösen alter Apps.

Checkliste: Gehört Ihnen Ihre App?

• ☐ Läuft die Android-App über Play App Signing, oder liegt ein Keystore mit Passwort bei Ihnen?
• ☐ Ist das Apple-Entwicklerkonto auf Ihren Betrieb angelegt, mit zwei Personen im Zugriff?
• ☐ Liegt der Quellcode in einem Repository, das Ihnen gehört?
• ☐ Können Sie mit der vorhandenen Anleitung eine Version bauen lassen?
• ☐ Wem gehören Firebase-Projekt, Push-Schlüssel und Drittdienst-Konten?
• ☐ Stehen die Ablauftermine in Ihrem Kalender?
• ☐ Wann wurde die Übergabemappe zuletzt getestet?

Fazit: Eigentum ist, was man in der Hand hat

Eine App gehört dem, der sie bauen, signieren und veröffentlichen kann. Der Quellcode allein reicht dafür nicht, und ein Vertrag ersetzt keinen Keystore. Die Übergabemappe kostet am Anfang überschaubaren Aufwand und danach nur noch regelmäßige Pflege. Sie ist der Unterschied zwischen einem Entwicklerwechsel, der zwei Wochen dauert, und einem, der die App kostet. Ich lege sie bei jedem Projekt an, und ich empfehle jedem Betrieb, sie von seiner Agentur einzufordern, heute, nicht wenn der Anruf kommt.