Figma eignet sich, um Ihren iPhone-Duo-Entwurf vorzubereiten; ob die native Anwendung in unterschiedlichen Gerätehaltungen korrekt reagiert, lässt sich damit allein nicht bestätigen. Übergeben Sie deshalb Layoutabsicht, Zustände und offene Fragen an die Entwicklung und planen Sie eine Mac-Abnahme erst, wenn ein ausführbarer Entwicklungsbuild und eine offiziell bestätigte Testumgebung verfügbar sind. Gehen Sie nicht davon aus, dass ein Simulator das Gerät bereits unterstützt.

Diese Woche: Klären Sie zuerst, ob Sie einen Entwurf, eine Interaktionsbeschreibung oder das Verhalten einer laufenden Anwendung abnehmen sollen. Daraus ergibt sich, ob Figma genügt oder eine native Prüfung ansteht.

Dieser Ablauf ist für Sie gedacht, wenn Sie als UI-Designer in Figma für iPhone Duo entwerfen, als Produktdesigner ein zweigeteiltes Layout an die Apple-Plattform-Entwicklung übergeben oder als Teamverantwortlicher unter Windows den Bedarf für eine Mac-Testumgebung beurteilen.

Zuletzt aktualisiert am 10.10.2026. Die Angaben zu Designmaterialien und Prüfgrenzen wurden anhand der Apple-Designressourcen, der iPhone-Duo-Designrichtlinien und der Apple-Entwicklungsinformationen für iPhone Duo abgeglichen.

01

Vor dem Entwurf: Abnahmeziel und Belege auseinanderhalten

Ein Figma-Prototyp, eine Entwicklerübergabe und ein getesteter Anwendungsbuild sind unterschiedliche Ergebnisse. Wenn Sie diese Begriffe im Projektplan vermischen, kann ein sauberer Entwurf fälschlich als Funktionsnachweis gelten. Legen Sie daher vor der Arbeit fest, welche Aussage Sie am Ende treffen müssen.

Ein visueller Entwurf zeigt, wie eine Oberfläche aussehen soll. Eine Interaktionsbeschreibung hält fest, was auf Eingaben oder einen Wechsel der Gerätehaltung hin passieren soll. Ein Entwicklungsbuild ist eine ausführbare Anwendung, in der das Team Implementierungen prüfen kann. Eine native Geräteabnahme bewertet schließlich das Verhalten in einer bestätigten Testumgebung. Nur die letzten Schritte können belegen, wie die implementierte Anwendung tatsächlich läuft.

Schreiben Sie das Abnahmeziel in einen Satz. Zum Beispiel: „Wir prüfen, ob die Navigation im breiten Layout erhalten bleibt, wenn sich die verfügbare Bildschirmfläche ändert.“ Das ist genauer als „Duo-Layout abnehmen“, weil es ein erwartetes Verhalten und einen möglichen Auslöser benennt.

Trennen Sie außerdem drei Arten von offenen Punkten:

  • Designentscheidung: Das Team hat festgelegt, wie die Oberfläche wirken und organisiert sein soll.
  • Implementierungsfrage: Die Entwicklung muss entscheiden, wie sich dieses Verhalten im Code umsetzen lässt.
  • Umgebungsfrage: Es ist noch ungeklärt, ob das Zielgerät oder ein passender Simulator für die Prüfung verfügbar und unterstützt ist.

Diese Trennung schützt Ihr Abnahmeprotokoll vor einer häufigen Verwechslung: Ein statisches Bild kann eine vorgesehene Ansicht zeigen, aber weder ein Geräteverhalten noch die Verfügbarkeit einer Testumgebung belegen.

02

Schritt 1: Die Figma-Grundlage auf die offiziellen Ressourcen stützen

Apple hat Designinformationen zu iPhone Duo veröffentlicht und stellt Designressourcen einschließlich eines Figma UI Kit für iOS und iPadOS 27 bereit. Verwenden Sie diese Materialien als Ausgangspunkt für Ihren Entwurf und gleichen Sie die verwendeten Ressourcen mit Apples Designressourcen-Seite ab.

Das Figma UI Kit beschleunigt die Gestaltung und hilft, bereitgestellte Elemente in Ihren Entwurf einzubeziehen. Es ist jedoch weder ein Nachweis dafür, dass Ihr konkreter Entwurf den Anforderungen entspricht, noch eine Garantie für das Verhalten einer laufenden App. Die eigentliche Entscheidung über Navigation, Inhaltsprioritäten, Zustände und Übergänge bleibt bei Ihrem Projektteam.

Prüfen Sie vor dem Entwurf:

  1. Ressourcenquelle: Verwenden Sie die offiziellen Materialien und dokumentieren Sie, welche Figma-Datei beziehungsweise welche Kit-Version im Projekt eingesetzt wird.
  2. Projektbezug: Kennzeichnen Sie, welche Frames tatsächlich für iPhone Duo vorgesehen sind und welche lediglich als allgemeine Komponentenbibliothek dienen.
  3. Nutzungsrahmen: Prüfen Sie Apples Lizenzbedingungen für Designressourcen, bevor Sie Materialien weitergeben oder in Teamabläufe übernehmen.
  4. Arbeitsumgebung: Falls Sie Figma unter Windows im Browser verwenden, kontrollieren Sie die Figma-Hinweise zur Browserkonfiguration. Eine funktionierende Browserumgebung erleichtert die Designarbeit, ersetzt aber nicht die native Prüfung.

Kann ein Windows-Team die iPhone-Duo-Oberfläche zunächst in Figma vorbereiten? Ja. Sie können Frames, Komponenten, Kommentare und Interaktionsabsichten in Figma ausarbeiten und an Entwickler weitergeben. Beschreiben Sie das Ergebnis aber als Designvorbereitung. Behaupten Sie nicht, die native Darstellung oder Gerätekompatibilität sei damit getestet.

03

Schritt 2: Layout und Haltungswechsel als nachvollziehbare Zustände darstellen

Ein Entwurf für ein Gerät mit dynamischer, zweigeteilter Darstellung sollte nicht nur eine bevorzugte Ansicht zeigen. Apple verweist in den Designrichtlinien für iPhone Duo auf Gerätehaltungen und dynamische Layouts über beide Bildschirmbereiche. Machen Sie daher sichtbar, welche Inhalte zusammengehören und wie sich ihre Anordnung in den vorgesehenen Zuständen verändern soll.

Erstellen Sie für jede repräsentative Ansicht eine klare Zuordnung:

  • Ausgangsansicht: Welche Inhalte sieht die Person beim Öffnen des jeweiligen Bereichs?
  • Zweiteilung: Welche Information steht im ersten und welche im zweiten Bereich? Bleiben beide Bereiche gleichzeitig relevant?
  • Wechsel der Haltung: Was ordnet sich neu, was bleibt sichtbar und was wird ausgeblendet?
  • Navigation: Wird ein Element ersetzt, ergänzt oder in einem anderen Bereich geöffnet?
  • Rückkehr: Wie gelangt die Person zur vorherigen Ansicht, und bleiben Auswahl oder Eingaben erhalten?
  • Sonderzustand: Was zeigt die Oberfläche bei leeren Inhalten, Ladezustand, Fehler oder einer nicht verfügbaren Funktion?

Die Zustandsliste sollte nicht künstlich jedes denkbare Detail enthalten. Nehmen Sie die Zustände auf, die eine andere Layoutentscheidung oder ein anderes erwartetes Verhalten auslösen. Wenn Sie beispielsweise eine Detailansicht im zweiten Bereich öffnen, kennzeichnen Sie sowohl den vorherigen als auch den neuen Zustand. Ein einzelner Screenshot der fertigen Ansicht reicht nicht, um den Übergang zu erklären.

Welche Zustände gehören in die Prüfung des zweigeteilten Layouts? Mindestens die für Ihr Produkt relevanten Ansichten, die Zuordnung von Inhalt zu Bereich, Änderungen bei einem Haltungswechsel und die Navigation zwischen Übersicht und Detail. Ergänzen Sie leere, fehlerhafte oder noch nicht unterstützte Zustände, wenn sie eine sichtbare Layoutentscheidung beeinflussen.

Ordnen Sie Ihre Figma-Frames nach diesen Zuständen statt nach internen Design-Dateinamen. Geben Sie jedem Frame eine verständliche Bezeichnung, etwa „Übersicht – breite Darstellung“ oder „Detail geöffnet – Auswahl erhalten“. Schreiben Sie dazu, ob der Frame einen verbindlichen Entwurf, eine Alternative oder nur eine offene Hypothese zeigt.

04

Schritt 3: Übergabe so vorbereiten, dass Entwickler den Entwurf rekonstruieren können

Eine gute Übergabe beantwortet nicht nur die Frage „Wie sieht es aus?“, sondern auch „Was soll passieren, wenn sich die Situation ändert?“ Entwicklern müssen die relevante Ausgangslage, das erwartete Ergebnis und bekannte Unsicherheiten vorliegen. Andernfalls müssen sie Absichten aus Screenshots ableiten und können eine Abweichung zwischen Entwurf und Implementierung nur schwer einordnen.

Packen Sie diese Bestandteile in die Übergabe:

  1. Einstiegspunkt: Verlinken Sie auf die relevanten Figma-Seiten und benennen Sie den vorgesehenen Start-Frame.
  2. Repräsentative Ansichten: Fügen Sie nur die Frames ein, die eine Designentscheidung oder einen wichtigen Zustand belegen. Markieren Sie Varianten ausdrücklich als Varianten.
  3. Zustandsfolge: Beschreiben Sie in kurzen Schritten, welche Aktion zu welcher Ansicht führt und ob Inhalte beim Wechsel erhalten bleiben sollen.
  4. Layoutabsicht: Erklären Sie, welche Inhalte Priorität haben, was zusammengehört und welche Elemente sich abhängig von der verfügbaren Darstellung ändern.
  5. Offene Fragen: Kennzeichnen Sie Annahmen, die noch nicht entschieden oder technisch geprüft sind.
  6. Abnahmeverantwortung: Trennen Sie, was Design visuell kontrolliert, was Entwicklung implementiert und was erst in einer nativen Testumgebung geprüft werden kann.

Wie übergeben Sie einen iPhone-Duo-Figma-Prototyp an die Entwicklung? Geben Sie den Figma-Einstiegspunkt, beschriftete Zustände, die erwarteten Übergänge und eine Liste offener Punkte gemeinsam weiter. Legen Sie fest, welche Aussagen Designvorgaben sind und welche erst die Entwicklung oder eine spätere Geräteprüfung bestätigen kann.

Ein konkretes Beispiel: Sie liefern eine Übersicht mit einer zugehörigen Detailansicht und erwarten, dass die Auswahl nach einer Änderung der Gerätehaltung bestehen bleibt. Notieren Sie die Auswahl als Zustand, zeigen Sie beide Ansichten und formulieren Sie die Erhaltungsanforderung. Schreiben Sie nicht „auf dem Gerät funktioniert es“, solange niemand die laufende Anwendung in einer passenden Umgebung geprüft hat.

Vereinbaren Sie für Rückmeldungen eine wiederverwendbare Fehlerbeschreibung: Ausgangszustand, durchgeführte Aktion, beobachtetes Ergebnis, erwartetes Ergebnis, verwendeter Build und Testumgebung. Der letzte Punkt ist entscheidend, sobald es um native Ergebnisse geht. Ein Designkommentar ohne Angaben zur Umgebung kann die Ursache einer Abweichung nicht belegen.

05

Schritt 4: Mac und Testumgebung erst bei einem nativen Prüfschritt einplanen

Der Übergang von Figma zur Mac-Abnahme sollte nicht automatisch erfolgen, nur weil es um ein Apple-Gerät geht. Klären Sie zuerst, ob ein ausführbarer Entwicklungsbuild vorliegt und ob Apple die für Ihr Vorhaben benötigte Geräte- oder Simulatorunterstützung bestätigt hat. Die Vorbereitungsinformationen für iPhone Duo sowie Apples jeweilige Xcode-27.1-Versionshinweise sind mögliche offizielle Prüfstellen. Die Versionshinweise belegen für sich allein jedoch nicht, dass Ihr konkretes Gerät oder Ihr benötigter Testfall unterstützt wird.

Auch eine Erklärung zur allgemeinen Simulatorbedienung ist kein Kompatibilitätsnachweis. Apples Xcode-Simulator-Anleitung kann beim Verständnis von Simulatorabläufen helfen. Ob sich damit gerade Ihr iPhone-Duo-Szenario testen lässt, müssen Sie anhand der aktuellen offiziellen Unterstützung und Ihres konkreten Builds prüfen.

Ist für die native Abnahme zwingend ein Mac erforderlich? Nicht für das Erstellen und Besprechen eines Figma-Entwurfs. Wenn Sie aber Apples native Entwicklungswerkzeuge für einen ausführbaren Build oder einen nativen Prüfschritt benötigen, müssen Sie eine geeignete macOS-Umgebung einplanen. Entscheidend ist nicht die Bezeichnung „Mac“, sondern ob Build, Werkzeuge, Zielgerät und Testfall tatsächlich zusammenpassen.

Was sollte ein Windows-Team vor der Mac-Buchung klären? Lassen Sie sich von der Entwicklung bestätigen, welcher Build vorliegt, welches Verhalten geprüft werden soll und welche offizielle Geräte- oder Simulatorunterstützung dafür bekannt ist. Wenn diese Punkte offen sind, kann ein Mac-Zugang allein die fehlende Testgrundlage nicht ersetzen.

Wenn Sie einen befristeten macOS-Zugang erwägen, vergleichen Sie den Aufwand mit dem tatsächlichen Prüfbedarf. Die Mietkosten für einen Mac mini M4 können Sie als Kosteninformation heranziehen; die passende Umgebung und die tatsächliche Verwendbarkeit für Ihren Testfall müssen Sie separat bestätigen. Prüfen Sie vorab auch, welche Dateien, Konten und Projektdaten auf die Umgebung übertragen werden. Für vertrauliche Kundenprojekte sollten Ihre Datenschutz- und Zugriffsregeln feststehen, bevor Sie Zugangsdaten oder Material bereitstellen.

06

Schritt 5: Abnahme mit getrennten Ergebnissen abschließen

Führen Sie die Designprüfung und die native Prüfung als getrennte Nachweise. So können Sie einen vollständig überprüften Figma-Entwurf freigeben, ohne daraus eine unbelegte Aussage über die laufende Anwendung abzuleiten.

Dokumentieren Sie am Ende für jeden Prüfpunkt einen dieser Status:

  • Geprüft: Die angegebene Prüfmethode wurde durchgeführt und das Ergebnis ist dokumentiert.
  • Offen: Es fehlt noch eine Entscheidung, ein Build, eine bestätigte Testumgebung oder ein Prüfschritt.
  • Nicht anwendbar: Der Punkt betrifft die vorliegende Funktion oder den bestätigten Projektumfang nicht.

Fügen Sie zu „Geprüft“ immer die passende Evidenz hinzu. Bei einer visuellen Prüfung kann das der benannte Figma-Frame mit dokumentiertem Feedback sein. Bei einer nativen Prüfung gehören die bekannte Testumgebung, der verwendete Build, der beobachtete Zustand und das Ergebnis dazu. Verwenden Sie keinen Screenshot eines statischen Entwurfs als Beleg für Geräteverhalten.

Entscheidung nach Bedingungen:

  • Wenn Sie ausschließlich visuelle Gestaltung, Kommentare und Interaktionsabsichten abstimmen müssen, dann schließen Sie die Figma-Übergabe ab und führen die offenen Fragen als Design- oder Implementierungspunkte weiter.
  • Wenn ein ausführbarer Build vorhanden ist und Apple die benötigte Testumgebung offiziell bestätigt, dann planen Sie die native Prüfung mit Entwicklung und dokumentieren Sie die Umgebung.
  • Wenn ein Build oder die offizielle Unterstützung noch fehlt, dann kennzeichnen Sie die native Abnahme als offen. Leiten Sie daraus weder Simulatorverfügbarkeit noch einen erfolgreichen Gerätetest ab.
  • Wenn Ihr Team nur einen macOS-Werkzeugschritt ausführen muss, dann prüfen Sie zunächst, ob ein zeitlich begrenzter Zugang genügt. Bei wiederkehrenden, dauerhaft hohen Anforderungen kann ein eigener Mac besser passen.
Prüfabschnitt Was Sie belastbar beurteilen können Was Sie dafür benötigen Häufige Fehlinterpretation
Figma-Entwurf Vorgesehene Ansichten, Inhaltsprioritäten und Designvarianten Benannte Frames, Komponenten und Designfeedback Ein fertiger Frame beweise native Darstellung
Interaktionsübergabe Beschriebene Aktionen und erwartete Zustandswechsel Zustandsfolge, Übergangsnotizen und offene Fragen Eine Prototype-Verknüpfung belege das App-Verhalten
Entwicklungsbuild Implementierte Funktionen im verfügbaren Testumfang Ausführbarer Build und bestätigte Werkzeuge Jeder Build sei automatisch für iPhone Duo geeignet
Native Abnahme Beobachtetes Verhalten in der tatsächlich genutzten Umgebung Bestätigtes Gerät oder bestätigte Simulatorunterstützung sowie dokumentierter Prüflauf Allgemeine Simulatorinformationen bestätigten die Unterstützung des konkreten Szenarios

Für ein Windows-Team besteht der Vorteil des beschriebenen Ablaufs darin, dass Designarbeit und native Abnahme nicht miteinander verwechselt werden. Der Nachteil: Eine Figma-Datei kann eine fehlende Entwicklungsumgebung nicht ersetzen, und eine gemietete Mac-Umgebung löst weder ungeklärte Geräteunterstützung noch fehlende Builds. Wenn Ihr Projekt nur gelegentlich native Werkzeuge benötigt, kann ein eigener Mac für diese Aufgabe unnötig sein. Wenn Sie dagegen dauerhaft intensive Arbeit leisten oder physische Anschlüsse und lokale Geräte benötigen, sollten Sie vorübergehende Fernnutzung nicht als automatischen Ersatz für einen festen Arbeitsplatz behandeln.

Wenn nach der Übergabe tatsächlich ein macOS-Werkzeugschritt ansteht, prüfen Sie zuerst, ob Build, Projektzugriff und bestätigte Testbedingungen vorhanden sind. Erst dann ist ein gemieteter Mac von VpsMesh eine mögliche Alternative zu den Nachteilen eines ausschließlich Windows-basierten Ablaufs: native Prüfschritte bleiben unzugänglich, die Abstimmung mit der Entwicklung wird unnötig verzögert und ein Designentwurf kann fälschlich als Geräteabnahme gelten. Für passende Projekte können Sie sich über Mac-Zugangsoptionen bei VpsMesh informieren; wenn die Testgrundlage noch ungeklärt ist, warten Sie mit der Anmietung.