Stand: 01.09.2026. Die Angaben zu Visual Studio 2026 und .NET MAUI wurden anhand der aktuellen Microsoft-Dokumentation zu Hot Restart und der Dokumentation zu Pair to Mac geprüft.
SECTION 01 Zeitplan und Empfehlung für diese Woche
Die Microsoft-Dokumentation bestätigt, dass Visual Studio 2026 iOS Hot Restart nicht verfügbar ist. Das ist keine gewöhnliche Installationsstörung, die Sie durch eine weitere Reparatur des Workloads beheben. Lassen Sie Windows als Hauptumgebung für Quellcode und Projektverwaltung bestehen, und richten Sie Pair to Mac zu einer erreichbaren Mac-Instanz ein. Dieser Mac übernimmt iOS-Kompilierung, Simulator, Signierung und Veröffentlichung.
| Zeitpunkt | Entscheidung oder Meilenstein | Was Sie konkret erledigen |
|---|---|---|
| Heute | Ursache bestätigen | Visual-Studio-Version, .NET-MAUI-Arbeitslast und Hot-Restart-Erwartung dokumentieren; nicht sofort neu installieren |
| Diese Woche | Pair to Mac herstellen | Mac-Netzwerk, Remote Login, Benutzerrechte, SSH-Anmeldung und Xcode prüfen |
| Danach | Build-Kette validieren | Abhängigkeiten wiederherstellen, Simulator-Build ausführen und eine signierte Archive-Variante erzeugen |
| Vor der Veröffentlichung | Produktionsprüfung | Zertifikat, privaten Schlüssel, Provisioning Profile und Upload-Zugang getrennt testen |
| Bei wiederholten Ausfällen | Betriebsmodell wählen | Visual Studio 2022 nur für kurzfristiges Debugging, Remote Mac für wiederholbare Builds oder beide Umgebungen kombiniert einsetzen |
Wer sollte diese Anleitung lesen?
Sie sind hier richtig, wenn Sie nach dem Upgrade auf Visual Studio 2026 den Hot-Restart-Einstieg nicht mehr finden und eine .NET-MAUI-iOS-Anwendung weiterentwickeln müssen.
Die Anleitung ist außerdem für Windows-Entwickler ohne lokalen Mac sowie für kleine Teams gedacht, die aus einem manuellen Debugging-Ablauf eine dauerhaft erreichbare Build-Umgebung machen möchten.
SECTION 02 Funktionsgrenze statt Installationsfehler
Die wichtigste Unterscheidung lautet: Ein verschwundener Menüpunkt ist nicht dasselbe wie ein beschädigtes Visual-Studio-Setup. Microsoft beschreibt Hot Restart in der aktuellen Dokumentation für Visual Studio 2022; für Visual Studio 2026 ist die Funktion laut dem festgelegten Dokumentationsstand nicht unterstützt. Eine Reparaturinstallation kann daher keine nicht unterstützte Funktion zurückbringen. Maßgeblich ist die offizielle Hot-Restart-Beschreibung von Microsoft, nicht ein einzelner Eintrag in Ihrer Arbeitslastauswahl.
Hot Restart war vor allem für einen begrenzten Entwicklungsfall gedacht: Sie konnten Änderungen aus Visual Studio auf ein iOS-Gerät übertragen, ohne für jeden kurzen Test den vollständigen klassischen Mac-Build-Ablauf zu verwenden. Daraus folgt jedoch keine vollständige iOS-Toolchain. Abhängigkeiten, Xcode-Version, Zertifikate, Provisioning Profile, Archive und die Übergabe an App Store Connect bleiben eigene Prüfungen.
Warum fehlt iOS Hot Restart in Visual Studio 2026?
Nach dem geprüften Microsoft-Stand ist die Ursache die fehlende Unterstützung in Visual Studio 2026, nicht zwingend ein Fehler in Ihrem Projekt. Prüfen Sie die Versionsangabe und die installierte .NET-MAUI-Arbeitslast einmal, bevor Sie weitere Änderungen vornehmen. Wenn diese Werte stimmen, sparen Sie sich wiederholte Reparatur- und Neuinstallationen.
Für Ihre Entscheidung gelten zwei klare Abbruchbedingungen:
- Bleiben Sie vorübergehend bei Visual Studio 2022, wenn Sie ausschließlich kurze Tests auf einem bereits eingerichteten Gerät benötigen und keine neue Produktionsumgebung aufbauen wollen.
- Wechseln Sie zu Pair to Mac, sobald Sie regelmäßig iOS kompilieren, den Simulator verwenden, signierte Archive erzeugen oder App-Versionen veröffentlichen müssen.
- Behandeln Sie Visual Studio 2022 nicht als langfristigen Ersatz für eine Mac-Build-Umgebung. Microsoft dokumentiert den aktuellen Funktionsumfang, aber keine Zusage, wie lange ein bestimmter Hot-Restart-Ablauf künftig unverändert bestehen bleibt.
Die Plattformabgrenzung ist ebenfalls eindeutig: .NET MAUI unterstützt iOS als Zielplattform, die dafür erforderliche Apple-Toolchain läuft jedoch in einer macOS-Umgebung. Die Microsoft-Übersicht der unterstützten Plattformen hilft Ihnen dabei, Zielplattform und Entwicklungsbetrieb nicht miteinander zu verwechseln.
SECTION 03 Pair-to-Mac-Verbindung
Ein Pairing-Fehler entsteht häufig vor dem eigentlichen Projekt. Wenn Visual Studio keinen Host entdeckt, ist eine Neuinstallation auf Windows selten der erste sinnvolle Schritt. Prüfen Sie die Verbindung in der Reihenfolge, in der sie technisch aufgebaut wird.
- Netzwerk-Erreichbarkeit testen: Stellen Sie sicher, dass Windows den Mac über eine stabile Route erreicht. Bei einem Mac im Rechenzentrum muss die Adresse aus Ihrem Verwaltungs- oder privaten Netzwerk erreichbar sein; eine automatische lokale Erkennung ist über getrennte Netze nicht zuverlässig.
- Remote Login aktivieren: Öffnen Sie auf macOS die Systemeinstellungen für Freigaben und aktivieren Sie Remote Login. Der erlaubte Benutzer muss ausdrücklich für die Anmeldung zugelassen sein.
- SSH-Anmeldung isoliert prüfen: Testen Sie mit einem unkritischen, anonymisierten Beispielkonto, ob die Anmeldung grundsätzlich funktioniert. Verwenden Sie in Dokumentation und Screenshots Platzhalter wie
<MAC_IP>,<MAC_USER>und<SSH_KEY>. - Firewall und Zugriffspfad prüfen: Kontrollieren Sie die macOS-Firewall, vorgelagerte Netzwerkregeln und gegebenenfalls die Zugriffsliste des Hostings. Ein erreichbarer Webdienst beweist nicht, dass SSH erreichbar ist.
- Host manuell hinzufügen: Wenn die automatische Suche scheitert, tragen Sie die IP-Adresse beziehungsweise den vorgesehenen Hostnamen manuell ein. Die automatische Erkennung und die tatsächliche SSH-Erreichbarkeit sind zwei verschiedene Vorgänge.
- Fehlerphase bestimmen: Vergleichen Sie Windows- und Mac-Protokolle. Suchen Sie zuerst nach dem letzten erfolgreichen Schritt: Erkennung, Authentifizierung oder Installation der Remote-Komponenten.
- Bereinigung nur mit Rückfallplan: Löschen Sie SSH-Schlüssel, Pairing-Daten oder Remote-Caches nicht als erste Maßnahme. Sichern Sie vorher die Konfiguration und notieren Sie, wie Sie Benutzerrechte und Schlüssel wiederherstellen.
Hinweis aus der Praxis: Ein erfolgreicher Login bedeutet noch nicht, dass Pair to Mac korrekt eingerichtet ist. Erst wenn die Remote-Komponenten installiert sind und ein Projekt tatsächlich kompiliert, ist die Verbindung für den Entwicklungsbetrieb brauchbar.
Was tun, wenn Pair to Mac keine Verbindung zum Remote Mac aufbaut?
Trennen Sie Erkennung, Anmeldung und Remote-Konfiguration. Wenn der Mac per IP erreichbar ist, aber die Anmeldung scheitert, prüfen Sie Benutzerfreigabe, SSH-Schlüssel und Firewall. Wenn die Anmeldung gelingt, aber die Remote-Installation abbricht, vergleichen Sie macOS-, Xcode- und .NET-MAUI-Voraussetzungen, statt den Host sofort neu aufzusetzen.
SECTION 04 Toolchain und Projektstatus
Nach dem Pairing müssen Sie drei Zustände getrennt protokollieren:
- Visual Studio hat den Mac gefunden und authentifiziert.
- Die für das Remote-Build erforderlichen Komponenten sind auf dem Mac eingerichtet.
- Das konkrete .NET-MAUI-Projekt kann für iOS kompilieren.
Nur der dritte Zustand beantwortet die eigentliche Arbeitsfrage. Ein grünes Pairing-Symbol darf daher nicht als Build-Nachweis gelten.
Prüfen Sie auf dem Mac zunächst, ob Xcode installiert ist und einmal vollständig gestartet wurde. Beim ersten Start können zusätzliche Komponenten, Lizenzbestätigungen oder Plattformbestandteile angefordert werden. Kontrollieren Sie danach den aktiven Entwicklerpfad mit den dafür vorgesehenen Xcode-Werkzeugen. Ein falscher aktiver Entwicklerordner kann dazu führen, dass Xcode sichtbar installiert ist, aber der Build die erwartete SDK-Umgebung nicht findet.
Auf Windows und Mac müssen Sie außerdem die .NET-MAUI-Arbeitslast, das Ziel-Framework und die verwendete .NET-Version abgleichen. Die offizielle Installationsanleitung für .NET MAUI beschreibt die erforderlichen Arbeitslasten; die Microsoft-Hinweise zu .NET 10 und .NET MAUI sind für die Einordnung neuerer Projektstände relevant. Versionsaussagen sollten Sie immer gegen diese Dokumente prüfen, weil Xcode, macOS, SDK und .NET-MAUI-Arbeitslast gemeinsam kompatibel sein müssen.
| Prüfbereich | Windows-Seite | Mac-Seite | Bestehen, wenn … |
|---|---|---|---|
| Projekt | Ziel-Framework, NuGet-Abhängigkeiten, Konfiguration | — | das Projekt ohne nicht aufgelöste Abhängigkeiten vorbereitet wird |
| Apple-Werkzeuge | Visual Studio steuert den Vorgang | Xcode und aktive Entwicklerwerkzeuge | der Mac den vorgesehenen iOS-Build ausführen kann |
| Signierung | Profil- und Build-Einstellungen auswählen | Zertifikat, privater Schlüssel und Profile verfügbar | der Release-Build mit dem richtigen Team signiert |
| Remote-Komponenten | Pair-to-Mac-Verbindung | erforderliche Remote-Dienste und Berechtigungen | Verbindung und Projekt-Build getrennt erfolgreich sind |
| Diagnose | Visual-Studio-Ausgabe sichern | Xcode-, .NET- und Systemprotokolle sichern | jeder Fehler einer klaren Phase zugeordnet werden kann |
Kann ein .NET-MAUI-iOS-Projekt ohne lokalen Mac weiterentwickelt werden?
Ja, Windows kann weiterhin Ihre Hauptumgebung für Quellcode, XAML, C# und Projektverwaltung sein. Für iOS-spezifische Kompilierung und Apple-Werkzeuge benötigen Sie jedoch einen zugänglichen Mac, der über Pair to Mac eingebunden ist. Ohne lokalen Mac ist ein Remote Mac deshalb eine mögliche Arbeitsumgebung, aber kein Weg, die macOS-Abhängigkeit vollständig zu entfernen.
SECTION 05 Vergleich der Entwicklungswege
Die Wahl sollte nicht allein davon abhängen, ob eine App einmal auf einem Gerät startet. Entscheidend sind Wiederholbarkeit, Signierung und die Möglichkeit, nach einem Neustart denselben Zustand wiederherzustellen.
| Option | Geeignet für | Stärken | Grenzen | Entscheidung |
|---|---|---|---|---|
| Visual Studio 2022 mit Hot Restart | kurzfristige Geräteprüfung eines bestehenden Projekts | wenig Umstellung für einen begrenzten Testablauf | keine vollständige Lösung für Archive, Signierung und Veröffentlichung | nur als Übergang |
| Visual Studio 2026 mit Pair to Mac | laufende .NET-MAUI-iOS-Entwicklung | Windows bleibt Editor, Mac übernimmt Apple-Build und Debugging | Netzwerk, Xcode und Mac-Zustand müssen gepflegt werden | Standardweg nach dem Upgrade |
| Remote Mac mit dauerhaftem Build-Ablauf | wiederkehrende Builds, Release-Kandidaten und Teamarbeit | kontrollierbarer Host, getrennte Entwicklungs- und Veröffentlichungsumgebung | Zugang, Schlüssel und Wiederanlauf müssen dokumentiert werden | für regelmäßige Veröffentlichungen |
| Lokaler Mac zusätzlich zu Windows | physische Geräte, lokale USB-Verbindungen und unabhängige Arbeit | kurze Latenz und direkte Hardware-Anbindung | Anschaffung, Wartung und Auslastungskosten | sinnvoll bei häufigen Gerätetests |
Eine Remote-Sitzung ersetzt außerdem nicht jede Form des Debuggings. Der iOS-Simulator läuft in der macOS-Umgebung; Windows steuert den Arbeitsablauf, stellt aber keinen Windows-eigenen iOS-Simulator bereit. Hot Reload kann Änderungen schneller in einen laufenden Prozess bringen, ist aber nicht dasselbe wie Hot Restart. Pair to Mac wiederum beschreibt den Transport und die Nutzung eines Mac-Buildhosts, nicht automatisch jede Funktion des früheren Hot-Restart-Erlebnisses.
Ein weiterer Unterschied betrifft reale Geräte. Ein Mac im Rechenzentrum kann normalerweise nicht einfach auf das USB-Gerät zugreifen, das neben Ihnen am Schreibtisch liegt. Für drahtlose Bereitstellung benötigen Sie ein gesondert vorbereitetes Apple-Gerät, passende Netzwerkbedingungen und eine funktionierende Vertrauens- und Signierungskette. Planen Sie daher Simulator-Tests und physische Gerätetests als zwei getrennte Pfade.
SECTION 06 Release- und Signierungsprüfung
Wie lange lässt sich Visual Studio 2022 mit Hot Restart noch verwenden?
Für eine kurzfristige Übergangsphase können Sie den in der Microsoft-Dokumentation beschriebenen Visual-Studio-2022-Ablauf weiter prüfen. Eine belastbare Zusage für eine unveränderte zukünftige Nutzungsdauer gibt es daraus nicht. Verwenden Sie ihn daher nur, wenn Ihr Ziel ein begrenzter Gerätetest ist und Sie parallel den Pair-to-Mac-Weg absichern.
Ein Debug-Build beweist weder, dass Ihr Release-Archiv erzeugt werden kann, noch dass die App hochgeladen oder von Apple verarbeitet wird. Trennen Sie im Protokoll mindestens diese Stationen:
- Debug-Kompilierung für den Simulator oder ein Testgerät
- Release-Kompilierung und Archive-Erzeugung
- Code-Signierung mit Zertifikat und privatem Schlüssel
- Einbindung des korrekten Provisioning Profile
- Upload zu App Store Connect
- anschließende Verarbeitung und weitere Prüfung im Apple-Konto
Apple legt die jeweils gültigen Xcode- und SDK-Anforderungen für die Einreichung in den aktuellen Vorgaben zum Einreichen von Apps fest. Vor jedem Release sollten Sie außerdem die Apple-Dokumentation zur Vorbereitung einer App für die Distribution gegenprüfen. Verlassen Sie sich nicht auf einen alten Buildserver, nur weil dort noch ein Zertifikat liegt.
Muss eine .NET-MAUI-iOS-App für die Veröffentlichung zwingend auf einem Mac gebaut werden?
Für den iOS-Build-, Xcode- und Signierungsanteil brauchen Sie eine macOS-basierte Apple-Toolchain. Das bedeutet nicht zwingend, dass Ihr gesamter Quellcode auf einem Mac liegen muss: Windows kann die Entwicklungsoberfläche bleiben, während ein lokaler oder entfernter Mac die Apple-spezifischen Schritte ausführt. Für die konkrete Einreichung müssen Sie zusätzlich die aktuellen Apple-Anforderungen für Xcode, SDK und Signierung erfüllen.
Fünfteilige Abnahme mit Meilensteinen
Führen Sie die Abnahme nicht anhand einer einmaligen Pairing-Anzeige durch. Verwenden Sie ein anonymisiertes Beispielprojekt und notieren Sie Zeitstempel, Toolchain-Versionen sowie die jeweils verwendeten Platzhalter für Team-ID, Bundle-ID und Zertifikate.
- Verbindung: Windows verbindet sich nach einer neuen Anmeldung mit
<MAC_IP>und<MAC_USER>. Die Anmeldung wird protokolliert, ohne private Schlüssel oder vollständige Zugangsdaten in Logs zu schreiben. - Wiederherstellung: Das Projekt stellt seine Abhängigkeiten auf einem frischen Arbeitsstand wieder her. Fehlt eine Abhängigkeit, wird die Ursache dokumentiert, statt lokale Binärdateien vom Entwicklerrechner zu kopieren.
- Simulator: Ein iOS-Simulator-Build läuft auf dem Mac durch. Dabei prüfen Sie nicht nur die Kompilierung, sondern auch Start, Beenden und erneuten Start der Anwendung.
- Archive: Eine Release-Konfiguration erzeugt ein Archive und verwendet das vorgesehene Team, Zertifikat und Provisioning Profile. Die privaten Schlüssel bleiben auf dem dafür bestimmten, geschützten Host.
- Wiederanlauf: Sie beenden die Pairing-Sitzung, starten den Mac neu oder simulieren einen Verbindungsabbruch und wiederholen Verbindung, Build und Protokollsicherung. Erst dann ist die Umgebung für einen wiederkehrenden Build-Ablauf belastbar.
Dokumentieren Sie zusätzlich, wo Logs liegen, wie lange sie aufbewahrt werden und wer auf Zertifikate zugreifen darf. Für ein kleines Team ist es ein Sicherheitsrisiko, denselben privaten Schlüssel unkontrolliert auf Windows, Mac und mehreren privaten Sicherungen zu verteilen. Prüfen Sie Datenschutz, Zugriffstrennung und Löschprozesse nach Ihren DSGVO-Anforderungen.
SECTION 07 Entscheidung für Ihr Projekt
Wählen Sie Visual Studio 2022 als kurzfristige Brücke, wenn Sie heute nur einen begrenzten Hot-Restart-Gerätetest benötigen, keine Veröffentlichung ansteht und Sie den Umstieg nicht während eines dringenden Releases durchführen können. Definieren Sie dafür ein konkretes Enddatum und bewahren Sie die Projekt- und Signierungsdaten getrennt auf.
Wählen Sie Visual Studio 2026 mit Pair to Mac, wenn Ihre Entwicklung fortgesetzt werden soll. Das ist die passende Richtung für Simulator-Builds, wiederholbare iOS-Kompilierung und die Nutzung von Xcode, ohne Windows als Hauptarbeitsplatz aufzugeben.
Wählen Sie eine getrennte Entwicklungs- und Veröffentlichungsumgebung, wenn mehrere Personen arbeiten, Release-Builds regelmäßig wiederholt werden oder ein einzelner Entwicklerrechner nicht als dauerhafte Infrastruktur ausfallen darf. Der Release-Mac sollte dann nicht nur erreichbar, sondern auch nach Neustarts, Schlüsselwechseln und fehlgeschlagenen Builds reproduzierbar nutzbar sein.
Wenn Sie dafür keinen eigenen Mac anschaffen möchten, kann VPSNIX als Mietoption für einen zugänglichen Mac geprüft werden. Entscheidend ist nicht die bloße Verfügbarkeit einer Remote-Sitzung, sondern ob Ihre konkrete Pair-to-Mac-Verbindung, der Simulator-Build und das Archive in der vorgesehenen Umgebung funktionieren. Prüfen Sie vor einer längeren Bindung die verfügbaren Mietmodelle und führen Sie die Abnahme aus dieser Anleitung durch.
Ein Windows-Rechner mit Hot Restart ist nach dem Upgrade vor allem deshalb unzureichend, weil Ihnen der unterstützte Ablauf für vollständige iOS-Builds fehlt, die Apple-Toolchain nicht lokal vorhanden ist und Release-Signierung sowie Wiederherstellung vom alten Zustand abhängen. Ein eigener Mac ist dagegen bei langfristiger Volllast, direktem USB-Zugriff und dauerhaft niedriger Latenz oft die bessere Wahl, verursacht aber Anschaffungs- und Wartungsaufwand. Wenn Sie nur für Übergangsphasen, einzelne Releases oder einen zusätzlichen Buildhost Rechenkapazität benötigen, ist ein gemieteter Mac von VPSNIX die flexiblere Variante: erst die Pairing- und Archive-Abnahme bestehen, danach den Mietzeitraum passend zum tatsächlichen Veröffentlichungsrhythmus wählen.