App Store Connect App Transfer: Danach packen – Checkliste 2026

Nach einem App Transfer in App Store Connect sollten Sie die alte Signier- und Veröffentlichungskette nicht einfach weiterverwenden: Die übernehmende Partei muss Bundle ID und Fähigkeiten prüfen, neue Signierungs-, Push- und Upload-Zugänge auf einem Remote Mac einrichten und anschließend ein echtes Archive bis zum TestFlight-Upload durchtesten. Für die Übergabe in dieser Woche gilt daher: alte Umgebung kurzfristig parallel verfügbar lassen, neue Kette zuerst beweisen und erst danach alte Schlüssel, Runner und Zugänge deaktivieren.

Diese Anleitung ist für drei Gruppen gedacht: Verkäufer, die vor der Übertragung alle wiederherstellbaren Build- und Kontodaten sichern müssen; Käufer, die unter dem neuen Team die Veröffentlichung wiederherstellen; sowie kleine Teams, die einen Remote Mac oder eine CI/CD-Umgebung ohne ungeklärte Berechtigungen übernehmen.

Ein App Transfer ändert nicht automatisch jede technische Abhängigkeit des Projekts. Apple beschreibt, dass die App ihre Bundle ID behält und die zugehörige App ID an das empfangende Team übertragen wird. Das bedeutet jedoch nicht, dass Quellcode, private Schlüssel, CI/CD-Zugangsdaten, Webhooks, lokale Keychains oder Dateien auf einem Remote Mac automatisch den Besitzer wechseln. Die offizielle Übersicht zum App Transfer sollte deshalb neben dem technischen Übergabeprotokoll geöffnet bleiben.

Die Übergabe sollte nicht als ein einziger Vorgang behandelt werden. Eine belastbare Zuordnung sieht so aus:

Für die übertragende Partei ist außerdem wichtig, die Voraussetzungen des Transfers zu prüfen, statt nur auf den Transferstatus zu warten. Dazu gehören unter anderem der Zustand der App, offene Vereinbarungen und die von Apple geforderten Kontobedingungen. Die Apple-Kriterien für einen App Transfer und die Anleitung zum Initiieren sind dafür die maßgeblichen Quellen.

Achtung: Eine erfolgreiche Übergabe der App im Portal ist kein Nachweis, dass eine vorhandene Xcode-Build-Maschine weiter veröffentlichen kann. Portalzugriff, Projektdateien, Signaturmaterial und Serverzugänge müssen getrennt abgenommen werden.

Was muss vor einem App Transfer aus Xcode und App Store Connect gesichert werden? Nicht nur der Quellcode, sondern alle Informationen, mit denen ein unabhängiger Entwickler ein reproduzierbares Archive erzeugen kann. Dazu gehören das Projekt oder der Workspace, Package-Abhängigkeiten, Build-Skripte, Exportoptionen, verwendete Xcode-Einstellungen, Entitlements, Konfigurationsdateien und eine Liste der erforderlichen Capabilities.

Die übertragende Partei sollte dabei keine privaten Schlüssel oder Tokens unverschlüsselt in ein Repository legen. Stattdessen gehört in das Übergabedokument:

• der Name der Bundle ID und die zugehörige App-ID-Struktur;
• verwendete Team- und Signing-Zuordnungen als anonymisierte Platzhalter;
• eine Liste von Apple-Distribution-Zertifikaten und Provisioning Profiles mit Status und Zweck;
• die Herkunft der APNs-Konfiguration, ohne private Schlüssel oder geheime Inhalte einzufügen;
• App Store Connect API Key, Webhook- und CI/CD-Abhängigkeiten als Rollen- und Prozessbeschreibung;
• Abhängigkeiten zu iCloud, Associated Domains, Keychain Sharing, Apple Pay, Game Center oder Sign in with Apple;
• vorhandene Archive, IPA-Dateien, dSYM-Dateien und relevante Build-Logs;
• ein dokumentierter Rückweg, falls die erste Veröffentlichung unter dem neuen Team scheitert.

Apple weist ausdrücklich darauf hin, dass die übertragende Partei Code und Build-Assets direkt an die empfangende Partei übergeben muss. Das ist etwas anderes als die Übertragung eines Datensatzes in App Store Connect. Ebenso sollte die Apple-Dokumentation zur Übernahme eines App Transfers in die Übergabe aufgenommen werden.

Bei sensiblen Unterlagen sollten Sie die Daten nach dem Prinzip „Kenntnis nur bei Bedarf“ verteilen. Die Person, die das Projekt prüft, benötigt nicht automatisch den API Key für Uploads; die Person, die den Remote Mac betreut, benötigt nicht automatisch Zugriff auf Apple-Pay-Verwaltung oder Abrechnungsdaten. Für DSGVO-relevante Projekte ist zusätzlich zu dokumentieren, welche personenbezogenen Testdaten auf dem Rechner, in Logs oder in Artefakten liegen.

Nach der Annahme sollte die übernehmende Partei zuerst die Sichtbarkeit und die Rechte prüfen, bevor sie Zertifikate erzeugt. Entscheidend ist, ob die übertragene App im richtigen Team erscheint, ob historische Builds und App-Daten erwartungsgemäß sichtbar sind und ob die zuständigen Personen die für ihre Aufgaben erforderlichen Rollen besitzen.

App Store Connect, App ID, Bundle ID und Signaturprofil sind dabei vier unterschiedliche Ebenen:

• App Store Connect verwaltet den App-Datensatz, Builds, TestFlight und Veröffentlichungsabläufe.
• Die App ID verbindet die übertragene Anwendung mit dem Developer-Team und ihren Fähigkeiten.
• Die Bundle ID identifiziert das Produkt in Projekt- und Signaturkonfiguration.
• Zertifikate und Provisioning Profiles erlauben konkrete Entwicklungs-, Export- oder Veröffentlichungsaktionen.

Diese Ebenen dürfen nicht durch eine einzige erfolgreiche Portalansicht ersetzt werden. Prüfen Sie jede aktivierte Fähigkeit einzeln, besonders wenn die App nicht nur lokale Daten verwendet.

Gilt die Standardregel für jede App? Nein. Apple Pay, iCloud, Game Center, Sign in with Apple, Associated Domains, Keychain Sharing, Webhooks und Mac Catalyst können zusätzliche Arbeit erfordern. Apple stellt beispielsweise klar, dass eine Apple Pay Merchant ID nicht automatisch mit der App übertragen wird. Für Sign in with Apple beschreibt Apple außerdem einen gesonderten Migrationsprozess für Nutzer. Die technische Anleitung zur Migration von Sign in with Apple sollte deshalb nicht durch allgemeine Transfer-Erfahrungen ersetzt werden.

Bei iCloud-Containern und Keychain Sharing muss die übernehmende Partei genau prüfen, welche Identitäten und Container im Projekt verwendet werden. Ein erfolgreiches Archive kann entstehen, obwohl eine Laufzeitfunktion später keine Daten lesen kann. Deshalb gehören auch Login, Cloud-Synchronisation, Push und In-App-Käufe in die Abnahme.

Können Apple Distribution-Zertifikat und Provisioning Profile nach der Übertragung einfach weiterverwendet werden? Nicht als allgemeine Annahme. Ein bisher gültiges Push-Zertifikat kann laut der offiziellen Transfer-Übersicht innerhalb seiner Gültigkeit noch funktionieren; für spätere Push-Abläufe muss das empfangende Team jedoch eigene Zertifikate oder Schlüssel erzeugen und die Serverseite aktualisieren. Die Aussage „alle Zertifikate wechseln automatisch“ ist dagegen keine belastbare Grundlage für eine Übergabe.

Die neue Signierung sollte in einer kontrollierten Reihenfolge entstehen:

1. Die übernehmende Partei bestätigt Team-Zuordnung, Bundle ID und erforderliche Capabilities.
2. Nicht benötigte Fähigkeiten werden aus dem Projekt entfernt oder als offene Prüfaufgabe markiert.
3. Neue Distribution- und gegebenenfalls Development-Zertifikate werden im empfangenden Team eingerichtet.
4. Für die konkrete Exportart wird ein neues Provisioning Profile erzeugt und auf dem Remote Mac installiert.
5. Entitlements, Keychain Sharing, Associated Domains, iCloud und Push werden gegen die Projektdateien geprüft.
6. CI/CD oder fastlane erhält Zugang über eine sichere Geheimniszufuhr, nicht über kopierte Benutzerverzeichnisse.
7. Ein lokales oder isoliertes Test-Archive wird erstellt, bevor die alte Umgebung deaktiviert wird.

Die Apple-Anleitung zum Erstellen eines App-Store-Provisioning-Profils ist dabei wichtiger als ein blind kopiertes Profil aus dem alten Team. Ein Profil ist an konkrete Identitäten, Berechtigungen und eine App-Zuordnung gebunden; die bloße Dateiablage beweist daher keine gültige neue Signierung.

Muss APNs nach einem App Transfer neu eingerichtet werden? Für die nachhaltige Weiterführung sollten Sie das einplanen. Die übernehmende Partei muss Serverzugang, Push-Schlüssel oder TLS-Zertifikat, Topic beziehungsweise Bundle-Zuordnung und die verwendete Umgebung prüfen. Apple beschreibt die Einrichtung der APNs-TLS-Kommunikation separat. Nach der Umstellung sollte nicht nur der Upload erfolgreich sein, sondern auch eine kontrollierte Push-Nachricht auf einem Testgerät ankommen.

Kann die alte Xcode-Build-Maschine nach dem App Transfer weiter verwendet werden? Nur als kurzfristige Übergangsbrücke und nur mit klarer Zugriffstrennung. Sie ist kein vollständiges Übergabeergebnis, solange dort alte Team-Zertifikate, private Schlüssel, Benutzerkonten, API Keys oder CI/CD-Runner unkontrolliert weiterlaufen.

Auf dem Remote Mac sollte die übernehmende Partei eine nachvollziehbare Arbeitsumgebung einrichten. Die folgenden Schritte sind für eine erste technische Abnahme geeignet:

1. Xcode-Version, SDK-Anforderungen und Projektabhängigkeiten dokumentieren; keine Versionsannahme allein aus dem alten Archive übernehmen.
2. Projekt und Package-Abhängigkeiten in einem neuen, kontrollierten Arbeitsverzeichnis auschecken.
3. Signing-Identitäten und Provisioning Profiles unter dem neuen Team installieren, ohne die gesamte alte Keychain zu kopieren.
4. Secrets über einen sicheren Mechanismus injizieren; Team ID, Bundle ID, Key ID, Pfade und Tokens in Beispielen ausschließlich als Platzhalter führen.
5. Ein Archive über die grafische Xcode-Oberfläche ausführen.
6. Dasselbe Projekt, soweit vorgesehen, über SSH oder CI/CD bauen und Exit-Status sowie Logdatei sichern.
7. IPA exportieren, Signatur und Entitlements prüfen und das Artefakt eindeutig versionieren.
8. Upload mit dem neuen App Store Connect-Zugang durchführen und die Verarbeitung im Portal abwarten.
9. TestFlight-Installation, Push, Login, Cloud-Funktionen und kritische Produktpfade prüfen.
10. Erst danach entscheiden, ob die alte Umgebung weiter parallel benötigt wird.

Für Uploads sollten Sie die offiziellen Statusdefinitionen beachten, statt „Archive erstellt“ mit „Build veröffentlicht“ gleichzusetzen. Apple beschreibt sowohl den Upload von Builds als auch die einzelnen Build-Statuswerte. Ein Build kann lokal erfolgreich archiviert sein, während Upload, Verarbeitung oder TestFlight-Verfügbarkeit noch ausstehen.

Erfahrung aus der Übergabepraxis: Ein einzelner grüner Xcode-Dialog deckt mindestens vier getrennte Fehlerklassen nicht ab: falsches Team, fehlerhafte Entitlements, fehlende Upload-Berechtigung und eine nicht funktionsfähige Laufzeitintegration. Protokollieren Sie deshalb jeden Abschnitt separat.

Wer keine eigene Hardware für diese Übergangsphase vorhalten möchte, kann die Anforderungen an einen Remote Mac für iOS-Builds zunächst gegen die Projektanforderungen abgleichen. Relevant sind dabei nicht pauschale Leistungsversprechen, sondern ein klarer Zugriffspfad, vollständige Administrationsrechte, eine getrennte Benutzer- und Schlüsselverwaltung sowie die Möglichkeit, Archive und Logs nachvollziehbar abzulegen.

Die erste Veröffentlichung sollte nicht mit einem irreversiblen Produktionsschritt beginnen. Verwenden Sie eine Build-Nummer und einen Release-Ablauf, die der übernehmenden Partei eine kontrollierte TestFlight-Prüfung erlauben. Das Ziel ist nicht nur ein erfolgreiches Kompilieren, sondern eine vollständige Kette:

• Projekt wird unter dem neuen Team gebaut;
• Archive enthält die erwartete Bundle ID;
• Entitlements entsprechen den tatsächlich benötigten Capabilities;
• IPA lässt sich mit dem neuen Profil exportieren;
• Upload wird vom neuen Zugang authentifiziert;
• Build wird von App Store Connect verarbeitet;
• TestFlight stellt den Build für berechtigte Tester bereit;
• App lässt sich installieren und starten;
• Push, Login, Cloud-Funktionen und geschäftskritische Abläufe funktionieren;
• Logs, Artefakte und Entscheidungen sind später nachvollziehbar.

Woran erkennen Sie, dass die Übergabe wirklich abgeschlossen ist? Erst wenn jede dieser Ebenen einen eigenen Nachweis besitzt. Ein erfolgreiches Archive ersetzt weder die App-Store-Verarbeitung noch den Test auf einem Gerät. Ebenso ersetzt ein sichtbarer TestFlight-Build keinen Funktionstest von Push, Sign in with Apple, iCloud oder In-App-Käufen.

Für kleine Teams empfiehlt sich eine einfache Abnahmematrix:

Eine kurze Doppelspur zwischen alter und neuer Umgebung ist bei einer App-Übertragung meist sicherer als ein sofortiger harter Schnitt. Sie darf jedoch nicht zu dauerhaft gemeinsam genutzten privaten Schlüsseln führen. Definieren Sie vor dem Transfer, welche Bedingungen die drei Beteiligten erfüllen müssen.

Die übertragende Partei kann ihre aktive Unterstützung beenden, wenn Quellcode, Build-Assets und Übergabeunterlagen vollständig übergeben wurden, die neue Partei Zugriff auf die erforderlichen App-Store-Daten besitzt und mindestens ein TestFlight-Nachweis vorliegt. Die übernehmende Partei sollte die alte Umgebung erst freigeben, wenn Archive, IPA, Upload und Kernfunktionen unter dem neuen Team wiederholbar funktionieren. Die betreuende Person des Remote Mac sollte alte Benutzer, Runner, Webhooks und API Keys erst entfernen, wenn Logs und Artefakte der neuen Kette gesichert sind.

Für die finale Entscheidung genügt diese kompakte Checkliste:

• [ ] Bundle ID, App ID und Capabilities sind dokumentiert.
• [ ] Sonderfunktionen wie Apple Pay, iCloud und Sign in with Apple sind separat bewertet.
• [ ] Neue Zertifikate und Provisioning Profiles sind im empfangenden Team eingerichtet.
• [ ] APNs wurde mit der neuen Serverkonfiguration getestet.
• [ ] Der neue Remote Mac baut über GUI und den vorgesehenen Automatisierungsweg.
• [ ] IPA-Export, Upload und App-Store-Verarbeitung sind nachgewiesen.
• [ ] TestFlight-Installation und kritische Produktfunktionen wurden geprüft.
• [ ] Archive, IPA, Logs und Übergabeentscheidungen sind auffindbar gespeichert.
• [ ] Alte API Keys, Webhooks, Runner und Benutzerzugänge haben einen dokumentierten Abschalttermin.
• [ ] Es existiert eine Rückfallentscheidung, falls ein Fehler erst nach der TestFlight-Prüfung sichtbar wird.

Wenn diese Punkte nicht vollständig erfüllt sind, sollte die alte Umgebung nicht als Produktionsersatz weiterlaufen, sondern nur als zeitlich begrenzte Rückfalloption. Private Schlüssel sollten nicht dauerhaft zwischen den Parteien geteilt werden; nach erfolgreicher Abnahme sind die alten Zugänge zu widerrufen oder zumindest aus dem aktiven Veröffentlichungsweg zu entfernen.

Eine alte, gemeinsam übernommene Build-Maschine wirkt zunächst bequem, bringt aber drei reale Nachteile mit: Die Herkunft von Zertifikaten und privaten Schlüsseln bleibt unklar, alte Team- und Webhook-Berechtigungen können unbemerkt weiterwirken, und ein lokaler Benutzerkontext lässt sich nur schwer reproduzierbar an eine neue Eigentümerstruktur übergeben. Bei einer privaten Mac-Hardware kommen zusätzlich Beschaffung, Wartung und die dauerhafte Absicherung der Maschine hinzu.

Wenn für die Übergabe nur wenige Veröffentlichungen anstehen, kann eine kontrollierte eigene Umgebung genügen. Wenn dagegen ein ständig erreichbarer Build-Rechner, vollständige Root-Rechte und eine getrennte Arbeitsumgebung benötigt werden, ist ein gemieteter Remote Mac von JEXCLOUD oft die sauberere Übergangslösung: Die neue Partei kann die Signierung selbst einrichten, die alte Keychain muss nicht übernommen werden, und die Abnahme bleibt von der Hardware des Verkäufers getrennt. Die verfügbaren Remote-Mac-Optionen von JEXCLOUD sollten Sie dabei nach Zugriff, Verantwortungsbereich und geplanter Nutzungsdauer auswählen, nicht nur nach dem Namen des Tarifs.

Für die konkrete Umstellung ist die sinnvolle Reihenfolge damit klar: erst Übergabe dokumentieren, dann App Store Connect und Bundle ID prüfen, danach Signierung und APNs neu aufbauen, anschließend auf dem Remote Mac ein echtes Archive bis TestFlight abnehmen und erst am Ende die alte Veröffentlichungskette zurückbauen.