Warum ich Cursor mit dem Figma-MCP nutze — und trotzdem am iPhone per Kabel teste

„Frontend mit KI-Unterstützung" bedeutete früher: einen Screenshot in einen Chat einfügen und CSS zurückbekommen, das nah dran war, aber nie genau den richtigen Abstand, das richtige Grau, die richtige Zeilenhöhe hatte. Das Model Context Protocol hat genau diesen Teil der Design-Übergabe verändert. Cursor spricht mit dem Figma-MCP-Server, und statt einen Frame für das Modell zu Pixeln zu flatten, aus denen es raten muss, bekommt es den echten Node-Baum: Auto-Layout, Abstandswerte, gebundene Variablen, Komponentennamen, Typo-Skala. Genau darauf verlasse ich mich täglich.

1. Was der MCP wirklich richtig macht

Ich wähle einen Frame in Figma aus, gebe Cursor den Link, und es fragt den MCP-Server nach genau diesem Node ab. Zurück kommt Strukturiertes: Ein 8px-Gap ist die tatsächliche Zahl 8, nicht etwas, das ich mit einem Lineal-Tool auf einem PNG abmesse. Eine Farbe ist der Design-Token oder Hex-Wert, den die Designerin gebunden hat, kein Wert, den ich mit einer Pipette wähle und hoffe, dass er passt. Schriftgewicht, Zeilenhöhe, Eckenradius, die tatsächliche Komponentenhierarchie — alles kommt als Daten an, nicht als Bild, das ich zurückentwickle.

• Abstände, die zum Design-System passen, nicht die nächste runde Zahl, die ich geschätzt habe.
• Farben und Typo als Tokens, sodass ein Rebranding eine Variable aktualisiert statt ein Grep über alle Komponenten.
• Komponentengrenzen, die dazu passen, wie die Designerin Dinge tatsächlich gruppiert hat — das macht das generierte Markup leichter semantisch zu halten.

2. Was ich immer noch von Hand prüfe

Strukturierte Daten sind kein Urteilsvermögen. Ein Figma-Frame zeigt jeweils einen Breakpoint; er sagt Cursor nicht, was zwischen 768px und 1024px passiert, oder wie eine Karte mit zweizeiligem statt einzeiligem Titel aussieht. Es gibt keinen Empty-State, keinen Error-State, kein Loading-Skeleton, weil dafür nie ein Design-Frame existierte. Und generiertes Markup kann strukturell exakt zum Frame passen und trotzdem ein div sein, wo ein Button, ein Nav oder ein Überschriften-Tag hingehört — ich lese vor dem Merge immer noch jede Komponente auf Semantik und Tastaturzugänglichkeit.

3. Warum ein Emulator nicht reicht

Die Geräteleiste in Chrome DevTools ist Chromium, das einen verkleinerten Viewport rendert. Das ist kein WebKit, es hat nicht das dynamische Viewport-Verhalten von iOS Safari, und es zeigt keine Bugs, die nur auf der echten Engine existieren. Der letzte Schritt vor jedem Release ist deshalb, ein echtes iPhone per Kabel an meinen Mac anzuschließen. Einstellungen → Safari → Erweitert → Web-Inspector, einmal am Telefon aktiviert. Dann ein Lightning- oder USB-C-Kabel zum Mac, das Develop-Menü von Safari erkennt das Gerät, und ich bekomme einen Live-Web-Inspector — echtes DOM, echte Konsole, echtes Netzwerk-Panel — an einer Seite, die wirklich auf iOS Safari läuft, keine Simulation davon.

Genau dort finde ich die Bugs, die ein Emulator versteckt: safe-area-inset-Padding, das in DevTools gut aussieht und auf dem echten Handy unter der Notch abgeschnitten wird, ein 100vh-Sprung, wenn Safaris Adressleiste beim Scrollen einklappt (dvh behebt das, aber nur ein Live-Test beweist es), der Input-Fokus-Sprung, wenn die Tastatur bei fixiertem Footer aufgeht, Rubber-Band-Overscroll, der das ganze Layout mitzieht, und wie sich die Seite tatsächlich verhält, wenn sie als eigenständige PWA zum Homescreen hinzugefügt wurde. Nichts davon zeigt sich in einem Emulator. Alles davon zeigt sich, sobald eine echte Kundin den Link zum ersten Mal auf ihrem eigenen Handy öffnet — also sehe ich es lieber vorher.

4. Warum ausgerechnet Safari — der Browser, für den ich wirklich ausliefere

Ich schaue mir die Analytics an, bevor ich entscheide, was „korrekt" für ein Projekt überhaupt bedeutet. Bei den meisten Kleinunternehmen- und Service-Sites, die ich baue, öffnet die Kundin die Site auf dem Handy, kommt von Instagram, Telegram, Google Maps oder einer SMS — und bei einem großen Teil dieses Traffics ist dieses Handy ein iPhone. Desktop-Chrome ist, wo ich entwickle. iOS Safari ist, wo die Person mit der Kreditkarte tatsächlich ist. Pixelgenauigkeit für den Browser zu optimieren, den ich den ganzen Tag anstarre, und den zu überspringen, den die Kundin meiner Kundin tatsächlich in der Hand hält, heißt, für das falsche Publikum zu optimieren.

Der tatsächliche Ablauf

Figma-Frame, ausgewählt und über den MCP an Cursor übergeben. Komponente gebaut aus echten Tokens, nicht geschätzten Pixeln. Ein Durchgang für Semantik, Zustände und Breakpoints, die der Frame nie gezeigt hat. Dann kommt das iPhone aus der Schublade, wird an den Mac angeschlossen, und dieselbe Seite läuft live in Safaris Web-Inspector auf der echten Engine. Erst danach wird irgendetwas gemergt. Zwei verschiedene Tools, zwei verschiedene Aufgaben: eines bringt mich schnell nah ans Design, das andere sagt mir die Wahrheit über das Gerät, das die Kundin meiner Kundin tatsächlich benutzen wird.

Soll es auf dem Handy Ihrer Kundschaft tatsächlich richtig aussehen?

Das ist die Pipeline, die ich bei jedem Build fahre: echte Design-Tokens rein, echtes Gerät raus. Melden Sie sich über das Kontaktformular und sagen Sie mir, welche Plattform Ihre Kundschaft tatsächlich nutzt — ich baue und teste für genau die, nicht für den Browser, der für mich bequem ist.