iPhone Duo-Anpassung: Was jetzt tun? Remote-Testliste 2026

Die wichtigste Trennung verhindert einen typischen Fehler: Ein bestehendes Projekt kann bereits starten und trotzdem die neue Innenanzeige, die veränderte Fensterform oder die Navigation nicht sinnvoll nutzen. Ein Start ist daher kein Layout-Nachweis.

Apple verweist für die Gestaltung auf eigene Richtlinien für iPhone Duo. Diese sind eine Grundlage für Layout-Entscheidungen, ersetzen aber nicht die spätere Laufzeitprüfung in Xcode und auf einem Gerät: Apple Design Guidance für iPhone Duo.

SwiftUI: von festen Annahmen zu messbaren Containergrößen

Bei SwiftUI sollte die erste Prüfung nicht mit einem neuen Gerätemodell beginnen. Durchsuchen Sie das Projekt nach folgenden Annahmen:

• feste Breiten und Höhen in frame;
• Abfragen eines konkreten Gerätemodells;
• direkte Ableitung aus Bildschirmbreite oder Bildschirmhöhe;
• Logik, die nur zwischen Hoch- und Querformat unterscheidet;
• symmetrische padding-Werte, obwohl die sichere Fläche nicht symmetrisch ist;
• manuelle Offsets für Navigations- oder Werkzeugleisten.

Ersetzen Sie diese Annahmen, soweit möglich, durch size class, Containergröße und die jeweilige Layout-Umgebung. Entscheidend ist nicht, ob ein einzelnes Vorschaufenster gut aussieht. Entscheidend ist, ob die Ansicht auf mehreren Breiten dieselbe Aufgabe erledigen kann, ohne dass Text, Eingabefelder oder primäre Aktionen aus dem sichtbaren Bereich geraten.

Prüfen Sie besonders NavigationSplitView, TabView, Sheet und Popover. Eine Oberfläche, die auf einem einzelnen Vollbildzustand funktioniert, kann bei einer kleineren Außenanzeige oder einer geteilten Darstellung eine andere Hierarchie benötigen. Legen Sie daher pro kritischer Seite mindestens diese Zustände als wiederholbare Fälle an:

• Außenanzeige, Hochformat;
• Außenanzeige, Querformat, falls der Anwendungsfall dies zulässt;
• Innenanzeige, Hochformat;
• Innenanzeige, Querformat;
• verkleinertes oder geteiltes Fenster;
• Rückkehr aus einem modalen Ablauf mit erhaltenem Zustand.

Die Fälle sind zunächst ein Testplan, noch kein Beweis für das Verhalten des iPhone-Duo-Simulators. Markieren Sie sie deshalb als „vorbereitet“ und nicht als „bestanden“.

UIKit und eigene Navigation: harte Geometrie zuerst finden

Bei UIKit liegen die Risiken häufig in älteren Annahmen. Suchen Sie nach UIScreen.main.bounds, festen frame-Werten, manuell positionierten Werkzeugleisten und Ansichten, die den sicheren Bereich ignorieren. Solche Stellen funktionieren oft so lange, wie Breite, Orientierung und Anzeigefläche vorhersehbar bleiben.

Prüfen Sie anschließend:

• reagiert die Ansicht auf Änderungen der traitCollection;
• verwendet Auto Layout ausreichende Prioritäten und keine widersprüchlichen Zwangsbreiten;
• kann UISplitViewController seine Spalten bei wechselnder Größe neu anordnen;
• bleiben eigene Übergänge sichtbar und interaktiv, wenn sich die Geometrie während des Ablaufs ändert;
• wird der Fokus nach Rotation oder Fensterwechsel korrekt wiederhergestellt;
• bleiben Tastatur, Eingabefeld und primäre Aktion gemeinsam erreichbar.

Jede Korrektur benötigt danach eine normale iPhone-Regression. Bauen Sie keine dauerhafte Sonderverzweigung ein, nur weil ein einzelnes Zielgerät heute anders wirkt. Ein Gerät-spezifischer Pfad ist erst dann vertretbar, wenn eine veröffentlichte API oder eine überprüfbare Laufzeiteigenschaft ihn begründet. Für nicht dokumentierte Eigenschaften des neuen Formfaktors sollten Sie keine eigenen Annahmen aus Produktbildern ableiten.

Mehrere Szenen, Medien und Kamera: getrennte Testgruppen

Apps mit mehreren Szenen müssen mehr als die erste Vollbildseite prüfen. Für jede Szene dokumentieren Sie:

1. Öffnen im Ausgangszustand.
2. Wechsel der Fenstergröße.
3. Wechsel zwischen primärer und sekundärer Ansicht.
4. Unterbrechung durch eine andere Szene.
5. Wiederherstellung nach Rückkehr.
6. Erhalt von Formular-, Scroll- und Navigationszustand.

Kamera-, Video-, Spiele- und Querformat-Apps erhalten eine eigene Gruppe. Dort gehören sichtbare Fläche, Drehung, Position von Eingaben, Overlay-Platzierung und verfügbare Hardware zu den Akzeptanzkriterien. Ein Video kann beispielsweise korrekt dekodieren und trotzdem durch ein falsch berechnetes Overlay unbedienbar sein.

Wenn ein Test von Gelenkzustand, mehreren Anzeigeflächen oder neuer Kamerafunktion abhängt, verwenden Sie ausschließlich veröffentlichte Apple-Dokumentation. Bis Apple die entsprechende Schnittstelle und ihr Verhalten dokumentiert, bleibt der Fall offen. Eine Medienmeldung oder ein Werbebild darf kein Testkriterium ersetzen.

Verwenden Sie diese Bedingungen, bevor Sie eine bestehende Build-Maschine aktualisieren:

• Wenn die aktuelle Maschine ihre stabile Build- und Signierkette behalten muss, dann lassen Sie sie unverändert und richten Sie die iPhone-Duo-Erprobung getrennt ein.
• Wenn Xcode 27.1 beta nach der Freigabe die vorhandene macOS-Version und Architektur unterstützt, dann testen Sie zuerst auf einer isolierten Installation. Die verbindlichen Anforderungen stehen in den Xcode-Systemanforderungen von Apple.
• Wenn die Anforderungen nicht erfüllt sind oder die Beta die Produktionsumgebung gefährdet, dann wählen Sie einen separaten Remote Mac statt eines ungeplanten Upgrades.
• Wenn die grafische Sitzung die Simulatoroberfläche nicht zuverlässig hält, dann behandeln Sie den Remote Mac nur als Build- oder Log-Host und verschieben Sie die visuelle Prüfung auf eine geeignete Sitzung.
• Wenn nach einer Unterbrechung Logs, Screenshots und Teststatus nicht wieder auffindbar sind, dann ist die Umgebung für eine belastbare Abnahme noch nicht geeignet.
• Wenn nur ein einzelner Entwickler gelegentlich prüft, dann reicht eine zeitlich begrenzte Umgebung. Wenn mehrere Personen täglich testen oder ein dauerhafter Regression-Lauf geplant ist, dann braucht die Umgebung feste Projekt-, Artefakt- und Zugriffsregeln.

Für die Auswahl eines physischen Macs können Sie die MESHLAUNCH-Übersicht für Mac-mini-Konfigurationen als Vergleichspunkt heranziehen. Das ist keine Aussage über die noch offenen Xcode-27.1-Anforderungen. Prüfen Sie diese erst gegen Apples veröffentlichte Systemmatrix.

Ein Remote Mac ist für diese Aufgabe nur dann sinnvoll, wenn die Testresultate reproduzierbar bleiben. Arbeiten Sie die Einrichtung in dieser Reihenfolge ab.

1. Produktions- und Beta-Umgebung trennen

Legen Sie fest, welche Maschine weiterhin stabile Archive erzeugt. Installieren Sie eine Beta nicht automatisch auf diesem Host. Trennen Sie Projektpfad, Schlüsselbund, Zertifikate und Artefaktablage. Veröffentlichen Sie keine Testarchive aus einer Umgebung, deren Xcode-Version noch nicht für den regulären Release-Prozess freigegeben ist.

Dokumentieren Sie Bundle-ID, Team-Zuordnung, Scheme und verwendete Konfigurationen in einer anonymisierten Form. In Tickets gehören keine privaten Zertifikatsdaten, Kontotokens oder vollständigen Provisioning-Profile.

2. macOS- und Architekturvoraussetzungen prüfen

Nach Freigabe von Xcode 27.1 vergleichen Sie die offizielle Systemanforderung mit dem Host. Prüfen Sie macOS-Version, Prozessorarchitektur, freien Speicher, verfügbare Simulator-Laufzeiten und Berechtigungen. Schreiben Sie die Prüfung mit Datum und Xcode-Build in das Runbook.

Installieren Sie die Beta nicht, solange nur eine unbestätigte Medienangabe vorliegt. Apple kann Anforderungen und Komponenten zwischen einer Beta und einer späteren Version verändern.

3. Grafische Sitzung und Device Hub validieren

Device Hub ist nicht bloß eine Liste von Geräten. Prüfen Sie, ob die grafische Sitzung über den gewählten Remote-Zugriff stabil geöffnet bleibt, ob Simulatorfenster sichtbar sind und ob Eingaben korrekt ankommen. Apple beschreibt Device Hub in der offiziellen Dokumentation und stellt eine Einführung aus der WWDC26 bereit: Device Hub bei Apple.

Testen Sie mindestens:

• Auswahl der vorgesehenen Simulator-Laufzeit;
• Start und Beenden einer App;
• Wechsel von Orientierung und Anzeigebereich;
• Speicherung von Logs und Screenshots;
• Verhalten nach Trennung und Wiederaufnahme der Sitzung.

Die Dokumentation bestätigt die Funktion von Device Hub. Sie bestätigt nicht automatisch jede Kombination aus Remote-Grafiksitzung, Beta-Laufzeit und Ihrem Netzwerk. Diese Grenze muss Ihr Team selbst messen und dokumentieren.

4. Projekt- und Artefaktpfade festlegen

Synchronisieren Sie den Quellcode reproduzierbar. Verwenden Sie keine persönlichen Desktop-Pfade als Testvoraussetzung. Legen Sie getrennte Verzeichnisse für Build-Artefakte, Simulator-Screenshots, Laufzeitprotokolle und Abnahmeberichte an.

Entfernen Sie aus Dateinamen und Screenshots interne Kundennamen, echte Bundle-IDs, E-Mail-Adressen, Kontonummern und Zugangsdaten. Bei Teamzugriffen gelten DSGVO-Grundsätze: minimale Berechtigung, nachvollziehbare Konten und keine gemeinsam genutzten privaten Schlüssel.

5. Unterbrechung und Übergabe simulieren

Trennen Sie die Remote-Sitzung absichtlich während eines Simulatorlaufs. Prüfen Sie danach, ob der Teststatus, das letzte Log und das relevante Bildschirmbild wieder auffindbar sind. Ein Test, der nur im Kopf des gerade verbundenen Entwicklers existiert, ist kein übergabefähiger Test.

Übergeben Sie jeden Fall mit Build-Kennung, Simulatorzustand, reproduzierbaren Schritten, erwarteten Ergebnissen und einem anonymisierten Beleg. So kann ein zweiter Entwickler den Fehler prüfen, ohne Zugriff auf persönliche Konten oder ungeschützte Projektdateien zu benötigen.

Die Veröffentlichung benötigt fünf Belege, die nicht miteinander verwechselt werden dürfen:

1. Build: Das Projekt lässt sich mit der vorgesehenen Konfiguration kompilieren.
2. Simulatorzustand: Die relevanten Innen-, Außen-, Orientierungs- und Größenvarianten wurden nach Verfügbarkeit der Werkzeuge geprüft.
3. Nutzerablauf: Anmeldung, Navigation, Eingabe, Medienfunktion und Wiederaufnahme funktionieren.
4. Material: Die passenden Screenshots und Texte liegen getrennt nach Zielzustand vor.
5. Gerät: Ein realer Build wurde auf verfügbarer echter Hardware geprüft.

Apple hat die Screenshot-Spezifikationen für App Store Connect veröffentlicht. Prüfen Sie die aktuelle Screenshot-Referenz und den Ablauf zum Hochladen von Screenshots, bevor Sie produktive Materialien ersetzen. Die Unterstützung für iPhone-Duo-Materialien soll laut Aufgabenstand später im Jahr 2026 bereitgestellt werden; bis der Upload-Einstieg tatsächlich sichtbar ist, bleiben Vorlagen und Zuordnungen Vorbereitung.

Für Teams mit automatisierten Abläufen kann die App-Screenshots-API-Dokumentation die technische Planung unterstützen. Sie beweist jedoch nicht, dass ein noch nicht freigeschalteter iPhone-Duo-Zieltyp bereits angenommen wird.

Kann eine bestehende App ohne erneuten Build auf iPhone Duo laufen?

Eine bestehende App kann möglicherweise starten, wenn Betriebssystem und Binärformat kompatibel sind. Das reicht nicht als Anpassungsnachweis. Prüfen Sie damit höchstens den Startpfad. Für vollständige Layout-, Navigations- und Screenshot-Abnahme benötigen Sie den passenden Build, das veröffentlichte Simulatorwerkzeug und später eine Prüfung auf echter Hardware.

Wann ist der iPhone-Duo-Simulator in Xcode 27.1 nutzbar?

Apple hat die Xcode-27.1-Beta, den iPhone-Duo-Simulator und ergänzende Dokumentation für später im September 2026 angekündigt. Bis zur tatsächlichen Veröffentlichung sollten Sie keine Verfügbarkeit annehmen. Nach dem Release gehören Systemanforderungen, Laufzeitinstallation, Device-Hub-Geräteliste und ein realer Projektlauf in das Abnahmeprotokoll.

Kann Device Hub auf einem Remote Mac verwendet werden?

Das ist eine prüfbare Umgebungsfrage, keine pauschale Zusage. Entscheidend sind unterstützte Xcode-Version, macOS-Basis, Simulator-Laufzeit, grafische Sitzung und Wiederaufnahme nach einer Trennung. Prüfen Sie diese Punkte auf dem konkreten Host. Wenn die Darstellung oder Artefaktablage instabil ist, verwenden Sie die Umgebung nicht als alleinige visuelle Abnahme.

Brauchen Innen- und Außenanzeige eigene App-Store-Screenshots?

Planen Sie getrennte Materialsets, sobald Apples Spezifikation und App Store Connect den Zielzustand unterscheiden. Ersetzen Sie die derzeit veröffentlichten Bilder nicht vorzeitig. Erstellen Sie zunächst Vorlagen, Benennung und Zuordnung. Die endgültige Entscheidung treffen Sie erst, wenn der Upload-Einstieg und die zugehörige Apple-Dokumentation für den konkreten App-Eintrag verfügbar sind.

Sofort erledigen:

• [ ] SwiftUI-Ansichten auf feste Breiten, Gerätemodelle und symmetrische Safe Areas prüfen.
• [ ] UIKit-Code nach UIScreen.main.bounds, festen Frames und ignorierten Safe Areas durchsuchen.
• [ ] Navigation, Sheets, Popovers, Szenen und Zustandswiederherstellung als Testfälle erfassen.
• [ ] Kamera-, Medien- und Querformatpfade separat markieren.
• [ ] Produktions-Build und künftige Beta-Umgebung organisatorisch trennen.
• [ ] Screenshot-Vorlagen erstellen, aber keine produktiven Assets voreilig austauschen.

Nach Freigabe von Xcode 27.1 prüfen:

• [ ] Unterstützte macOS-Version und Architektur bestätigen.
• [ ] Simulator-Laufzeit installieren und Device Hub öffnen.
• [ ] Innen- und Außenanzeige sowie Größen- und Orientierungszustände ausführen.
• [ ] Logs, Screenshots und Build-Artefakte reproduzierbar ablegen.
• [ ] Remote-Sitzung trennen und Wiederaufnahme dokumentieren.

Vor der Veröffentlichung abschließen:

• [ ] Vollständige Testmatrix mit realem Build ausführen.
• [ ] Kritische Nutzerabläufe auf echter Hardware wiederholen.
• [ ] App-Store-Screenshot-Anforderungen im aktuellen Eintrag bestätigen.
• [ ] Signierung, Upload und Rückmeldung aus App Store Connect prüfen.
• [ ] Erst danach die iPhone-Duo-Anpassung als abgeschlossen markieren.

Ein vorhandener Mac bleibt für stabile Releases oft die bessere Basis, wenn er nicht sicher parallel mit Xcode 27.1 betrieben werden kann. Ein zweiter physischer Rechner bindet dagegen Kapital, muss gepflegt werden und ist für eine zeitlich begrenzte Beta-Prüfung möglicherweise unnötig. Ein Remote Mac von MESHLAUNCH kann in diesem Fall die isolierte Testumgebung bereitstellen, während die produktive Build-Maschine unverändert bleibt. Das ist besonders dann sinnvoll, wenn Sie nur für die Werkzeugfreigabe, Simulatorläufe und Screenshot-Validierung zusätzliche macOS-Kapazität benötigen. Für dauerhaft hohe Build-Last, spezielle physische Schnittstellen oder eine tägliche Geräteflotte sollten Sie den Eigenbetrieb weiterhin separat kalkulieren.

Weitere Informationen zur verfügbaren Remote-Mac-Umgebung finden Sie bei MESHLAUNCH. Entscheidend ist nicht, möglichst früh „fertig“ zu melden, sondern jede offene Ebene — Layout, Simulator, Remote-Sitzung, Material und echte Hardware — mit einem eigenen Nachweis zu schließen.