Xcode kann das Projekt archivieren, aber flutter build ipa scheitert über SSH mit einem codesign-Fehler? Dann löschen Sie nicht zuerst Zertifikate oder die gesamte Keychain. Trennen Sie zunächst Projektkonfiguration, Signaturidentität, Target-Berechtigungen und Remote-Keychain; prüfen Sie danach Release Archive, IPA-Export und echten Upload in genau dieser Reihenfolge.

Für wen ist diese Anleitung gedacht?
Für Sie, wenn Sie unter Windows oder Linux entwickeln und einen Remote Mac für iOS-Builds benötigen. Sie richtet sich außerdem an Entwickler, deren Flutter-3.44-Projekt nach einem Upgrade bei Runner oder Plugin-Targets nicht mehr signiert. Kleine Teams mit SSH-, Skript- oder CI/CD-Builds finden hier eine Abnahme für unbeaufsichtigte Signaturvorgänge.

Zuletzt aktualisiert am 07.09.2026; die Angaben wurden anhand der offiziellen Flutter-3.44-Veröffentlichungsnotizen, der aktuellen Flutter-Dokumentation zum iOS-Deployment sowie der Apple-Dokumentation zu Signatur, Profilen und Distribution geprüft.

01

Der Fehler muss zuerst einer Build-Phase zugeordnet werden

Ein Flutter-iOS-Build besteht nicht aus einem einzigen Vorgang. flutter build ios kann bis zur Xcode-Buildphase kommen, ohne ein vollständiges Release-Artefakt zu erzeugen. flutter build ipa führt zusätzlich Archivierung und Export zusammen. Danach folgen Signaturprüfung, Upload und die serverseitige Validierung.

Ein typischer, anonymisierter Ausschnitt kann beispielsweise so aussehen:

[ X ] Code signing failed for target Runner
error: No profiles for 'APP_BUNDLE_ID' were found
error: Signing certificate 'Apple Distribution: [TEAM_NAME]' is not installed
Command CodeSign failed with a nonzero exit code

Die letzte codesign-Zeile ist dabei nicht automatisch die ursprüngliche Ursache. Entscheidend sind:

  • der erste verwertbare Fehler vor dem Abbruch,
  • das betroffene Target, etwa Runner, NotificationExtension oder ShareExtension,
  • die Build Configuration, meist Release,
  • das aktive Scheme,
  • der konkrete Einstiegspunkt: Xcode, flutter build ipa, SSH-Skript oder CI/CD-Aufgabe.

Flutter beschreibt den iOS-Veröffentlichungsweg weiterhin als macOS-, Xcode- und Apple-Signaturprozess. Ein Flutter-Build auf einem Linux- oder Windows-Rechner ersetzt diese letzte Umgebung nicht; für Archive und Distribution brauchen Sie eine geeignete macOS-Buildumgebung. Die offizielle iOS-Build-Anleitung von Flutter grenzt diese Schritte voneinander ab.

Der erste Vergleich: grafische Sitzung gegen Kommandozeile

Erstellen Sie zunächst zwei möglichst identische Protokolle:

Ausführung Aussage bei Erfolg Aussage bei Fehler
Xcode, Release, Archive Projekt und grafische Signaturumgebung funktionieren wahrscheinlich Target, Profile oder Projektkonfiguration prüfen
Lokales Terminal auf dem Mac CLI-Umgebung kann grundsätzlich signieren Flutter-, Xcode- oder Keychain-Pfad prüfen
SSH mit demselben Benutzer Remote-Sitzung erreicht die Signaturumgebung Keychain, Session oder Zugriffsrechte sind verdächtig
Unbeaufsichtigtes Skript Build ist für CI/CD wiederholbar Nicht-interaktive Rechte oder geheime Zugangsdaten prüfen

Verwenden Sie für alle Vergleiche dasselbe Commit und dieselbe Release-Konfiguration. Ein Debug-Erfolg ist kein Nachweis für eine veröffentlichungsfähige Signatur. Der belastbare Zwischenstand ist ein Release Archive, das die erwarteten Targets und Signaturdaten enthält.

02

Flutter 3.44 Signaturfehler: Projekt, Team und Bundle ID auseinanderhalten

Wenn flutter build ipa nach einem Development Team fragt, fehlt nicht zwingend ein Zertifikat. Häufig verwendet der Build ein anderes Scheme, eine andere Konfiguration oder eine Target-Einstellung ohne gültige Team-Zuordnung.

Öffnen Sie das iOS-Projekt in Xcode und kontrollieren Sie nacheinander:

  1. das Runner-Projekt,
  2. das Runner-Target,
  3. die Release-Konfiguration,
  4. das aktive Scheme,
  5. jedes zusätzliche Extension-Target,
  6. die Bundle ID im Signaturbereich.

Die Bundle ID im Projekt muss zur App-ID im Entwicklerkonto passen. Ein ähnlicher Name genügt nicht. APP_BUNDLE_ID, TEAM_ID und die tatsächlichen Target-Namen sollten Sie in Logdateien immer durch eindeutige Platzhalter ersetzen. Veröffentlichen Sie niemals reale Zertifikatsnamen, Profile-UUIDs, Benutzer, Hostadressen oder Token.

Automatische und manuelle Signierung nicht zufällig vermischen

Automatische Signierung kann Profile und Entwicklungswerte passend auswählen. Manuelle Signierung gibt Ihnen mehr Kontrolle über Distribution, mehrere Targets und reproduzierbare Buildsysteme. Problematisch wird es, wenn das Runner-Target automatisch signiert, ein Extension-Target jedoch manuell ein veraltetes Profile verwendet und der IPA-Export wiederum eigene Exportoptionen erzwingt.

Prüfen Sie deshalb für jede Phase:

  • Ist automatische Signierung bewusst aktiviert oder deaktiviert?
  • Verwendet das aktive Scheme wirklich Release?
  • Hat jedes Target eine passende Bundle ID?
  • Wird beim Export derselbe Signaturmodus fortgeführt?
  • Erzeugt derselbe Commit ein vollständiges Archive?

Der Apple-Leitfaden zur Vorbereitung einer App für die Distribution ist für diese Zuordnung maßgeblich. Die erfolgreiche Debug-Ausführung zählt hier nicht als Abnahme.

03

Zweiter Prüfpunkt: Zertifikat, private Schlüssel und Provisioning Profile

Ein Zertifikat ist nur ein Teil der Signaturidentität. Für eine funktionierende Signatur müssen mindestens diese Ebenen zusammenpassen:

  • das Zertifikat im Keychain,
  • der zugehörige private Schlüssel,
  • die daraus sichtbare Signaturidentität,
  • das Provisioning Profile,
  • App-ID, Team und Capabilities,
  • die Distributionsebene des aktuellen Builds.

Wenn Sie lediglich eine Zertifikatsdatei importieren, aber der private Schlüssel fehlt, kann Xcode das Zertifikat anzeigen und codesign trotzdem scheitern. Apple erklärt die unterschiedlichen Zertifikatstypen und ihre Einsatzbereiche. Für einen Release-Build benötigen Sie außerdem ein Profile, das zum Ziel und zur vorgesehenen Verteilung passt.

Provisioning Profile anhand der tatsächlichen Aufgabe prüfen

Öffnen Sie nicht nur den Profilnamen. Prüfen Sie die enthaltenen Werte gegen den Build:

  • App-ID beziehungsweise Bundle ID,
  • Team,
  • Distributionstyp,
  • erlaubte Capabilities,
  • zugeordnete Zertifikatsidentität,
  • Target, für das das Profile bestimmt ist.

Die technische Erklärung von Apple zu Provisioning Profiles und Code Signing beschreibt, warum Profile nicht austauschbar sind. Ein Entwicklungsprofil kann einen lokalen Gerätetest ermöglichen, aber nicht automatisch den gewünschten App-Store-Export abdecken.

Löschen, widerrufen oder ersetzen Sie Signaturmaterial nicht als erste Maßnahme. Sichern Sie vorher die zulässigen Projekt- und Exportinformationen und dokumentieren Sie, welche weitere Buildmaschine davon abhängt. Ein Widerruf kann laufende Releases, andere Entwicklergeräte und parallele CI/CD-Aufgaben beeinflussen. Die Rückfallbedingung muss klar sein: Erst wenn die bestehende Identität nachweislich unbrauchbar oder kompromittiert ist, kommt eine kontrollierte Neuerstellung infrage.

04

Erweiterungen und Flutter-Plugins können separat scheitern

Der Runner ist nicht zwangsläufig das einzige signierte Produkt. Benachrichtigungs-Erweiterungen, Widgets, Share Extensions und von Plugins erzeugte native Targets können eigene Bundle IDs und Entitlements besitzen.

Ein häufiger Fehlansatz ist:

  1. Runner in Xcode erfolgreich archivieren,
  2. nur die Runner-Einstellungen kontrollieren,
  3. beim Export den Fehler des eingebetteten Targets übersehen.

Prüfen Sie stattdessen jede Target-Zeile im Archive. Vergleichen Sie für jedes Target:

  • Bundle ID,
  • Team,
  • Signing & Capabilities,
  • verwendetes Provisioning Profile,
  • Entitlements,
  • Einbettung in das finale Produkt.

Runner und Plugin-Targets müssen nicht dieselbe Bundle ID besitzen. Sie müssen aber jeweils mit ihren eigenen App-IDs und Berechtigungen konsistent signiert sein. Ein Widget mit einer Capability, die sein Profile nicht erlaubt, kann den gesamten Export ungültig machen.

Entitlements aus dem fertigen Produkt lesen

Die Projektdatei zeigt nur die gewünschte Konfiguration. Für die Diagnose zählt, was tatsächlich in Archive und IPA gelandet ist. Vergleichen Sie die Entitlements des exportierten Produkts mit den im Entwicklerkonto aktivierten Capabilities. Apple beschreibt die Funktion und Struktur der Entitlements.

Achten Sie auf Unterschiede bei Push-Benachrichtigungen, App Groups, Keychain Sharing oder Associated Domains. Entfernen Sie eine Capability nicht blind aus dem Projekt. Damit können Sie zwar einen einzelnen Fehler verschieben, aber eine benötigte Funktion oder eine andere Ziel-App beschädigen.

05

Dritter Prüfpunkt: Remote-Keychain und nicht-interaktive Sitzungen

Wenn Xcode auf dem Remote Mac archiviert, aber derselbe Commit über SSH scheitert, liegt der Fehler häufig nicht im Flutter-Projekt. Eine grafische Sitzung kann bereits angemeldet sein, die Standard-Keychain verwenden und einen Zertifikatszugriff zuvor bestätigt haben. Ein SSH-Prozess muss diese Bedingungen nicht vorfinden.

Vergleichen Sie deshalb zwischen grafischer Sitzung, SSH und automatischem Auftrag:

  • welcher Benutzer den Prozess startet,
  • welche Keychain tatsächlich verwendet wird,
  • ob diese Keychain entsperrt ist,
  • ob die Signaturidentität sichtbar ist,
  • ob der private Schlüssel für den Prozess zugänglich ist,
  • ob der Zugriff interaktiv bestätigt werden müsste.

Geben Sie keine Passwörter, privaten Schlüssel oder App-Store-Zugangsdaten in Skripte oder Logs aus. Bevorzugen Sie einen eigenen Build-Benutzer mit minimalen Rechten. Beschränken Sie den Zugriff auf die benötigten Signaturobjekte, anstatt einer allgemeinen Aufgabe die vollständige Benutzerumgebung zu öffnen.

Apple führt in seinen Hinweisen zur Code-Signing-Fehlersuche auch die Unterschiede zwischen Sitzungen und Signaturzugriffen als relevante Diagnoseebene. Diese Quelle ist keine Garantie für jede Remote-Umgebung. Sie liefert aber die richtige Prüfrichtung: erst Identität und Zugriff vergleichen, dann Projektdateien verändern.

Sichere Änderungen und Rückfall

Jede Änderung an Keychain-Zugriffen sollte vier Angaben enthalten:

  1. betroffener Benutzer und betroffene Keychain,
  2. genaues Ziel des Zugriffs,
  3. minimale notwendige Berechtigung,
  4. Rückfallweg bei einem fehlgeschlagenen Build.

Setzen Sie keine globale Freigabe für alle Prozesse, nur damit ein einzelner SSH-Aufruf funktioniert. Wenn Sie eine private Schlüsseldatei importieren müssen, klären Sie vorher Aufbewahrung, Dateirechte, Löschung nach dem Einsatz und Rotation. Ein Remote Mac ist nur dann als dauerhafter iOS-Buildserver geeignet, wenn ein Neustart, eine getrennte Sitzung und ein erneuter Auftrag ohne manuelle Passwortabfrage kontrolliert wiederhergestellt werden können.

06

Sieben Schritte bis zur belastbaren Release-Abnahme

1. Ausgangslage unverändert sichern

Erstellen Sie zuerst einen reproduzierbaren Ausgangspunkt. Notieren Sie Commit, Flutter-Version, Xcode-Version, aktives Scheme, Build Configuration und den ausführenden Benutzer. Verwenden Sie in veröffentlichten Protokollen nur Platzhalter wie APP_BUNDLE_ID, TEAM_ID, PROFILE_UUID und BUILD_HOST.

2. Den ersten gültigen Fehler isolieren

Führen Sie flutter build ios und anschließend flutter build ipa getrennt aus. Speichern Sie die komplette Ausgabe, aber entfernen Sie Token, Pfade mit Benutzernamen, Hostnamen und private Zertifikatsdaten. Markieren Sie das erste Target, das mit einer verwertbaren Fehlermeldung abbricht.

3. Xcode-Archive als Referenz erzeugen

Öffnen Sie den gleichen Commit in Xcode. Wählen Sie das reale Release-Scheme und erstellen Sie ein Archive. Prüfen Sie darin Runner und alle eingebetteten Targets. Wenn Xcode ebenfalls scheitert, liegt die Ursache wahrscheinlich in Projekt, Profile, Zertifikat oder Target-Berechtigungen.

4. Team und Bundle IDs abgleichen

Vergleichen Sie jedes Target mit der App-ID im Entwicklerkonto. Prüfen Sie, ob das aktive Scheme wirklich die Release-Werte verwendet. Ein Development Team, das nur im Debug-Target gesetzt ist, löst den Release-Build nicht.

5. Signaturidentität vollständig prüfen

Suchen Sie nicht nur nach dem Zertifikatsnamen. Bestätigen Sie, dass der private Schlüssel vorhanden ist und dass die erwartete Signaturidentität für den Build-Benutzer sichtbar ist. Prüfen Sie danach das Provisioning Profile auf App-ID, Distributionstyp, Team und Capabilities.

6. Session und Keychain getrennt testen

Führen Sie denselben Build einmal in der grafischen Sitzung, einmal im Terminal des Remote Macs und einmal über SSH aus. Ändern Sie zwischen den Versuchen nicht mehrere Variablen gleichzeitig. Wenn nur SSH scheitert, untersuchen Sie Keychain-Pfad, Entsperrstatus und Zugriffskontext vor einer Projektänderung.

7. IPA, Entitlements und Upload verifizieren

Ein erzeugtes IPA ist noch kein erfolgreicher Release. Prüfen Sie Archive, IPA-Export, Signatur und Entitlements. Führen Sie anschließend den vorgesehenen Upload aus und bewerten Sie die echte Validierungsantwort. Erst wenn diese Kette funktioniert, darf der Remote Mac als zuverlässiger Flutter-Buildserver gelten.

07

Die Entscheidungslogik für Reparatur oder Umzug

Verwenden Sie diese Bedingungen nach der Diagnose:

  • Wenn Xcode und SSH mit demselben Commit scheitern, wählen Sie zuerst eine Reparatur von Team, Bundle ID, Profile oder Target. Sonst prüfen Sie die Umgebung.
  • Wenn Xcode archiviert, das lokale Terminal ebenfalls funktioniert, SSH aber scheitert, wählen Sie eine Keychain- und Sitzungsprüfung. Löschen Sie nicht vorschnell die Signaturassets.
  • Wenn Runner signiert, ein Extension-Target aber scheitert, wählen Sie die Target- und Entitlements-Reparatur. Verlassen Sie sich nicht auf den Runner-Erfolg.
  • Wenn das Archive vollständig ist, der IPA-Export aber fehlschlägt, wählen Sie die Prüfung von Exportoptionen, Distributionstyp und Profilzuordnung.
  • Wenn IPA und Entitlements stimmen, der Upload aber abgelehnt wird, wählen Sie die serverseitige Validierung des konkreten Fehlers. Bewerten Sie nicht allein die lokale Dateierzeugung.
  • Wenn ein Neustart oder eine neue SSH-Sitzung die Signatur unzuverlässig macht, wählen Sie entweder eine kontrollierte Remote-Keychain-Konfiguration oder eine macOS-Umgebung mit geeigneter Persistenz.

Für die Umgebungsauswahl ist ein Remote Mac besonders dann sinnvoll, wenn Sie kurzfristig eine vollständige macOS-Toolchain, Xcode und eine dauerhaft erreichbare Signaturumgebung benötigen. Einen Überblick über die Mac-Remote-Lösungen von VpsMesh können Sie getrennt von der technischen Abnahme prüfen. Verfügbare Mac-Mietpreise helfen anschließend bei der Kostenplanung. Entscheidend bleibt nicht der Markenname des Rechners, sondern ob Ihr eigener Commit Archive, IPA und Upload wiederholbar durchläuft.

08

FAQ zur Flutter-Signatur auf dem Remote Mac

Warum verlangt flutter build ipa plötzlich die Auswahl eines Development Teams?

Prüfen Sie zuerst, ob das tatsächlich verwendete Scheme und die Release-Konfiguration ein Team enthalten. Bei mehreren Targets reicht eine korrekte Einstellung im Runner nicht aus. Kontrollieren Sie außerdem Bundle ID, Entwicklerkonto und Signaturmodus in Xcode. Danach starten Sie einen reproduzierbaren Release-Build, statt nur den Debug-Modus zu testen.

Warum funktioniert der Flutter-Build in Xcode, aber nicht über SSH?

Eine grafische Sitzung kann auf eine entsperrte Standard-Keychain und bereits bestätigte Zugriffsrechte zugreifen. Ein SSH-Prozess läuft dagegen häufig ohne diese Sitzung. Vergleichen Sie Identität, Keychain-Pfad, Entsperrstatus und Zugriffsrechte in beiden Ausführungswegen. Ändern Sie die Keychain nicht global, bevor Sie den betroffenen Build-Benutzer und die Rückfallmöglichkeit dokumentiert haben.

Müssen Runner und Plugin-Targets dieselben Signaturwerte verwenden?

Sie müssen nicht dieselbe Bundle ID besitzen, aber jedes Target braucht eine passende eigene Identität. Bundle ID, Team, Signing-Modus, Capabilities und Provisioning Profile müssen zusammenpassen. Prüfen Sie daher Erweiterungen, Widgets und Benachrichtigungs-Targets einzeln. Ein erfolgreich signierter Runner beweist nicht, dass das eingebettete Plugin-Target korrekt signiert wurde.

Was tun Sie bei nicht passenden Entitlements nach dem IPA-Export?

Vergleichen Sie die Entitlements des tatsächlich signierten IPA mit den Capabilities und dem verwendeten Provisioning Profile. Entscheidend ist das exportierte Artefakt, nicht nur die Einstellung im Quellprojekt. Entfernen Sie keine Capability auf Verdacht, weil dadurch Funktionen oder App-IDs anderer Builds betroffen sein können. Korrigieren Sie anschließend Target, Profile und Exportoption gemeinsam.

09

Was Sie jetzt mit dem bestehenden Mac entscheiden sollten

Wenn Ihr aktueller Rechner nur in einer geöffneten Xcode-Sitzung funktioniert, entstehen drei konkrete Nachteile: SSH-Builds sind nicht reproduzierbar, Neustarts können den Signaturzugriff unterbrechen und ein lokaler Rechner steht nicht zuverlässig für nächtliche oder teamweite Release-Aufgaben bereit. Ein einzelner Entwickler-PC erschwert außerdem die Trennung zwischen persönlicher Keychain und automatisiertem Build-Benutzer.

Wenn Sie nicht dauerhaft eine zusätzliche Hardware für iOS-Veröffentlichungen betreiben möchten, können Sie denselben Repository-Stand zunächst auf einem Remote Mac von VpsMesh prüfen. Führen Sie dort Archive, IPA-Export und Upload mit Ihren eigenen Projekt- und Apple-Zugangsdaten durch. Erst wenn der Ablauf nach erneuter Anmeldung oder einem Neustart wiederholbar ist, entscheiden Sie zwischen zeitweiser Miete für einen Release-Zyklus und einer dauerhaften Buildumgebung. Für eine kurze Fehleranalyse oder einen ausgelagerten Veröffentlichungsjob ist Mieten meist flexibler als ein Rechner, der außerhalb der Release-Phasen ungenutzt bleibt.