Xcode 27.1 RC Mac Catalyst-Fehler: Was tun? Fehlersuche 2026

Entscheidung: Bei einem Xcode-27.1-RC-Mac-Catalyst-Fehler prüfen Sie zuerst, ob einer der beiden von Apple dokumentierten Fälle vorliegt: ein Fehler durch eine nur für iOS verfügbare API oder ein fehlendes Catalyst-Laufziel. Trennen Sie im ersten Fall den plattformspezifischen Code per bedingter Kompilierung; im zweiten prüfen Sie das Catalyst-Mindestbereitstellungsziel. Für eine Veröffentlichung muss jedes Ziel separat erfolgreich geprüft werden.

Dieser Leitfaden richtet sich an unabhängige Entwickler, die iOS- und Mac-Catalyst-Code gemeinsam pflegen.
Auch kleine Teams mit mehreren Build-Zielen finden hier eine Abgrenzung zwischen Werkzeug- und Projektfehlern.
Wer auf einem Remote Mac oder in einer CI-Umgebung baut, erhält außerdem Kriterien für eine belastbare Abnahme.

Zuletzt aktualisiert am 10.10.2026; die Angaben wurden anhand der Xcode-27.1-RC-Versionshinweise und des Apple-Developer-Veröffentlichungseintrags geprüft.

Xcode-27.1-RC-Mac-Catalyst-Fehler: zwei Fälle statt einer pauschalen Ursache

Apple führt für Xcode 27.1 RC zwei relevante bekannte Probleme im Zusammenhang mit Mac Catalyst auf: Bei der Verwendung von iOS-27.1-spezifischen APIs können Kompilierungsfehler auftreten; außerdem kann bei Projekten mit iOS 27.1 das Mac-Catalyst-Laufziel fehlen. Beide Fälle haben unterschiedliche Workarounds. Die Hinweise gelten für die in den Xcode-Versionshinweisen beschriebenen Fälle, nicht automatisch für andere Xcode-Versionen oder beliebige Compilerfehler.

Ein Fehler wie „undeclared identifier“ oder „has no member“ ist deshalb zunächst ein Symptom, noch keine Diagnose. Entscheidend ist, ob die betroffene Deklaration tatsächlich nur für iOS verfügbar ist und ob der Fehler beim Catalyst-Ziel auftritt. Ein fehlendes Laufziel ist dagegen ein Problem bei der verfügbaren Build- beziehungsweise Ausführungsdestination. Eine Anpassung des Mindestbereitstellungsziels behebt nicht automatisch Fehler in gemeinsamem Quellcode.

Die Zuordnung muss zum konkreten Target passen. Ein erfolgreiches iOS-Ergebnis beweist weder, dass die Catalyst-Codepfade kompilieren, noch dass ein Catalyst-Laufziel verfügbar ist. Ebenso reicht eine fehlende Destination nicht aus, um einen API-Fehler im Quellcode als Werkzeugproblem zu verbuchen.

Für iOS-only-Projekte: zuerst den tatsächlichen Build-Pfad feststellen

Wer ausschließlich eine iOS-App pflegt, sollte nicht allein aus einer Fehlermeldung mit „Catalyst“ auf ein Catalyst-Problem schließen. Prüfen Sie zunächst, ob das Projekt Mac Catalyst für das betreffende Scheme und Target überhaupt aktiviert hat. Projekte können mehrere Targets, Konfigurationen oder gemeinsam genutzte Build-Einstellungen enthalten. Ein Catalyst-Ziel in einem anderen Target sagt noch nichts darüber aus, wo der konkrete Fehler entsteht.

In Xcode zeigt die gewählte Destination, für welche Plattform der Build angefordert wird. Ergänzend können Sie die verfügbaren Ziele für das verwendete Scheme ausgeben lassen:

xcodebuild -showdestinations -scheme "$SCHEME"

Ersetzen Sie $SCHEME durch den Schemenamen des Projekts. Die Ausgabe ist keine Erfolgsmeldung für den Build. Sie zeigt lediglich, welche Ziele Xcode für dieses Scheme anbietet. Wenn der Catalyst-Eintrag fehlt, halten Sie diese Beobachtung getrennt von einem Kompilierungsfehler fest.

Für einen reproduzierbaren Vergleich bauen Sie denselben Commit einmal mit dem iOS-Ziel und einmal mit dem Mac-Catalyst-Ziel. Nutzen Sie dafür die Destinationsangabe, die Xcode tatsächlich für Ihr Scheme ausgibt. Vergleichen Sie anschließend die erste relevante Compilerdiagnose, nicht nur die letzte Zeile des Build-Protokolls. Folgefehler können entstehen, nachdem bereits eine frühere Deklaration nicht aufgelöst wurde.

Für iOS-only-Projekte gilt eine klare Grenze: Wenn Catalyst nicht zum Produktscope gehört und im betroffenen Scheme nicht gebaut wird, ändern Sie nicht vorsorglich die Catalyst-Einstellungen. Dokumentieren Sie stattdessen, welches Target und welche Destination den Fehler auslösen. Dadurch vermeiden Sie, eine iOS-Konfiguration zu verändern, obwohl die Ursache in einem anderen Build-Pfad liegt.

Für gemeinsam genutzten iOS- und Catalyst-Code: iOS-APIs gezielt abgrenzen

Bei gemeinsam genutztem Swift-Code ist die zentrale Frage, ob der betroffene Aufruf auf Mac Catalyst verfügbar ist. Ein API-Name kann im iOS-SDK bekannt sein und dennoch für ein anderes Plattformziel nicht zur Verfügung stehen. Das gilt besonders, wenn ein Projekt neue iOS-27.1-APIs verwendet. Apple benennt diesen Zusammenhang in den bekannten Problemen für Xcode 27.1 RC ausdrücklich.

Prüfen Sie zunächst die Verfügbarkeit der API in der Dokumentation und die Plattform des fehlgeschlagenen Builds. Anschließend trennen Sie nur die Implementierung, die tatsächlich iOS-spezifisch ist. Eine grobe Bedingung, die große Teile der gemeinsamen Logik ausschließt, kann zwar einen einzelnen Fehler beseitigen, aber zugleich Verhalten oder Tests für Mac Catalyst entfernen.

Ein typisches Muster für getrennte Implementierungen sieht so aus:

#if targetEnvironment(macCatalyst)
func performPlatformAction() {
    // Catalyst-kompatibles Verhalten
}
#else
func performPlatformAction() {
    // iOS-spezifische Implementierung
}
#endif

Die Namen und Implementierungen sind Platzhalter und müssen durch die tatsächliche Funktion des Projekts ersetzt werden. Wenn die Unterscheidung nicht nur Catalyst, sondern weitere Plattformen betrifft, muss die Bedingung entsprechend präzisiert werden. Apple beschreibt die Abgrenzung von Plattformcode in der Dokumentation zum Erstellen einer Mac-Version einer iPad-App und zu plattform- und systemversionsabhängigem Code.

Die gemeinsame Schnittstelle sollte dabei stabil bleiben. Wenn die iOS-Implementierung eine Funktion ausführt, die Catalyst nicht anbietet, legen Sie für Catalyst ein fachlich passendes Ersatzverhalten fest: etwa eine alternative Aktion, eine kontrollierte Nichtverfügbarkeit oder eine Rückmeldung an die Oberfläche. Eine leere Implementierung ist nur dann korrekt, wenn das Fehlen dieser Funktion im Produkt ausdrücklich akzeptabel ist.

Für den konkreten Compilerfehler sind sowohl der Bezeichner als auch der betroffene Build-Kontext wichtig. „Undeclared identifier“ kann auf eine fehlende Deklaration, einen nicht importierten Modulbereich, eine falsche Target-Zugehörigkeit oder eine Plattformbedingung zurückgehen. „Has no member“ kann ebenso aus einer anderen API-Version oder einem anderen Typ entstehen. Erst wenn Fehlerstelle, API-Verfügbarkeit und Zielplattform zusammenpassen, ist der bekannte Xcode-Fall eine plausible Erklärung.

Für Projekte ohne Catalyst-Laufziel: Mindestbereitstellungsziel gezielt prüfen

Wenn Xcode kein Mac-Catalyst-Laufziel anbietet, kontrollieren Sie das Catalyst-Mindestbereitstellungsziel des betroffenen Targets. Apples Workaround für den dokumentierten Fall verweist auf eine Anpassung dieses Mindestziels. Das ist kein allgemeiner Reparaturvorschlag für beliebige Build-Fehler und auch keine Aufforderung, iOS- und Catalyst-Ziele gleichzusetzen.

Die Einstellungen können je nach Projektstruktur auf Projektebene, Target-Ebene oder in einer Build-Konfiguration überschrieben sein. Prüfen Sie daher die wirksamen Werte für genau das Scheme, das die Destination vermissen lässt. Apples Referenz zu Build-Einstellungen beschreibt, wie Build-Einstellungen eingeordnet werden. Änderungen an einem übergeordneten Projektwert können mehrere Targets beeinflussen; eine lokale Anpassung am Catalyst-Target kann dagegen wirkungslos bleiben, wenn eine Konfiguration den Wert überschreibt.

Gehen Sie in dieser Reihenfolge vor:

1. Öffnen Sie das betroffene Scheme und notieren Sie das zugehörige Target sowie die aktive Konfiguration.
2. Kontrollieren Sie, ob Mac Catalyst für dieses Target tatsächlich als unterstützte Plattform eingerichtet ist.
3. Prüfen Sie den effektiven Wert des Catalyst-Mindestbereitstellungsziels, statt nur den Projektwert anzusehen.
4. Vergleichen Sie die Einstellung mit Apples Workaround für den dokumentierten Xcode-27.1-RC-Fall.
5. Ändern Sie nur das betroffene Catalyst-Ziel und führen Sie anschließend die Destination-Abfrage erneut aus.

Die Änderung muss mit den tatsächlich unterstützten Betriebssystemen und Produktanforderungen vereinbar sein. Ein niedrigeres Mindestziel kann ältere Systeme einschließen, aber zugleich zusätzliche Test- und Supportpflichten bedeuten. Falls das Produkt diese Systeme nicht unterstützen soll, ist eine Änderung nicht automatisch die richtige Entscheidung. Halten Sie fest, warum das Ziel angepasst wurde und welche Betriebssysteme anschließend getestet werden müssen.

Hinweis: Das Catalyst-Mindestbereitstellungsziel zu ändern ist nur für das fehlende Laufziel im beschriebenen bekannten Fall eine passende Richtung. Es ersetzt weder die Prüfung von API-Verfügbarkeit noch die Korrektur plattformspezifischen Codes.

Für Teams mit mehreren Targets: einen Fehler nicht auf alle Plattformen übertragen

In Projekten mit mehreren Targets ist ein einzelner erfolgreicher Build keine ausreichende Abnahme. Ein iOS-App-Target, ein Catalyst-Target und zusätzliche Komponenten können unterschiedliche Build-Einstellungen, Compilerbedingungen und Abhängigkeiten verwenden. Der gleiche Quellcode kann deshalb für ein Target erfolgreich und für ein anderes fehlerhaft sein.

Apple beschreibt das Anlegen und Konfigurieren eigener Targets in der Dokumentation zur Target-Konfiguration. Für die Fehlersuche ist vor allem wichtig, jede relevante Kombination aus Target, Scheme und Destination getrennt zu erfassen. Prüfen Sie, ob eine Datei nur einem Target zugeordnet ist, ob ein Build-Setting überschrieben wird und ob bedingte Kompilierung die erwartete Implementierung auswählt.

Ein schlanker Vergleich verwendet denselben Commit und dieselben Abhängigkeiten. Zuerst bauen Sie das iOS-Ziel, dann Catalyst. Weicht nur Catalyst ab, untersuchen Sie zuerst Plattformbedingungen und Catalyst-Einstellungen. Scheitern beide Ziele an derselben Stelle, spricht das eher für einen gemeinsamen Code- oder Abhängigkeitsfehler als für das Fehlen einer Catalyst-Destination. Diese Abgrenzung ist ein Diagnosehinweis, kein Beweis für die Ursache.

Bewahren Sie die relevanten Protokolle getrennt auf. Eine kurze Notiz sollte mindestens Scheme, Target, gewählte Destination, Xcode-Buildversion, macOS-Version und erste wirksame Fehlermeldung enthalten. Die Angaben helfen dabei, einen Werkzeugunterschied von einer Änderung im Projekt zu unterscheiden. Vermeiden Sie es, nur den letzten Fehler aus dem Build-Fenster zu kopieren: Er kann lediglich eine Folge des ursprünglichen Problems sein.

Für Remote Mac und CI: Build-Erfolg plattformweise nachweisen

Auf einem Remote Mac oder in CI kommen zusätzliche Fehlerquellen hinzu. Eine andere Xcode-Installation, eine abweichende macOS-Version, fehlende lokale Projektänderungen oder ein anderes Scheme können Ergebnisse verändern. Das ist besonders relevant, wenn lokal nur das iOS-Ziel gebaut wurde, während die Veröffentlichung auch Mac Catalyst voraussetzt.

Beginnen Sie mit einer reproduzierbaren Umgebungserfassung. Im Build-Protokoll sollten die tatsächliche Xcode-Version und die macOS-Version erscheinen. Dazu kommen Commit-Identifikation, Scheme, Target, Destination und die erste aussagekräftige Diagnose. Stimmen diese Angaben zwischen lokaler und entfernter Umgebung nicht überein, vergleichen Sie zunächst die Werkzeug- und Projekteinstellungen, bevor Sie den Fehler einer Plattform zuschreiben.

Nach einer Korrektur müssen mindestens die betroffenen Ziele unabhängig gebaut werden. Ein erfolgreicher iOS-Build bestätigt nur den iOS-Buildpfad. Für Catalyst sind zusätzlich das Vorhandensein einer geeigneten Destination, ein erfolgreicher Catalyst-Build und die Prüfung des Archivs relevant. Apples Hinweise zur Verteilung von Apps für Beta-Tests und Veröffentlichungen ordnen Archive und den weiteren Distributionsweg ein.

Mit xcodebuild lässt sich der Build in einer automatisierten Umgebung nachvollziehbar starten. Verwenden Sie für -destination den Eintrag, den -showdestinations für das konkrete Scheme ausgibt:

xcodebuild \
  -scheme "$SCHEME" \
  -destination "$DESTINATION" \
  build

Die Variablen sind bewusst nicht mit Beispielwerten belegt. Destination-Namen hängen vom verfügbaren Ziel und der Xcode-Umgebung ab. Kopieren Sie deshalb nicht ungeprüft einen Wert aus einem fremden Projekt. Bewahren Sie den vollständigen Aufruf und die Ausgabe als Teil des CI-Protokolls auf. Für die Release-Abnahme ist außerdem ein Archive-Schritt erforderlich, wenn der vorgesehene Veröffentlichungsweg ein Archiv voraussetzt; ein erfolgreicher gewöhnlicher Build ist kein Ersatz dafür.

Abnahme vor der Veröffentlichung: Ergebnisse je Ziel festhalten

Die Entscheidung, ob ein Release weiterlaufen kann, hängt davon ab, ob Mac Catalyst Teil des Produktumfangs ist. Ist Catalyst für die anstehende Veröffentlichung vorgesehen, darf ein erfolgreicher iOS-Build nicht als Freigabe für beide Plattformen gelten. Ist Catalyst nicht im aktuellen Umfang, muss das Team dennoch sicherstellen, dass das iOS-Target nicht durch eine unnötige Catalyst-Änderung beeinträchtigt wurde.

Verwenden Sie diese ausführbare Prüfliste nach jeder Anpassung:

• [ ] Xcode-Version und macOS-Version der verwendeten Umgebung im Build-Protokoll festgehalten.
• [ ] Betroffenes Scheme, Target, Commit und Destination benannt.
• [ ] Erste relevante Fehlermeldung gespeichert und dem konkreten Ziel zugeordnet.
• [ ] Bei API-Fehlern die Verfügbarkeit für iOS und Mac Catalyst geprüft.
• [ ] iOS-spezifischen Code bedingt getrennt und eine fachlich passende Catalyst-Alternative festgelegt.
• [ ] Bei fehlendem Laufziel ausschließlich die wirksame Catalyst-Mindestbereitstellungseinstellung geprüft und gegebenenfalls gezielt angepasst.
• [ ] iOS- und Catalyst-Build aus demselben Commit unabhängig ausgeführt.
• [ ] Für den Release-Umfang erforderliches Archive erstellt und dessen Ergebnis geprüft.
• [ ] Release-Entscheidung dokumentiert: Catalyst freigegeben, vorerst ausgeschlossen oder erneute Prüfung nach einem Werkzeugupdate erforderlich.

Ein Eintrag wie „Build erfolgreich“ ist für eine belastbare Abnahme zu ungenau. Die Dokumentation sollte erkennen lassen, welches Ziel gebaut wurde und ob ein Archive erzeugt wurde. Wenn Catalyst vorübergehend nicht freigegeben wird, benennen Sie das ausdrücklich. Andernfalls kann ein Team später einen erfolgreichen iOS-Lauf irrtümlich als plattformübergreifende Bestätigung lesen.

Wann sich ein Remote Mac für die Reproduktion lohnt

Für eine einmalige Quellcodekorrektur genügt häufig die vorhandene Entwicklungsumgebung. Ein Remote Mac ist vor allem dann sinnvoll, wenn ein Team keinen eigenen Mac für wiederholbare Xcode- und Catalyst-Builds bereitstellen kann oder eine getrennte Build-Umgebung benötigt. Er löst jedoch keinen Fehler in einer falschen Plattformbedingung und ersetzt keine Prüfung der Zielkonfiguration. Zugangsschutz, Verwaltung von Signiermaterial und die Ablage von Build-Artefakten müssen weiterhin zum Sicherheitsmodell des Teams passen.

Wer vor der Einrichtung zunächst die Umgebungsmöglichkeiten einordnen möchte, kann die Informationen zu Remote-Mac-Entwicklung bei SFTPMAC prüfen. Für eine Entscheidung, ob Miete oder eigene Hardware zum Nutzungsprofil passt, sind auch die Mietkosten für Mac mini relevant. Eine Miete ist eher für zeitlich begrenzte Reproduktionen, parallele Plattformtests oder eine zusätzlich benötigte Build-Umgebung geeignet. Bei dauerhaft hoher Auslastung, Bedarf an physischen Schnittstellen oder strengen lokalen Sicherheitsvorgaben kann ein eigener Mac die passendere Lösung sein.

Wenn die bisherige Umgebung nur ein iOS-Ziel verlässlich baut, bleiben Catalyst-Fehler bis zur gezielten Prüfung verborgen. Lokale Hardware kann außerdem durch belegten Speicher, gemeinsam genutzte Ressourcen oder manuelle Konfigurationsabweichungen zum Engpass werden. Ein gemieteter Mac von SFTPMAC kann für den begrenzten Zeitraum der Reproduktion eine separate macOS-Umgebung bereitstellen, ohne dass dafür dauerhaft zusätzliche Hardware angeschafft werden muss. Entscheidend ist nicht die Mietentscheidung allein, sondern die Abnahme: Beide vorgesehenen Targets müssen aus demselben Commit nachvollziehbar gebaut und – sofern für den Release erforderlich – archiviert werden.