iPhone-Duo-Anpassung testen: 2026 Enterprise-CI-Abnahme

Apple hat Ressourcen zur Vorbereitung auf iPhone Duo, Designhinweise und technische Videos veröffentlicht. Xcode 27 ist offiziell verfügbar. Der Entwicklungsstand für Xcode 27.1 beta, zugehörige Simulatoren und weitere vollständige Unterlagen ist jedoch laut offizieller iPhone-Duo-Seite noch an die angekündigte spätere Bereitstellung gebunden. Die Aussage „Apple hat das Gerät vorgestellt“ reicht daher nicht als Abnahmegrundlage aus. Maßgeblich ist, welche Funktion im eigenen Build- und Veröffentlichungsprozess tatsächlich reproduzierbar verfügbar ist.

Wir trennen deshalb sechs Zustände:

• Anwendungskompatibilität: Läuft der bestehende Code unter den neuen Layout- und Zustandsbedingungen?
• Oberflächenanpassung: Sind Navigation, Dialoge und eigene Layouts für die unterschiedlichen Haltungen sinnvoll?
• Simulatorprüfung: Lassen sich deterministische Regressionen ohne physische Hardware ausführen?
• Prüfung auf echter Hardware: Verhalten sich Kamera, Leistung, Sensorik und physische Interaktion korrekt?
• Materialerstellung: Können reproduzierbare Screenshots und weitere App-Store-Materialien erzeugt werden?
• Produktionsveröffentlichung: Sind Signierung, Archivierung und Upload für den produktiven Prozess freigegeben?

Die offizielle iPhone-Duo-Übersicht von Apple beschreibt die verfügbaren Vorbereitungsressourcen. Die dort genannten Entwicklungs- und Materialzustände dürfen nicht automatisch als Freigabe für den eigenen App-Store-Prozess interpretiert werden.

Hinweis aus dem Betrieb: Ein grüner Simulatorlauf beweist weder korrektes Verhalten der Kamera noch die Eignung eines Screenshots für die spätere Veröffentlichung. Wir akzeptieren deshalb keinen Sammelstatus „iPhone-Duo-kompatibel“, sondern verlangen getrennte Nachweise je Zustand.

Welche Gerätehaltungen müssen in der iPhone-Duo-Anpassung geprüft werden?

Die Entwicklungsabnahme beginnt nicht mit einer vollständigen Testmatrix. Sie beginnt mit einer Asset-Liste pro Anwendung. Für jede kritische Oberfläche erfassen wir mindestens Außenansicht, Innenansicht, aufgeklappten Zustand, gefalteten Zustand und Rotation. Diese Begriffe beschreiben Prüfzustände, nicht automatisch konkrete Hardwaremerkmale oder garantierte Produktionsabmessungen.

Besonders fehleranfällig sind:

• Navigation mit verschachtelten Stapeln und modalen Dialogen.
• Formulare, deren Tastatur den relevanten Inhalt überdeckt.
• Kamera- und Scan-Flows mit wechselnder Orientierung.
• Scene-Management bei Größen- oder Aktivitätswechsel.
• Eigene Layout-Container, die nur auf klassische Hoch- und Querformate reagieren.
• Wiederaufnahme nach dem Wechsel zwischen Haltungen.
• UI-Automatisierung, die sich auf Koordinaten statt auf stabile Accessibility-Identifikatoren stützt.

Für jede Hochrisiko-Oberfläche verlangen wir einen Codepfad, eine reproduzierbare Ausgangslage, einen erwarteten Zustand und einen Verantwortlichen. Apple erläutert in den technischen iPhone-Duo-Videos zu Design und Entwicklung die relevanten Anpassungsfragen. Wir verwenden diese Hinweise als Prüfbasis, nicht als Ersatz für Anwendungstests.

Verantwortung und Übergabe

• Entwicklung liefert betroffene Screens, Codeposition, bekannte Annahmen und den geplanten Fix.
• QA definiert Ausgangszustand, Haltung, Rotation, erwartetes Ergebnis und Fehlerklasse.
• Teams für Entwicklungsproduktivität entscheiden, welche Fälle deterministisch automatisierbar sind.
• CI-Plattform übernimmt nur klar beschriebene Tests mit stabilen Startbedingungen.
• Sicherheit und Release erhalten keine Produktionsschlüssel, solange die Prüfung experimentell bleibt.

Ein Fall wird zurückgewiesen, wenn die Haltung nicht reproduzierbar angegeben ist, der Fehler nur als Video ohne Log vorliegt oder die Testautomatisierung von einer instabilen Koordinate abhängt. So verhindern wir, dass eine bloße Designbeobachtung als Build-Blocker oder umgekehrt ein echter Zustandsverlust als kosmetischer Fehler klassifiziert wird.

Kann der iPhone-Duo-Simulator die Prüfung auf echter Hardware ersetzen?

Nein. Der Simulator kann deterministische Layout-, Navigations-, Zustands- und UI-Automatisierungstests abdecken. Er ersetzt aber keinen Nachweis für Kameraabläufe, physische Übergänge, sensorabhängiges Verhalten, reale Speicher- oder Leistungsbedingungen und Fehler, die erst beim Wechsel zwischen Hardwarezuständen auftreten.

Wir teilen die QA-Matrix deshalb in drei Ebenen:

Ebene A: Basiskompatibilität

• Anwendung startet und beendet sich ohne unerwarteten Absturz.
• Navigation bleibt nach einem Haltungswechsel erreichbar.
• Dialoge, Tabellen, Eingabefelder und Fehlermeldungen bleiben sichtbar.
• Accessibility-Elemente behalten stabile Kennungen.
• Wiederaufnahme aus dem Hintergrund erhält den fachlichen Zustand.

Ebene B: automatisierte Haltungsregression

• Ein definierter Startzustand wird hergestellt.
• Die Haltung wird nach einem festen Muster geändert.
• Ein kritischer Nutzerpfad wird ausgeführt.
• Screenshot, Log und Testergebnis werden als Artefakt gespeichert.
• Die gleiche Prüfung wird mit Produktions- und Testkonfiguration ausgeführt, soweit die Signierungsgrenzen das erlauben.

Ebene C: echte Hardware

• Kamera, Scan, Video und sensornahe Funktionen.
• Physische Interaktion und Übergänge zwischen Gerätehaltungen.
• Verhalten unter realer Netzwerk- und Energieversorgung.
• Veröffentlichungskritische Screenshots und visuelle Endkontrolle.
• Wiederholung eines Simulatorfehlers auf dem realen Gerät, bevor ein Release blockiert wird.

Nicht jeder Commit muss die vollständige Matrix ausführen. Wir ordnen Tests nach Risiko und Änderungsfläche. Ein Layout-Commit kann zunächst die deterministische Simulatorregression auslösen. Eine Änderung am Kamera- oder Scene-Management benötigt zusätzlich einen Hardware-Nachweis. Der Testdatensatz enthält Haltung, Anwendungsstatus, erwartetes Ergebnis, tatsächliches Ergebnis, Log, Screenshot und Blockierungsstufe.

Die offiziellen Apple-Technikvideos zu den iPhone-Duo-Entwicklungsänderungen und zur Vorbereitung der Test- und Designabläufe helfen bei der Zuordnung. Sie liefern jedoch keine unternehmensspezifischen Aussagen zu Build-Zeit, Warteschlange oder erforderlicher Mac-Anzahl.

Wie wird Xcode 27.1 in einer Enterprise-CI separat bereitgestellt?

Wir installieren Xcode 27.1 beta nicht auf dem stabilen Release-Knoten. Stattdessen wird ein eigener Validierungsknoten mit eigenem Runner-Label, eigener Warteschlange und eigener Artefaktablage eingerichtet. Die Xcode-Veröffentlichungsnotiz von Apple und die offizielle Übersicht zu den Xcode-Neuerungen sind vor jeder Änderung erneut zu prüfen.

Die Einrichtung erfolgt in dieser Reihenfolge:

1. Scope festlegen: Repositories, Branches, Testziele und verantwortliche Teams dokumentieren. Keine globale Umschaltung des Standard-Runners.
2. Knoten isolieren: Eigenes Runner-Label, eigener Arbeitsbereich und getrennte Cache-Regeln verwenden. Die Produktionswarteschlange darf den neuen Knoten nicht ungeplant nutzen.
3. Toolchain prüfen: Xcode-Version, SDK, Simulator-Runtime, Command-Line-Tools und benötigte Abhängigkeiten protokollieren. Der Build muss die tatsächlich ausgewählte Developer-Directory verwenden.
4. Repräsentatives Projekt starten: Zuerst eine kleine, aber fachlich relevante Anwendung bauen. Danach ein Projekt mit UI-Automatisierung und ein Projekt mit kritischen Abhängigkeiten ergänzen.
5. Minimale Regression ausführen: Start, Navigation, Haltungswechsel, Statuswiederherstellung und Artefaktspeicherung testen.
6. Fehler klassifizieren: Toolchain-Fehler, Anwendungscode, Testinstabilität, Signierung und Infrastruktur getrennt erfassen.
7. Beobachtungsphase durchführen: Installationswiederherstellung, Build-Dauer, Test-Dauer, Fehlerrate, Warteschlangenwartezeit und Speicherwachstum aus den CI-Logs sammeln.
8. Freigabeentscheidung treffen: Erst nach dieser Evidenz wird der Testumfang erweitert oder eine Kapazitätsänderung beantragt.

Die Daten müssen aus den eigenen CI-Logs stammen. Wir leiten keine Knotenanzahl aus der Zahl der Geräte oder Entwickler ab. Zwei Anwendungen können durch unterschiedliche Testtiefe und Artefaktgrößen völlig verschiedene Last erzeugen; ohne Messung wäre eine Kapazitätsaussage lediglich eine Annahme.

Der Validierungsknoten darf standardmäßig keine Produktionszertifikate, privaten Schlüssel oder App-Store-Veröffentlichungsrechte erhalten. Für Tests nutzen wir getrennte Bundle-Identifikatoren, Testkonten und kurzlebige oder klar begrenzte Zugangsdaten. Die Release-Archivierung bleibt auf einem vertrauenswürdigen Knoten, bis Sicherheit und Release-Verantwortliche die neue Toolchain ausdrücklich freigeben.

Die technische Abnahme umfasst:

• Prüfung der Zugriffsgruppen und Runner-Tags.
• Ausschluss produktiver Schlüssel aus Umgebungsvariablen, Caches und Logdateien.
• Trennung interner Abhängigkeiten und Testdaten vom Veröffentlichungsprozess.
• Festlegung der Aufbewahrungsdauer für Logs, Screenshots und Build-Artefakte.
• Dokumentierte Löschung nach einem Knoten-Rebuild.
• Wiederherstellungsprüfung ohne Rückfall auf alte Credentials.
• Nachweis, dass ein experimenteller Job keine Produktionswarteschlange blockieren kann.

App Store Connect führt bereits Dokumentation zu den Screenshot-Spezifikationen. Daraus folgt aber nicht, dass jede iPhone-Duo-Materialübermittlung sofort produktiv möglich ist. Laut der offiziellen Apple-Ressource soll die Unterstützung für die Übermittlung entsprechender Materialien später im Jahr verfügbar werden. Bis dahin bereiten wir eine reproduzierbare Generierung, Prüfung und Ablage vor, behaupten aber keine aktuelle Upload-Freigabe.

Die folgende Liste wird pro Anwendung und pro Validierungsknoten ausgefüllt. Ein leeres Feld ist kein „noch offen“, sondern eine dokumentierte Abnahmelücke.

Entwicklungsprüfung

• [ ] Betroffene Anwendungen und kritische Geschäftsabläufe sind benannt.
• [ ] Außen-, Innen-, Falt-, Entfalt- und Rotationszustände sind als Testzustände beschrieben.
• [ ] Hochrisiko-Seiten enthalten Codeposition, Reproduktionsbedingung und verantwortliches Team.
• [ ] Layout-, Scene-Management-, Kamera- und Dialogrisiken sind getrennt bewertet.
• [ ] Jeder Befund besitzt eine klare Blockierungsstufe.
• [ ] Ein Fix ist mit einem reproduzierbaren Regressionstest verknüpft.

QA- und Automatisierungsprüfung

• [ ] Simulatorfälle und echte Hardwarefälle sind getrennt markiert.
• [ ] Jeder Test dokumentiert Startzustand, Haltung, erwartetes Ergebnis und Artefakte.
• [ ] UI-Automatisierung verwendet stabile Identifikatoren statt fragiler Koordinaten.
• [ ] Kritische Kamera-, Sensor- und Übergangsfälle haben einen Hardware-Nachweis.
• [ ] Ein fehlgeschlagener Test kann ohne manuelle Geheimkenntnis wiederholt werden.
• [ ] Die vollständige Matrix ist nicht pauschal jedem Commit zugeordnet.

CI- und Toolchain-Prüfung

• [ ] Xcode 27.1 beta läuft auf einem eigenen Validierungsknoten.
• [ ] Runner-Label und Warteschlange sind von der Produktion getrennt.
• [ ] SDK, Simulator-Runtime und Developer-Directory sind protokolliert.
• [ ] Ein repräsentatives Projekt wurde vor der breiten Aktivierung gebaut.
• [ ] Build-Zeit, Test-Zeit, Fehler, Warteschlange und Speicherwachstum stammen aus Logs.
• [ ] Ein Knoten-Rebuild wurde mit bereinigten Zugangsdaten geprüft.

Sicherheits- und Release-Prüfung

• [ ] Produktionszertifikate und private Schlüssel sind ausgeschlossen.
• [ ] Testkonten, interne Abhängigkeiten und Artefaktablage sind dokumentiert.
• [ ] Log- und Screenshot-Aufbewahrung ist freigegeben.
• [ ] Der Validierungsknoten kann keinen produktiven Upload auslösen.
• [ ] Die Freigabegrenze für App-Store-Materialien ist schriftlich festgehalten.
• [ ] Release-Archivierung und experimentelle Regression besitzen getrennte Verantwortliche.

IT- und Einkaufsprüfung

• [ ] Neue Testfälle, erwartete Wiederholungen und Spitzenzeiten sind erfasst.
• [ ] Warteschlangenbeobachtung basiert auf CI-Daten, nicht auf Entwicklerzahl.
• [ ] Ausfall- und Wiederherstellungsanforderungen sind bewertet.
• [ ] Datenschutz, DSGVO-Anforderungen und Datenlöschung sind geklärt.
• [ ] Der Bedarf an festem Knoten, temporärer Kapazität oder Hybridbetrieb ist begründet.
• [ ] Offene Beweislücken stehen neben der Entscheidung und werden nicht stillschweigend als erfüllt markiert.

Braucht die Mac-CI nach zusätzlichen iPhone-Duo-Regressionen mehr Kapazität?

Nicht automatisch. Eine Erweiterung ist erst begründet, wenn die neue Testlast die bestehende Release- oder Entwicklerwarteschlange messbar beeinträchtigt, die Validierung wegen fehlender Isolation nicht parallel laufen kann oder die Wiederherstellung nach einem Fehler die vereinbarten Betriebsgrenzen überschreitet. Diese Grenzen müssen aus Ihren eigenen CI-Daten und Betriebsanforderungen stammen.

Wir unterscheiden vier Entscheidungen:

Für eine befristete Prüfung kann ein Remote-Mac-PoC von MESHLAUNCH sinnvoll sein, wenn Zugriff, Datenlöschung, Benutzerrechte und Wiederherstellung vorab in der eigenen Abnahmeliste stehen. Bei dauerhaft hoher, planbarer Last kann der Kauf eines eigenen Mac-Knotens besser passen. Eine Bewertung verfügbarer Mac-mini-Konfigurationen ist dann nur ein Teil der TCO-Prüfung; Wartung, Ersatzgerät, Fernzugriff, Stromversorgung und interne Betriebszeit gehören ebenfalls in die Rechnung.

Der aktuelle Ansatz mit gemeinsamem Produktionsknoten hat drei reale Nachteile: Experimentelle Toolchains können stabile Builds verunreinigen, neue Regressionen können die Release-Warteschlange verlängern, und eine unklare Signierungsgrenze vergrößert das Risiko für Zertifikate und interne Artefakte. Ein sofortiger Hardwarekauf löst diese Probleme ebenfalls nicht, wenn weder Testdauer noch Peak-Last bekannt sind.

Wir empfehlen deshalb, nach der Rollenabnahme zunächst einen isolierten Remote Mac für das repräsentative Projekt einzusetzen. Dort lassen sich Xcode-27.1-Validierung, Haltungsregression, Artefaktablage und Wiederherstellung unter realen CI-Bedingungen messen, ohne den produktiven Signierungspfad zu öffnen. Wenn die Logs anschließend eine dauerhafte, planbare Last zeigen, ist ein fester eigener Knoten plausibel. Wenn nur ein begrenztes Anpassungs- oder Veröffentlichungsfenster entsteht, bleibt die befristete MESHLAUNCH-Miete die flexiblere Lösung.

Nutzen Sie für die Entscheidung nicht die Zahl neuer Geräte, sondern die nachgewiesene Warteschlange, Testfrequenz, Laufzeit und Sicherheitsgrenze. Genau diese Messung entscheidet, ob bestehende Kapazität genügt, ein eigener Validierungsknoten erforderlich wird oder eine temporäre Remote-Mac-Umgebung den saubereren Weg bietet.