.NET MAUI 10 Remote-Build-Fehler: Xcode 26.6, 2026

Ein .NET MAUI 10 Remote-Build-Fehler sollte zuerst auf dem Remote Mac mit einem Minimalprojekt reproduziert werden. Schlägt dieser lokale Build ebenfalls fehl, müssen .NET-for-iOS-Workload und Xcode 26.6 aufeinander abgestimmt werden; funktioniert er dagegen lokal, liegt die Ursache eher bei Pair to Mac, dem Remote-SDK, dem Cache oder der Windows-Konfiguration. Ein Knoten sollte erst neu aufgebaut werden, wenn sich die Umgebung nicht mehr isolieren lässt oder wiederholt driftet.

Diese Anleitung ist für Entwickler gedacht, die aus Visual Studio unter Windows eine .NET-MAUI-iOS-Anwendung bauen, sowie für DevOps-Ingenieure, die einen Remote Mac als Build-Knoten betreiben. Auch Verantwortliche für mobile Plattformen erhalten Kriterien dafür, ob eine Reparatur, ein Rückfall, ein Parallelbetrieb oder eine neue Umgebung verantwortbar ist.

Zu den geprüften Grundlagen gehören die offizielle .NET-MAUI-10-Dokumentation, die aktuellen .NET-for-iOS-Releases und die offiziellen .NET-MAUI-Releases. Der Wissensstand wurde zuletzt am 05.09.2026 anhand dieser Quellen geprüft. Eine erneute Prüfung ist erforderlich, sobald .NET MAUI 10 einen neuen Service-Stand erhält, .NET for iOS die Xcode-Unterstützung verändert, die Pair-to-Mac-Dokumentation überarbeitet wird oder der eingesetzte Knoten seine Werkzeugkette aktualisiert.

Die vier Zustände zuerst getrennt erfassen

Die Formulierung „Mac verbunden, Build fehlgeschlagen“ beschreibt zu viele verschiedene Fehler. Für eine belastbare Übergabe muss das Team mindestens zwischen diesen Zuständen unterscheiden:

• Pair to Mac verbunden: Windows erreicht den Host, die Anmeldung und die Pairing-Verbindung funktionieren.
• Mac lokal erfolgreich gebaut: Ein Minimalprojekt lässt sich direkt auf dem Mac mit der dort ausgewählten Xcode-Installation kompilieren.
• Remote-Build erfolgreich: Dasselbe Projekt wird aus Windows heraus über Pair to Mac gebaut.
• Signierung und Veröffentlichung erfolgreich: Das gewünschte Ziel, etwa Simulator, Gerät oder Archiv, wird mit dem vorgesehenen Zertifikat und Profil verarbeitet.

Ein erfolgreicher erster Zustand beweist daher weder eine funktionierende .NET-MAUI-Werkzeugkette noch eine gültige Signierung. Umgekehrt ist ein Fehler beim vierten Zustand kein ausreichender Grund, Pair to Mac neu einzurichten, wenn der Debug-Build und der lokale Release-Build bereits funktionieren.

Für jede Wiederholung sollte eine unveränderte Fehleraufnahme verwendet werden:

• Windows-Betriebssystem und Visual-Studio-Version als Textwert festhalten.
• Auf beiden Seiten dotnet --info ausführen und die Ausgabe unverändert speichern.
• Den installierten MAUI-Workload mit dotnet workload list dokumentieren.
• Die tatsächlich verwendete .NET-for-iOS-Version aus der Build-Ausgabe übernehmen.
• Ziel-Framework, Konfiguration, Runtime-Identifier und Signierungsmodus notieren.
• Den vollständigen Binärlog sichern und den ersten verwertbaren Fehler markieren.
• Projektname, Benutzerkonto, Hostadresse, Port, Pfade und Zertifikatsnamen durch Platzhalter wie <PROJEKT>, <MAC_HOST> und <SIGNIERUNG> ersetzen.

Die Version .NET MAUI 10.0.100 ist laut offizieller Release-Übersicht am 20.08.2026 veröffentlicht worden. Die .NET-for-iOS-Release-Aufzeichnungen führen außerdem Unterstützung für Xcode 26.6 auf; beide Angaben müssen dennoch mit der konkret installierten Workload- und SDK-Ausgabe des Knotens abgeglichen werden, statt nur den Paketnamen des Projekts zu betrachten. Quelle zur .NET-MAUI-Releaseübersicht und Quelle zu den .NET-for-iOS-Releases.

Erster Schritt: Der Plattformverantwortliche baut die Diagnosebasis

Der Plattformverantwortliche sollte nicht mit einer Neuinstallation beginnen, sondern eine kleine, reproduzierbare Teststrecke definieren. Dafür genügt ein neues, unverändertes .NET-MAUI-Projekt mit einem iOS-Ziel. Das Projekt erhält einen festen Namen wie <MINIMAL_IOS_PROJEKT> und wird für jede Prüfung aus demselben Commit erzeugt.

Die Reihenfolge der Beweiserhebung lautet:

1. Das Projekt auf dem Remote Mac direkt in der Shell bauen.
2. Den verwendeten Xcode-Pfad und das aktive Entwicklerverzeichnis feststellen.
3. Dasselbe Projekt aus Windows über Pair to Mac aufrufen.
4. Den Build mit dem normalen Geschäftsprojekt wiederholen.
5. Erst danach Simulator-, Geräte-, Release- oder Archivierungsziele testen.

Auf dem Mac müssen insbesondere xcode-select -p, die Ausgabe von xcodebuild -version und die gesetzte Variable DEVELOPER_DIR zusammen betrachtet werden. Ein korrekt installiertes Xcode hilft nicht, wenn die Shell, Visual Studio und der Remote-Dienst auf unterschiedliche Installationen zeigen. Die offizielle .NET-MAUI-Fehlerbehebung beschreibt die Auswahl der Xcode-Installation und die relevanten Prüfungen; sie ist deshalb aussagekräftiger als eine allgemeine Cache-Löschung. Microsoft-Learn-Anleitung zur Xcode-Auswahl und Fehlerbehebung.

Warum kann .NET MAUI 10 trotz erfolgreicher Mac-Verbindung nicht für iOS bauen?
Weil eine SSH- beziehungsweise Pairing-Verbindung lediglich den Transport und die Anmeldung bestätigt. Der eigentliche iOS-Build benötigt auf dem Mac die passende Apple-Werkzeugkette, ein kompatibles .NET-for-iOS-Workload sowie ein Ziel, das mit Projekt und SDK übereinstimmt. Ein Fehler im lokalen Minimalprojekt gehört daher zur Werkzeugkettenverantwortung, nicht zur Netzwerkdiagnose.

Der Plattformverantwortliche sollte als Stop-Bedingung festlegen: Solange der lokale Minimal-Build nicht reproduzierbar funktioniert, werden weder Pairing-Daten gelöscht noch Zertifikate neu erstellt. Die Übergabe geht mit Log, SDK-Ausgabe, Xcode-Pfad und Ziel-Framework an den Verantwortlichen für die Werkzeugkette.

Zweiter Schritt: Der Windows-Entwickler isoliert Pair to Mac

Pair to Mac nutzt SSH, um von der Entwicklungsumgebung aus den entfernten Mac als Build-Host anzusprechen. Die Microsoft-Learn-Dokumentation zu Pair to Mac beschreibt diesen Aufbau und die Rolle der SSH-Verbindung. Für die Diagnose muss zwischen drei Fehlerklassen unterschieden werden:

• Der Host wird nicht gefunden oder ist über das Netzwerk nicht erreichbar.
• Der Host ist erreichbar, aber Benutzername, Schlüssel oder Berechtigung werden abgelehnt.
• Die Anmeldung funktioniert, doch der Remote-Dienst oder das SDK kann nicht initialisiert werden.

Was ist zu tun, wenn Pair to Mac den Remote Mac nicht findet oder wiederholt nach einer Anmeldung fragt?
Zuerst sollte der Entwickler von Windows aus die Erreichbarkeit von <MAC_HOST> und <SSH_PORT> prüfen und anschließend eine direkte SSH-Anmeldung mit dem vorgesehenen Konto testen. Dabei sind Hostname, Benutzername, Port und Schlüsselpfad exakt aus der Pairing-Konfiguration zu übernehmen. Ein erfolgreicher manueller SSH-Test beweist noch nicht, dass Visual Studio dieselbe Identität oder denselben Port verwendet.

Danach wird der gespeicherte Hosteintrag geprüft. Falls nur die Pairing-Aufzeichnung oder der zugehörige Schlüssel beschädigt ist, sollte ausschließlich diese Verbindung sicher getrennt und neu angelegt werden. Das pauschale Löschen sämtlicher SSH-Schlüssel oder Visual-Studio-Caches kann andere Projekte und Automatisierungen unterbrechen. Vor einer Bereinigung muss daher feststehen, wo der bisherige Schlüssel hinterlegt ist und wie die Verbindung wiederhergestellt wird.

Die Verifikation erfolgt mit einem leeren iOS-MAUI-Projekt:

• Verbindung aus Visual Studio trennen und erneut aufbauen.
• Bekannten Host, Benutzer und Port mit dem Eintrag vergleichen.
• Pairing-Protokoll nach dem ersten Authentifizierungs- oder Initialisierungsfehler durchsuchen.
• Minimalprojekt ohne Geschäftslogik starten.
• Bei Erfolg erst das eigentliche Projekt untersuchen.

Die Zuständigkeit wechselt an die Werkzeugkettenverantwortlichen, sobald Pair to Mac verbunden ist, der Minimal-Build aber auch direkt auf dem Mac fehlschlägt. Bleibt nur der Windows-Remote-Aufruf erfolglos, erhält der DevOps-Verantwortliche die Verbindungsdaten und beide Vergleichslogs.

Dritter Schritt: Der MAUI-Verantwortliche gleicht Xcode und Workloads ab

Ein installierter Projektverweis auf .NET MAUI 10 ist kein Beweis dafür, dass der Mac die erwartete .NET-for-iOS-Version verwendet. Entscheidend sind der aktive .NET-SDK, das Workload-Manifest, die tatsächlich geladene iOS-Toolchain und der von der Shell ausgewählte Xcode-Pfad.

Die Prüfung sollte auf dem Remote Mac und, soweit verfügbar, in der Windows-Buildausgabe dieselben Werte erfassen:

• dotnet --info
• dotnet workload list
• die .NET-for-iOS-Version aus dem ausführlichen Buildlog
• xcode-select -p
• xcodebuild -version
• DEVELOPER_DIR
• Ziel-Framework und Runtime-Identifier

Wie lässt sich eine Abweichung zwischen Xcode 26.6 und dem .NET-for-iOS-Workload beheben?
Zuerst wird anhand der offiziellen Release-Aufzeichnungen festgestellt, welche Xcode-Version der eingesetzte Workload unterstützt. Danach muss geprüft werden, ob die Shell und der Remote-Builddienst dieselbe Xcode-Installation verwenden. Ist nur eine Auswahlvariable falsch, wird die Auswahl auf Aufgabenebene korrigiert. Ist der Workload selbst inkompatibel, wird die offiziell passende Kombination installiert oder der betreffende Dienststand vorübergehend zurückgestellt.

Bei mehreren Xcode-Versionen ist ein globales Umschalten des gesamten Knotens riskant. Eine Aufgabe kann mit einem festgelegten DEVELOPER_DIR ausgeführt werden, sofern der Buildprozess diese Variable kontrolliert übernimmt. Alternativ wird ein zweiter, isolierter Knoten verwendet. Die Entscheidung hängt davon ab, ob andere Projekte dieselbe Xcode-Auswahl benötigen und ob ein Neustart die Auswahl wieder verändert.

Eine Workload-Neuinstallation ist erst dann gerechtfertigt, wenn die Ausgabe eine beschädigte oder unvollständige Installation belegt. Vorher werden die vorhandene SDK-Ausgabe, die Workload-Liste und der Rückweg dokumentiert. Nach einer Neuinstallation muss der Minimal-Build erneut ausgeführt werden; ein wiederhergestelltes Pairing allein ist kein Abnahmekriterium.

Vierter Schritt: Der CI-Verantwortliche prüft SDK, Cache und Befehlsweg

Ein Build aus Visual Studio und ein Build aus einer Windows-Shell können trotz desselben Projekts unterschiedliche Remote-Einstellungen verwenden. Zu vergleichen sind insbesondere Hostadresse, Benutzerkonto, Port, Remote-SDK-Verzeichnis, Arbeitsverzeichnis und der tatsächlich aufgerufene Projekteinstieg.

Der CI-Verantwortliche sollte einen sauberen Vergleich anlegen:

1. Vollständig neues Arbeitsverzeichnis aus einem festgelegten Commit erzeugen.
2. SDK- und Workload-Ausgabe des Mac-Knotens protokollieren.
3. Den Build ohne alte obj- und Binärartefakte starten.
4. Den von Visual Studio erzeugten beziehungsweise verwendeten Zielpfad mit dem Kommandozeilenpfad vergleichen.
5. Nur den ersten abweichenden Parameter weiter untersuchen.

Wie kann die Windows-Kommandozeile einen Remote-MAUI-iOS-Build verifizieren?
Sie sollte denselben Projektpfad, dieselbe Konfiguration, dasselbe Ziel-Framework und dieselbe Pair-to-Mac-Verbindung verwenden wie die IDE. Die konkreten Werte werden als Platzhalter dokumentiert, beispielsweise <PROJEKT>.csproj, <CONFIGURATION> und <TARGET_FRAMEWORK>, damit keine echten Konten, Adressen oder geheimen Pfade in Protokollen landen. Die Dokumentation zur .NET-MAUI-iOS-Veröffentlichung über die Kommandozeile beschreibt die relevanten Veröffentlichungsparameter.

Caches werden nicht als erste Standardmaßnahme gelöscht. Zunächst muss der Fehler zeigen, dass ein veraltetes SDK, ein fremdes Ziel-Framework oder ein beschädigtes obj-Ergebnis beteiligt ist. Eine lokale Bereinigung kann zwar den nächsten Build beeinflussen, sie behebt aber keine falsche Xcode-Auswahl und keine ungültigen Signierungsdaten. Vor dem Entfernen werden Pfad, Commit, verwendete SDK-Version und Wiederherstellungsweg notiert.

Für einen CI-Lauf gehören außerdem ein sauberer Checkout, ein festgelegter Toolchain-Zustand und ein Logartefakt zur Abnahme. Wenn ein frisch geklonter Stand auf demselben Mac funktioniert, der Entwicklerstand aber nicht, wird das Problem an die Projekt- oder Cache-Verantwortung übergeben. Wenn beide Stände scheitern, bleibt der Knoten beziehungsweise seine Werkzeugkette im Fokus.

Fünfter Schritt: Der Release-Verantwortliche trennt Signierung und Geräte

Ein erfolgreicher Debug- oder Simulator-Build sagt wenig über die Veröffentlichung auf ein echtes Gerät aus. Sobald der Fehler erst bei Release, Archivierung, einem Gerät oder einem bestimmten Runtime-Identifier auftritt, wird die Signierung als eigene Fehlerdomäne behandelt.

Zu prüfen sind:

• Signierungsidentität und deren Gültigkeit.
• Passendes Provisioning-Profil.
• Schlüsselbund des Kontos, unter dem der Remote-Dienst läuft.
• Zugriffsrechte auf private Schlüssel.
• Ziel-Runtime und Architektur.
• Sichtbarkeit des Geräts aus dem Remote Mac.
• Unterschiede zwischen interaktivem Login und nicht interaktivem CI-Konto.

Warum funktioniert der Remote-Build, während die MAUI-iOS-Veröffentlichung scheitert?
Ein kompiliertes Ergebnis kann ohne dieselben Zertifikats-, Profil- und Gerätebedingungen entstehen, die für ein signiertes Archiv verlangt werden. Deshalb werden zunächst ein unsignierter beziehungsweise minimal signierter Build und anschließend ein kleiner Signierungstest durchgeführt. Erst wenn beide erfolgreich sind, wird die vollständige Archivierung mit dem vorgesehenen Profil gestartet.

Die offizielle Anleitung zur iOS-Veröffentlichung über die CLI sollte dabei zusammen mit dem vollständigen Log verwendet werden. Ein fehlendes Zertifikat wird nicht durch die Neuinstallation des MAUI-Workloads behoben. Ebenso sollte ein Schlüssel nicht gelöscht werden, solange nicht geklärt ist, welches CI-Konto ihn benötigt und wie er sicher neu hinterlegt wird.

Die Übergabe an den Plattformverantwortlichen enthält daher getrennte Ergebnisse für Build, Signierung, Archiv und Gerätezugriff. Wird nur die Signierung abgelehnt, bleibt die Pair-to-Mac-Konfiguration unverändert.

Sechster Schritt: Reparatur, Rückfall oder neuer Knoten

Die Entscheidung muss aus mehreren Projekten und Zuständen abgeleitet werden, nicht aus einer einzelnen Fehlermeldung. Ein einzelnes Projekt mit einem abweichenden Cache rechtfertigt keinen neuen Remote Mac. Wiederholte Fehler in mehreren Projekten, unterschiedliche SDK-Ausgaben nach Neustarts oder nicht reproduzierbare Xcode-Auswahl sprechen dagegen für eine isolierte Reparatur.

Eine Reparatur ist angemessen, wenn:

• der Mac lokale Minimalprojekte erfolgreich baut,
• die Xcode-Auswahl festgelegt werden kann,
• der Workload eindeutig dokumentiert ist,
• Pair to Mac mit einem Testprojekt funktioniert,
• und der Zustand nach einem Neustart wiederherstellbar ist.

Ein zeitweiser Rückfall oder Parallelbetrieb ist sinnvoll, wenn ein Projekt noch nicht mit dem aktuellen Toolchain-Stand kompatibel ist, während andere Projekte bereits darauf angewiesen sind. Dann werden die Xcode-Auswahl, SDK-Version und Projektzuordnung je Build-Aufgabe festgehalten. Ein globales Umschalten ohne Zuordnung erzeugt neue, schwer nachvollziehbare Fehler.

Ein Neuaufbau wird erst erwogen, wenn die Umgebung trotz dokumentierter Reparaturen driftet, mehrere Projekte betroffen sind oder die Wiederherstellung nach einem Neustart nicht zuverlässig gelingt. Vorher müssen Schlüssel, Profile, Konfigurationsdateien und Pipeline-Geheimnisse sicher exportiert beziehungsweise neu ausstellbar sein. Ein neuer Knoten ohne diese Übergabe verschiebt das Problem nur.

Entscheidungsmatrix vor der nächsten Änderung

Diese Matrix ist bewusst keine automatische Reparaturanweisung. Sie verhindert, dass ein Fehler der Signierung als Netzwerkproblem oder ein fehlerhafter Cache als generelle Inkompatibilität interpretiert wird.

Abschlussprüfung nach der Reparatur

Vor der Freigabe des Knotens wird dieselbe Minimalprojekt-Definition in allen relevanten Zuständen ausgeführt:

• lokaler Mac-Build mit festgelegter Xcode-Auswahl,
• Windows-Build über Pair to Mac,
• sauberer Build nach einem neuen Checkout,
• Wiederverbindung nach einer kontrollierten Trennung,
• Build nach einem Neustart,
• Signierung mit dem vorgesehenen Konto,
• Archivierung oder Veröffentlichung mit einem realistischen Projekt.

Die Prüfungen werden mit Datum, Commit, SDK-Ausgabe, Workload-Version, Xcode-Auswahl und Ergebnis gespeichert. Passwörter, private Schlüssel und vollständige Zertifikatsgeheimnisse gehören nicht in das Protokoll. Für Teams, die einen Mac nicht dauerhaft selbst betreiben möchten, kann ein Remote-Mac-Zugang von RUVCLOUD als separat kontrollierbarer Testknoten geprüft werden. Vor einer Migration sollte jedoch zuerst die bestehende Werkzeugkette beschrieben werden; eine neue Maschine ersetzt keine fehlende Reproduzierbarkeit.

Ein eigener Mac mini kann langfristig sinnvoll sein, wenn ein Team dauerhaft hohe Last, lokale Peripherie oder vollständige Hardwarekontrolle benötigt. Ein Windows- oder Linux-Server bleibt für viele allgemeine CI-Aufgaben günstiger und einfacher, kann aber die Apple-spezifische Build- und Signierungskette nicht vollständig ersetzen. Eine virtuelle Umgebung kann zusätzlich durch Hardwarezugriff, Lizenz- und Stabilitätsfragen begrenzt sein. Wenn nur ein isolierter Testknoten, ein zeitlich begrenzter Upgrade-Versuch oder ein zweiter Xcode-Stand benötigt wird, vermeidet die Miete eines echten Remote Mac dagegen den Kauf ungenutzter Hardware und hält die Umgebung mit vollständigen Berechtigungen getrennt. Die passenden RUVCLOUD-Mietoptionen und Preise sollten dabei erst nach einem erfolgreichen Pairing-, Clean-Build- und Signierungstest bewertet werden.

Der wichtigste Entscheidungspunkt bleibt damit unverändert: Erst den lokalen Minimal-Build auf dem Remote Mac beweisen, dann Pair to Mac und Windows vergleichen, anschließend Signierung separat abnehmen. Sind Werkzeugkette und Zustand reproduzierbar, wird der vorhandene Knoten repariert oder parallel betrieben; bleibt die Umgebung trotz klarer Belege instabil, ist ein isolierter Remote Mac als neuer Test- und Migrationsknoten die sachlichere nächste Maßnahme.