Für den Einstieg genügt in vielen Fällen der Windows-PC, den Sie bereits besitzen. Entscheidend ist nicht allein die Marke oder das Alter des Computers, sondern die Aufgabe:

• Code schreiben: funktioniert unter Windows.
• JavaScript- oder TypeScript-Projekt bearbeiten: funktioniert unter Windows.
• Grundlegende Vorschau: funktioniert mit Expo Go und einem unterstützten echten Gerät.
• Cloud-Build für iOS anstoßen: kann von Windows aus erfolgen.
• iOS-Simulator lokal starten: benötigt macOS.
• Xcode-Fehler untersuchen und native Dateien bearbeiten: benötigt praktisch eine macOS-Entwicklungsumgebung.

Expo beschreibt das Erstellen eines Projekts in seiner offiziellen Anleitung zum Projektstart. Für Sie bedeutet das: Der erste Lernschritt ist nicht der Kauf eines Computers, sondern die Prüfung, welche Abgabe Ihr Kurs wirklich verlangt.

Stellen Sie sich Ihr Projekt wie eine Schulaufgabe mit zwei Räumen vor. Im ersten Raum schreiben Sie den Text: Das ist die Programmierung. Im zweiten Raum testen Sie ihn auf einem bestimmten Gerät: Das ist die Ausführung. Windows kann Ihnen beim Schreiben helfen. Für den Apple-spezifischen Testraum brauchen Sie jedoch entweder ein echtes iPhone oder macOS.

Diese Trennung verhindert einen typischen Fehlkauf. Viele Einsteiger kaufen einen Mac, obwohl sie zunächst nur Navigation, Formulare, Listen und einfache API-Aufrufe lernen. Andere bleiben zu lange bei Windows, obwohl bereits Screenshots aus dem iOS-Simulator oder ein Xcode-Log gefordert werden.

Expo Go ist für Einsteiger ein fertiger Experimentierkasten. Sie starten Ihr Projekt auf Windows und öffnen es anschließend auf einem kompatiblen Mobilgerät. Dadurch können Sie typische Lernaufgaben prüfen:

• Bildschirme und Navigation;
• Buttons, Texteingaben und Listen;
• einfache lokale Zustände;
• viele JavaScript-basierte Bibliotheken;
• Layout und grundlegende Interaktionen.

Die Verbindung erfolgt häufig über einen QR-Code. Ihr Computer und das Smartphone müssen sich dabei im passenden Netzwerk erreichen können. Wenn beide Geräte im selben WLAN sind, ist die erste Vorschau meist leichter. Scheitert die Verbindung in einem öffentlichen Netzwerk, liegt das nicht automatisch an Ihrem Code. Hochschul- und Gäste-WLANs trennen Geräte häufig voneinander oder blockieren lokale Verbindungen.

Prüfen Sie bei einem Verbindungsfehler deshalb nacheinander:

1. Öffnen Sie die Projektadresse auf dem Windows-PC und kontrollieren Sie, ob der Entwicklungsserver läuft.
2. Wechseln Sie testweise in ein privates Netzwerk.
3. Deaktivieren Sie nicht dauerhaft Ihre Sicherheitssoftware, sondern prüfen Sie deren konkrete Netzwerkfreigaben.
4. Starten Sie die Vorschau erneut über den angezeigten QR-Code.
5. Vergleichen Sie das Ergebnis mit der offiziellen Expo-Anleitung zum Projektstart.

Expo Go ersetzt aber nicht jedes iOS-Testgerät. Es enthält nur einen festgelegten Satz nativer Funktionen. Verwenden Sie eine Bibliothek, die eine eigene native Erweiterung braucht, kann Ihr Projekt in Expo Go nicht wie erwartet starten. Die Expo-Hinweise zur Bibliothekskompatibilität erklären, warum eine Bibliothek zwar im JavaScript-Code eingebunden ist, aber trotzdem eine eigene App-Build-Umgebung benötigt.

Wichtig: Ein Projekt, das in Expo Go startet, ist nicht automatisch auf alle iOS-Funktionen vorbereitet. Beurteilen Sie daher nicht nur die erste Vorschau, sondern auch die Anforderungen der Bibliotheken und der Kursabgabe.

Reales Beispiel aus dem Unterricht

Angenommen, Sie erstellen eine Lern-App mit drei Seiten, einem Anmeldeformular und einer lokalen Merkliste. Windows plus Expo Go kann für diesen Abschnitt genügen. Sie sehen die Seiten auf einem echten Gerät und korrigieren Abstände oder Navigation.

Später verlangt die Aufgabe Push-Benachrichtigungen, eine spezielle Gerätefunktion oder einen Screenshot aus dem Simulator. Dann ändert sich die Entscheidung. Das Projekt ist nicht plötzlich „falsch“ programmiert. Die Testumgebung ist nur anspruchsvoller geworden.

Der iOS-Simulator ist kein zweites Expo Go. Er ist ein Apple-Entwicklungswerkzeug, mit dem Sie virtuelle iPhone- und iPad-Modelle auf einem Mac ausführen. Er hilft besonders bei Aufgaben, für die ein echtes Gerät nicht genügt:

• Screenshots bestimmter Gerätegrößen;
• Tests ohne eigenes iPhone;
• wiederholbare Prüfungen auf verschiedenen virtuellen Geräten;
• Kontrolle von Statusleisten und Bildschirmrändern;
• Untersuchung von iOS-spezifischen Meldungen.

Die Expo-Anleitung zum iOS-Simulator nennt macOS als Voraussetzung. Auch die Apple-Anleitung zum Ausführen auf simulierten und physischen Geräten trennt klar zwischen Simulator und realem Gerät. Einen iOS-Simulator können Sie daher nicht einfach unter Windows installieren, indem Sie Expo oder ein zusätzliches Paket nachinstallieren.

Ein echtes iPhone kann diese Lücke teilweise schließen. Sie sehen dadurch die App auf echter Hardware, prüfen Berührung, Kamera und Bildschirmverhalten und benötigen keinen lokalen Simulator. Für eine iOS-Kursabgabe kann das ausreichen, wenn ausdrücklich nur ein Video oder ein Test auf einem realen Gerät verlangt wird.

Es reicht nicht aus, wenn die Lehrkraft einen Simulator-Screenshot verlangt, ein bestimmtes virtuelles Modell vorgibt oder einen Fehler nur in Xcode nachvollziehen möchte. Prüfen Sie deshalb die Aufgabenstellung, bevor Sie Ihre Arbeitsumgebung auswählen.

Kein iPhone und kein Mac: Welche Möglichkeit bleibt?

Ohne iPhone und Mac können Sie den Code unter Windows weiterlernen und einen Cloud-Build auslösen. Für die tatsächliche Bedienung und visuelle Abnahme der iOS-App fehlt Ihnen dann jedoch ein verlässliches lokales Gerät.

Sie haben drei sachliche Optionen:

• Android-Gerät nutzen: geeignet, um allgemeine Layout- und Logikfehler früh zu finden, aber kein vollständiger Ersatz für iOS-Tests.
• Zeitweise einen Remote Mac verwenden: sinnvoll, wenn Simulator, Xcode oder eine kurze Kursabgabe anstehen.
• Kursanforderung verschieben: akzeptabel, wenn zunächst nur plattformübergreifende Grundlagen bewertet werden.

Ein Remote Mac ist dabei keine Abkürzung, die jede technische Grenze beseitigt. Sie steuern einen echten Mac über eine entfernte Verbindung. Ihre Internetqualität, die Eingabeverzögerung und die Bildschirmübertragung beeinflussen den Bedienkomfort. Für kurze Tests und Kursprojekte kann das genügen; für stundenlange grafische Arbeit sollten Sie die Verbindung vorher prüfen.

Der kritische Übergang beginnt meist mit einer nativen Abhängigkeit. Expo Go ist eine vorbereitete App. Ein Development Build ist dagegen eine speziell für Ihr Projekt erzeugte Entwicklungs-App. Der Unterschied ähnelt dem zwischen einem allgemeinen Schul-Labor und einem Labor, in dem Ihr persönliches Messgerät eingebaut wurde.

Benötigt Ihr Projekt eine native Bibliothek, die nicht in Expo Go enthalten ist, müssen Sie die App mit den passenden nativen Bestandteilen bauen. Die FAQ zu Expo Development Builds beschreibt diese Grenze. Eine Einführung in den Ablauf finden Sie in der Dokumentation zu Development Builds mit EAS.

Typische Warnzeichen sind:

• Expo Go meldet, dass eine Funktion nicht verfügbar ist.
• Eine Bibliothek verlangt eine native Konfiguration.
• Der JavaScript-Code ist korrekt, die App beendet sich aber beim Laden.
• Sie müssen Einstellungen in iOS-Projektdateien ändern.
• Die Fehlermeldung verweist auf Pods, Signierung oder native Module.

Ein Cloud-Build kann die Erstellung dieser App von Windows aus übernehmen. Das ist hilfreich, weil Sie nicht zwingend selbst alle nativen Werkzeuge lokal installieren müssen. Es beantwortet aber nur die Frage „Kann die App gebaut werden?“. Es beantwortet nicht automatisch die Frage „Warum stürzt sie auf diesem Gerät ab?“.

Wenn Sie den Fehler nur in einem Xcode-Log sehen, benötigen Sie eine macOS-Umgebung für die Untersuchung. Die Expo-Erklärung zu benutzerdefiniertem nativem Code ist dafür die passende Referenz. Verändern Sie keine Konten- oder Geräteverwaltung, um Vorgaben Ihrer Schule oder eines Kurses zu umgehen. Verwenden Sie nur Konten und Berechtigungen, die Ihnen rechtmäßig zur Verfügung stehen.

Die folgende Tabelle ist als Entscheidungshilfe gedacht. Sie bewertet nicht, welcher Computer allgemein „besser“ ist, sondern welche Route Ihre konkrete Expo-Aufgabe abdeckt.

Die Einteilung folgt den dokumentierten Grenzen von Simulator, Build und nativen Erweiterungen. Die Apple-Systemanforderungen für Xcode sollten Sie zusätzlich prüfen, wenn Sie einen eigenen Mac kaufen oder einen gemieteten Mac für eine konkrete Xcode-Version auswählen.

Entscheidungsregel für Einsteiger

Wählen Sie zunächst Windows, wenn Ihre Aufgabe aus Code, Navigation, einfachen Komponenten und einer allgemeinen Vorschau besteht.

Nutzen Sie ein echtes iPhone, wenn Sie die Bedienung auf realer Hardware sehen müssen und die Aufgabe keinen Simulator verlangt.

Planen Sie einen Remote Mac ein, sobald mindestens eine dieser Bedingungen erfüllt ist:

• Ihre Abgabe verlangt den iOS-Simulator.
• Sie besitzen kein iPhone und müssen iOS trotzdem vorführen.
• Eine native Bibliothek funktioniert in Expo Go nicht.
• Sie müssen Xcode-Logs lesen oder native Einstellungen prüfen.
• Ihr Kurs verlangt einen iOS-Build, den Sie nicht nur aus der Cloud abgeben, sondern lokal untersuchen müssen.

Ein eigener Mac wird erst dann wirtschaftlich plausibel, wenn Sie regelmäßig native iOS-Entwicklung betreiben, lange Sitzungen planen und die laufenden Besitzkosten gegenüber einer zeitweisen Nutzung rechtfertigen können. Für ein einzelnes Semesterprojekt ist das nicht automatisch der beste erste Schritt.

Gehen Sie in dieser Reihenfolge vor, damit Sie nicht zu früh an einer falschen Stelle suchen:

1. Aufgabe lesen: Markieren Sie, ob Code, reale iOS-Vorschau, Simulator-Screenshot, Development Build oder Xcode-Fehler verlangt wird.
2. Projekt unter Windows starten: Erstellen Sie ein Expo-Projekt nach der offiziellen Dokumentation und lassen Sie die Grundstruktur zunächst unverändert.
3. Basisfunktion testen: Prüfen Sie Navigation, Eingaben und Bildschirmdarstellung mit Expo Go oder einem verfügbaren echten Gerät.
4. Netzwerk isolieren: Testen Sie die Verbindung in einem privaten Netzwerk, bevor Sie den Code für einen Fehler verantwortlich machen.
5. Bibliotheken einzeln hinzufügen: Nach jeder neuen Abhängigkeit starten Sie die Vorschau erneut. So erkennen Sie, welches Paket die native Grenze auslöst.
6. Development Build prüfen: Wenn Expo Go die benötigte Funktion nicht enthält, lesen Sie die Dokumentation zu Development Builds und klären Sie, ob ein Cloud-Build genügt.
7. iOS-Build anstoßen: Verwenden Sie die Expo-Dokumentation zum Build-Ablauf, wenn Sie von Windows aus einen iOS-Build vorbereiten möchten.
8. Fehlerart bestimmen: Ein fehlgeschlagener Cloud-Build ist ein Build-Problem. Ein Fehler, der erst beim Start auf iOS erscheint, kann lokale oder entfernte macOS-Analyse erfordern.
9. Simulator oder Xcode öffnen: Wechseln Sie erst jetzt auf einen Mac, wenn die Aufgabenstellung oder die Fehlermeldung diesen Schritt tatsächlich verlangt.
10. Abgabe kontrollieren: Testen Sie genau die verlangte Variante und speichern Sie Quellcode, Build-Ergebnis und Screenshots getrennt. So können Sie bei einem späteren Fehler nachvollziehen, welcher Stand geprüft wurde.

Ein Cloud-Build ersetzt damit nicht automatisch den Mac, sondern verschiebt nur einen Teil der Arbeit in eine entfernte Build-Umgebung. Auch die Expo-Anleitung zum iOS-Submit behandelt das Einreichen als eigenen Schritt. Bauen, testen und einreichen sind drei verschiedene Aufgaben.

Erfahrungstipp: Wenn Ihr Projekt bereits native Bibliotheken enthält, klären Sie die Build-Route vor der letzten Kurswoche. Ein erfolgreicher JavaScript-Start in Expo Go ist kein Beleg dafür, dass der spätere iOS-Development-Build ebenfalls ohne Anpassung funktioniert.

Für die meisten Anfänger lautet die Reihenfolge: vorhandenen Windows-PC verwenden, Grundlagen lernen, mit Expo Go oder einem echten Gerät testen und erst bei einer konkreten iOS-Anforderung macOS einplanen.

Das spart nicht nur eine voreilige Anschaffung. Sie vermeiden auch, sich gleichzeitig in macOS, Xcode, Zertifikate, native Bibliotheken und Expo einarbeiten zu müssen. Für den Lernfortschritt ist es sinnvoller, zuerst die Programmieraufgabe zu verstehen und die zusätzliche Plattform nur dann einzusetzen, wenn sie für die Abgabe relevant wird.

Ein Remote Mac eignet sich besonders für einen begrenzten Kurszeitraum, einen Simulator-Screenshot oder die Analyse eines nativen Fehlers. Prüfen Sie vorher, wie Sie sich verbinden, ob Sie Dateien dauerhaft speichern können und ob die Maus- und Tastatursteuerung für Xcode ausreicht. Eine Anleitung zur Auswahl eines Mac für Entwicklungsaufgaben kann Ihnen bei der Gegenprüfung einer eigenen Anschaffung helfen.

Wenn Sie dagegen dauerhaft native iOS-Module entwickeln, regelmäßig Xcode benötigen oder spezielle physische Geräte anschließen müssen, ist ein eigener Mac möglicherweise praktischer. Ein gemieteter Zugang ist dann nicht automatisch die langfristig günstigste oder bequemste Lösung.

Windows bleibt als aktuelle Lösung dennoch mit drei echten Nachteilen verbunden: Der lokale iOS-Simulator fällt weg, Xcode-Logs lassen sich nicht direkt untersuchen und native Änderungen müssen über eine entfernte oder cloudbasierte Umgebung geprüft werden. Für genau diese Engpässe kann ein zeitweise gemieteter Mac von KVMNODE die passendere Ergänzung sein als ein sofortiger Gerätekauf. Sie behalten Ihren Windows-PC für den täglichen Lerncode und verwenden den Mac nur für den Abschnitt, den Ihre Expo-Aufgabe tatsächlich blockiert. Informieren Sie sich dafür über die verfügbare Remote-Mac-Umgebung von KVMNODE, prüfen Sie die Zugriffs- und Speicherbedingungen und wählen Sie den Nutzungszeitraum passend zu Ihrer Kursaufgabe.