Die Flutter-3.47.0-Release-Notes führen eine Anpassung auf, mit der Flutter den Pfad zu DeviceHub.app in Xcode 27 berücksichtigt. Wenn Flutter 3.47 in Xcode 27 keinen Simulator findet, aktualisieren oder fixieren Sie zuerst das Flutter-SDK auf eine Version mit dieser Anpassung. Prüfen Sie danach das tatsächlich ausgewählte Xcode und den installierten Simulator-Laufzeitstand. Löschen Sie vor diesen Kontrollen weder Simulator-Daten noch installieren Sie Xcode neu.

Für Flutter-Entwickler, deren flutter devices nach dem Xcode-Wechsel keine iOS-Geräte mehr zeigt oder der Simulator nicht startet.
Für CI-Ingenieure, deren Build auf einem Remote Mac funktioniert, die Simulator-Erkennung oder der Testlauf jedoch scheitert.
Für Plattformverantwortliche, die den Fehler eingrenzen müssen, ohne einen gemeinsam genutzten Knoten vorschnell zurückzusetzen.

Der Zeitplan für die Diagnose: erst sichern, dann den Fehler eingrenzen

Diese Woche: Erfassen Sie zunächst Flutter-Pfad, Flutter-Version, ausgewähltes Xcode und die betroffenen Laufzeiten. Danach prüfen Sie die Geräteerkennung mit Flutter und den Start unabhängig davon über die Xcode-Werkzeuge. Erst wenn diese Ergebnisse auf dieselbe Fehlerursache zeigen, ändern Sie SDK oder Knoten.

Die Fehlermeldung „kein Simulator“ beschreibt nicht zwingend einen einzigen Fehler. In der Praxis müssen Sie drei Stationen auseinanderhalten:

  • Kompilierung: Kann xcodebuild das Projekt bauen? Ein erfolgreicher Build beweist nicht, dass Flutter einen Simulator erkennt.
  • Geräteerkennung: Liefert flutter devices den gewünschten Simulator? Das ist ein eigener Schritt vor dem Start der App.
  • Grafischer Start und Test: Kann der Simulator tatsächlich geöffnet werden, und läuft die App darin? Ein erkannter Gerätename beweist noch keinen erfolgreichen Start.

Xcode 27 verwendet Device Hub für die Verwaltung von Geräten und Simulatoren. Die Flutter-Dokumentation beschreibt den Unterschied zur Simulator-App in früheren Xcode-Versionen; auch die Apple-Informationen zu Xcode 27 erklären die Änderungen an der Entwicklungsumgebung. Ein Werkzeug, das ausschließlich einen älteren Anwendungspfad erwartet, kann deshalb bei der Erkennung scheitern. Das ist eine plausible Ursache, aber kein Beleg dafür, dass jeder Startfehler durch dieselbe Änderung entsteht.

Wichtig: Ein erfolgreiches flutter build ios und ein fehlgeschlagenes flutter devices widersprechen sich nicht. Der Build prüft nicht automatisch, ob Flutter den gewünschten Simulator auffinden und starten kann.

Flutter-Version gegen Device-Hub-Pfad prüfen

Die wichtigste Versionsfrage lautet nicht nur „Ist Flutter aktuell?“, sondern: Verwendet der fehlgeschlagene Aufruf tatsächlich ein Flutter-SDK, dessen Tool den Device-Hub-Pfad behandelt? Die Flutter-3.47.0-Veröffentlichungshinweise dokumentieren diese Anpassung. Daraus folgt nicht, dass jede andere Inkompatibilität in Ihrem Projekt oder auf Ihrem Knoten ebenfalls behoben ist.

Wie erkennt Flutter 3.47 die Simulatoren aus Xcode 27? Mit der in den Veröffentlichungshinweisen aufgeführten Device-Hub-Pfadanpassung kann Flutter den geänderten Anwendungspfad berücksichtigen. Sie müssen trotzdem prüfen, dass Ihr Terminal, Ihre IDE und der CI-Prozess diese Flutter-Version wirklich aufrufen. Eine installierte Version hilft nicht, wenn ein anderer SDK-Pfad Vorrang hat.

Prüfen Sie die verwendeten Werkzeuge in genau der Umgebung, in der der Fehler auftritt:

which flutter
flutter --version
flutter doctor -v

Notieren Sie die vollständigen Ausgaben, bevor Sie etwas ändern. which flutter zeigt, welches ausführbare Programm die aktuelle Shell verwendet; flutter --version gibt Auskunft über den aufgerufenen SDK-Stand. flutter doctor -v ergänzt die Diagnose um Hinweise zur Entwicklungsumgebung. Die Flutter-Anleitung für iOS-Entwicklung erläutert die Voraussetzungen und die zugehörigen Werkzeuge.

Auf einem Rechner mit mehreren Flutter-Installationen ist ein Unterschied zwischen Terminal und IDE ein wichtiger Hinweis: Eine IDE kann ein anderes SDK verwenden als die Shell. Auch ein CI-Runner kann unter einem eigenen Benutzerkonto starten und deshalb eine andere Shell-Konfiguration oder einen anderen Suchpfad haben. Vergleichen Sie die Ausgaben im Fehlerfall direkt; verlassen Sie sich nicht darauf, dass eine manuelle Prüfung in einer interaktiven Sitzung dieselbe Umgebung abbildet.

Nach dem Wechsel auf Xcode 27: Was sollten Sie zuerst prüfen? Erfassen Sie zuerst den Flutter-Pfad und die Version, dann die Xcode-Auswahl. Wenn tatsächlich ein älteres Flutter-Werkzeug aufgerufen wird, wechseln Sie kontrolliert auf eine Version mit der dokumentierten Device-Hub-Behandlung oder fixieren Sie diese Version für den betroffenen Workflow. Löschen Sie nicht zugleich Caches, Simulator-Daten und SDK-Installationen: Sonst können Sie nicht mehr erkennen, welche Änderung den Fehler beeinflusst hat.

Die Flutter-Problemerfassung zur Device-Hub-Anpassung ist eine zusätzliche Referenz, wenn Sie den Zusammenhang zwischen Pfadänderung und Werkzeugverhalten nachverfolgen wollen. Verwenden Sie sie als Beleg für den konkreten Änderungsverlauf, nicht als Diagnose für jeden lokalen Fehler.

Xcode-Auswahl gegen Flutter-SDK abgleichen

Dass Xcode installiert ist, bedeutet nicht automatisch, dass alle Prozesse dieses Xcode verwenden. Auf einem Entwicklungsrechner können Terminal, IDE und CI-Runner voneinander abweichen. Prüfen Sie daher den ausgewählten Entwicklerpfad und die Version in jeder betroffenen Sitzung:

xcode-select -p
xcodebuild -version

Die Ausgabe von xcode-select -p zeigt den ausgewählten Entwicklerpfad. xcodebuild -version hilft zu kontrollieren, ob der aufrufende Prozess tatsächlich die erwartete Xcode-Installation verwendet. Apples Referenz zu den Xcode-Kommandozeilenwerkzeugen beschreibt diese Werkzeuge und ihre Verwendung.

Device Hub ist geöffnet, aber flutter devices zeigt kein Gerät. Behandeln Sie das zunächst als Erkennungsfehler, nicht als Beweis für eine defekte Laufzeit. Prüfen Sie den Flutter-Pfad und die Xcode-Auswahl im selben Benutzerkontext, in dem der Befehl fehlschlägt. Danach vergleichen Sie, ob Xcode selbst den betreffenden Simulator bereitstellt und ob die Kommandozeilenwerkzeuge ihn sehen.

Unter CI sollten Sie die Befehle im Job oder in einem diagnostischen Schritt ausführen, nicht nur per SSH in einer persönlichen Sitzung. Ein interaktiver Login kann andere Umgebungsvariablen, Shell-Profile und Werkzeugpfade besitzen als der Runner-Prozess. Sichern Sie die Ausgabe gemeinsam mit dem fehlgeschlagenen Job-Log. So können Sie später feststellen, ob ein Wechsel des SDK oder des Xcode-Pfads die Ursache verändert hat.

Wenn Sie den Xcode-Pfad korrigieren, dokumentieren Sie den vorherigen Wert und den vorgesehenen Rückweg. Bei gemeinsam genutzten Knoten kann eine globale Änderung laufende Projekte beeinflussen. Ändern Sie die Auswahl deshalb nur nach Abstimmung mit den anderen Workloads und prüfen Sie anschließend sowohl den betroffenen Flutter-Aufruf als auch einen unabhängigen Xcode-Aufruf.

Simulator erkannt gegen Simulator gestartet abgrenzen

Erst nachdem Flutter und Xcode korrekt ausgewählt sind, lohnt sich der Blick auf die Simulator-Laufzeit. Eine Installation kann fehlen, für das ausgewählte Xcode nicht verfügbar sein oder zwar erkannt werden, aber beim Start scheitern. Diese Fälle sehen aus der Perspektive eines fehlgeschlagenen Tests ähnlich aus, erfordern aber unterschiedliche Maßnahmen.

Prüfen Sie zunächst mit den bereitgestellten Werkzeugen, welche Geräte und Laufzeiten sichtbar sind:

xcrun simctl list devices available
flutter devices -v

Die erste Ausgabe zeigt, welche verfügbaren Simulatorgeräte die Xcode-Werkzeuge melden. Die ausführliche Flutter-Ausgabe kann zusätzlich Hinweise darauf liefern, wie Flutter die Geräteerkennung durchführt. Vergleichen Sie beide Resultate, statt aus einer einzelnen Fehlermeldung auf die Ursache zu schließen.

Wenn Xcode den gewünschten Simulator nicht anbietet, prüfen Sie die installierten Komponenten über den vorgesehenen Xcode- oder Systemeinstieg. Apple beschreibt das Installieren zusätzlicher Komponenten in der Anleitung zu Xcode-Komponenten. Die Laufzeit muss zur tatsächlich ausgewählten Xcode-Installation passen; die bloße Existenz eines Simulator-Eintrags in einer anderen Installation reicht für den betroffenen Prozess nicht aus.

Wenn Xcode den Simulator sieht, Flutter jedoch nicht, kehren Sie zur SDK-Version und zum tatsächlich aufgerufenen Flutter-Pfad zurück. Wenn beide Werkzeuge das Gerät sehen, der Start aber scheitert, untersuchen Sie den Startpfad und die Laufzeit. Der Xcode-27-Veröffentlichungshinweis von Apple ist die maßgebliche Referenz für versionsbezogene Änderungen; er ersetzt jedoch keine Prüfung des lokalen Zustands.

Wie unterscheiden Sie auf einem Remote Mac einen Pfadfehler von einem Laufzeitfehler? Wenn Xcode das Gerät nicht auflistet, prüfen Sie zuerst die Laufzeitinstallation und die Xcode-Auswahl. Wenn Xcode das Gerät auflistet, Flutter es aber nicht findet, vergleichen Sie Flutter-Version und Flutter-Pfad. Wenn beide es finden, der Start aber fehlschlägt, sichern Sie die Startausgabe und untersuchen Sie die Laufzeit- oder Startkette. Diese Aufteilung verhindert, dass Sie einen SDK-Fehler durch eine Neuinstallation der Laufzeit zu überdecken versuchen.

Prüfliste für eine sichere Korrektur

Führen Sie die folgenden Kontrollen in der betroffenen Umgebung aus und notieren Sie jede Änderung. Auf einem CI-Knoten halten Sie die Ausgabe im Job-Artefakt oder in der vorgesehenen Betriebsdokumentation fest.

  • [ ] Sichern Sie den vollständigen Fehlertext und den fehlgeschlagenen Befehl.
  • [ ] Erfassen Sie which flutter, flutter --version und flutter doctor -v in der betroffenen Shell.
  • [ ] Erfassen Sie xcode-select -p und xcodebuild -version im selben Benutzerkontext.
  • [ ] Vergleichen Sie Flutter-SDK und Xcode-Auswahl zwischen Terminal, IDE und CI-Runner.
  • [ ] Prüfen Sie mit xcrun simctl list devices available, ob die erwartete Laufzeit und das Gerät sichtbar sind.
  • [ ] Vergleichen Sie die Geräteausgabe von Xcode mit flutter devices -v.
  • [ ] Ändern Sie nur die belegte Ursache: Flutter-Version, Xcode-Auswahl oder fehlende beziehungsweise nicht verfügbare Laufzeit.
  • [ ] Wiederholen Sie den Test mit dem echten Projekt und halten Sie Erkennung, Start und Testergebnis getrennt fest.

Die Ergebnisse ergeben eine belastbare Entscheidungsfolge:

  • Xcode sieht den Simulator, Flutter nicht: Prüfen Sie zuerst Flutter-Version und SDK-Pfad. Falls die aufgerufene Version die Device-Hub-Behandlung nicht enthält, fixieren oder aktualisieren Sie das SDK kontrolliert.
  • Weder Xcode noch Flutter sieht den Simulator: Prüfen Sie die Auswahl der Xcode-Installation und den Status der benötigten Laufzeit.
  • Beide sehen den Simulator, aber der Start schlägt fehl: Untersuchen Sie Startprotokoll und Laufzeitstatus, statt erneut den Device-Hub-Pfad zu ändern.
  • Nur CI weicht ab: Behandeln Sie den Runner als eigene Umgebung. Vergleichen Sie Benutzerkonto, Werkzeugpfade und Job-Ausgabe, bevor Sie gemeinsame Knoten verändern.

Reparatur gegen Rücksetzen: erst Belege, dann Eingriff

Das Entfernen von Simulator-Daten kann lokale Zustände und Testdaten löschen. Eine Neuinstallation von Xcode benötigt Zeit und kann andere Projekte oder festgelegte Toolchains beeinträchtigen. Beides ist keine sinnvolle erste Maßnahme, wenn noch nicht klar ist, ob Flutter ein falsches SDK aufruft oder Xcode selbst eine andere Installation ausgewählt hat.

Sichern Sie vor einem destruktiven Eingriff mindestens die Werkzeugpfade, Versionsausgaben, vollständigen Fehlerprotokolle und den betroffenen Simulatorzustand. Legen Sie außerdem fest, wie Sie zum vorherigen Zustand zurückkehren: etwa durch Wiederherstellung der zuvor ausgewählten Xcode-Installation oder des festgelegten Flutter-SDKs. Bei einem gemeinsam genutzten CI-Knoten informieren Sie die Verantwortlichen und prüfen Sie, ob andere Jobs dieselbe Laufzeit verwenden.

Die Fehlerbehebung gilt erst dann als bestätigt, wenn Ihr Projekt die relevanten Stationen durchlaufen hat. Ein einzelner erfolgreicher Geräteaufruf beweist noch nicht, dass App-Start und automatisierter Test ebenfalls funktionieren. Halten Sie deshalb die Ergebnisse getrennt fest: Flutter-Geräteerkennung, Simulatorstart, Projekt-Build und Testlauf. Scheitert nur ein Abschnitt, setzen Sie die Diagnose an genau diesem Abschnitt fort, statt alle Werkzeuge erneut aufzusetzen.

Wie weisen Sie die Reparatur in Ihrem Projekt nach? Verwenden Sie das tatsächliche Projekt und das im CI-Workflow vorgesehene Simulatorziel. Prüfen Sie zunächst, ob Flutter das Ziel meldet, starten Sie anschließend die App und führen Sie zuletzt den vorgesehenen Test aus. Wenn die Geräteerkennung funktioniert, der Start aber nicht, prüfen Sie die Laufzeit; wenn die Erkennung bereits scheitert, gehen Sie zurück zu Flutter-Version und Xcode-Auswahl.

Wann ein Remote Mac die bessere Betriebsentscheidung ist

Wenn sich der Fehler auf ein inkonsistentes lokales Setup zurückführen lässt, beheben Sie zunächst genau diese Abweichung. Für ein Team, das regelmäßig iOS-Simulatoren und Xcode-CI benötigt, kann ein dauerhaft verfügbarer macOS-Ausführungsort dagegen besser kontrollierbar sein als ein Entwicklerrechner, der nicht immer eingeschaltet ist. Ein Linux-Host ersetzt die macOS-Werkzeugkette dabei nicht.

Vergleichen Sie nüchtern mit Ihrer aktuellen Lösung: Ein lokaler Mac bindet Hardwarebudget und muss für einen dauerhaft verfügbaren Runner eingeschaltet bleiben. Eine selbst verwaltete VM oder ein nicht offiziell unterstützter macOS-Aufbau kann zusätzliche Pflege und schwer reproduzierbare Zustände verursachen. Ein vorhandener Linux-Runner kann zwar allgemeine CI-Aufgaben übernehmen, stellt aber kein Xcode für iOS-Builds bereit. Umgekehrt ist ein gemieteter Remote Mac nicht automatisch passend, wenn Sie dauerhaft hohe Last, bestimmte physische Anschlüsse oder lokale Bedienung benötigen.

Wenn Ihnen für Tests und CI vor allem eine verfügbare macOS-Umgebung fehlt, können Sie die Remote-Mac-Optionen von VMSPIN prüfen und die Preisübersicht mit Ihrer tatsächlichen Nutzung vergleichen. Validieren Sie zuerst Ihr Flutter-Projekt, die Xcode-Auswahl und den Simulatorablauf auf einer geeigneten Umgebung; entscheiden Sie anschließend, ob ein Remote-Knoten zu Ihrem Betriebsmodell passt. Für einen zeitlich begrenzten Test oder eine CI-Validierung kann Mieten flexibler sein als ein sofortiger Hardwarekauf. Bei dauerhafter, vorhersehbarer Auslastung oder benötigter lokaler Hardware kann ein eigener Mac die bessere Wahl bleiben.

Zuletzt aktualisiert am 30.09.2026. Geprüft anhand der Flutter-3.47.0-Veröffentlichungshinweise, der Flutter-iOS-Dokumentation und der Xcode-27-Veröffentlichungshinweise von Apple.