App Store Screenshots mit Cursor erstellen: Eine Schritt-für-Schritt-Anleitung

Wenn Sie zu den vielen Entwicklern gehören, die Teile ihres Workflows in Cursor verlegt haben – dem KI-Coding-Assistenten/Hackers-Editor, der die Indie-Szene auf Twitter erobert – dann laufen wahrscheinlich Ihr Code, Ihre Commits und Tests alle in diesem Fenster ab. Aber eine App zu veröffentlichen bedeutet mehr als nur Code. Irgendwann brauchen Sie umsatzstarke Screenshots für den App Store oder Google Play, und die bremsen Ihren Schwung auf eine Weise, wie es keine Docstring je könnte.

So baue ich auf meinem Mac ein Set verkaufsfertiger Screenshots für iOS und Android – meist in Cursor, mit einem kurzen Abstecher in den Browser für die Erstellung und den Export. Das ist ein schneller, iterativer Workflow. Wenn Sie an einen Designer übergeben und ihn in Figma schrauben lassen wollen, sind Sie hier falsch. Wenn Sie es hassen, einen Tag mit dem Export von Simulator-PNGs zu verlieren und das gleiche Layout zehnmal neu zu bauen, lesen Sie weiter.

Schritt 1: Simulator-Screenshots aufnehmen

Starten Sie Ihre App im Xcode Simulator oder auf einem verbundenen Gerät. Für App Store Connect benötigen Sie Bilder in mehreren Größen. Für iOS sollten Sie unbedingt Screenshots vom 6,7" (iPhone 14/15 Pro Max, 1284x2778) und 6,5" (iPhone 12/13 Pro Max, 1242x2688) machen. Für Android listet Google Play sämtliche Gerätegrößen auf, aber 1080x1920 ist der Median für Handy-Screenshots. Apples Dokumentation nennt die genauen Anforderungen, aber beachten Sie, dass Geräte regelmäßig veraltet werden – prüfen Sie daher die App Store Connect Anforderungen, bevor Sie Zeit verschwenden.

Um im Simulator einen Screenshot zu machen, legt Command+S eine PNG-Datei auf Ihrem Desktop ab. (Wenn Sie in der iOS-17-Ära sind und das nicht funktioniert, probieren Sie Datei > Bildschirmfoto speichern.) Für Android starten Sie Ihre App im Emulator von Android Studio und klicken auf den Kamera-Button oder drücken Control+S. Synchronisieren Sie diese dann in den /screenshots-Ordner Ihres Projekts, falls Sie alles versioniert halten wollen – Cursor macht das Umschalten von Ordnern trivial, es spricht also nichts dagegen.

Schritt 2: Screens auswählen

Laden Sie nicht jeden Screen ins App-Listing. Wählen Sie maximal 5, die die besten Abläufe zeigen: Onboarding, Hauptfunktion, Bezahlschranke und (wenn Ihre App B2B oder stark workflow-orientiert ist) jeden Screen, der den Wert schnell kommuniziert. Wenn Screens Benutzerdaten zeigen, verwenden Sie realistische Demo-Inhalte – leer geräumte States killen die Conversion. Ich sehe mir die Reihenfolge der Screens bei Top-Apps Ihrer Kategorie (z. B. Duolingo, Sudoku.com) als Referenz an. Vermeiden Sie lange leere Platzhalter oder etwas, das wie ein Fehler wirkt.

Schritt 3: Store-Richtlinien und Textlimits prüfen

Apple lehnt wegen Textüberlauf, Copyright-Logos oder UI-Artefakten ab. Google legt weniger Wert auf Politur, will aber Screenshots, die echte App-Funktionalität zeigen. Wenn Sie Text überlagern wollen, halten Sie Callouts auf einzelne Sätze (20–30 Zeichen funktionieren für Überschriften, das entspricht ungefähr der halben iPhone-Breite bei 14pt). Wenn Sie lokalisieren möchten, planen Sie längere Phrasen für Deutsch oder Russisch im Vergleich zu Englisch ein.

Ich habe gesehen, wie Nischen-Produktivitäts-Apps Wochen mit Übersetzungen verbrauchten. Wenn Sie nicht bereits unter den Top 100 in Ihrem Heimatland sind, überspringen Sie Übersetzungen zum Start und holen das später nach, wenn Sie echten Traffic aus dem Ausland haben.

Schritt 4: Verkaufsfertige Screenshots mit ScreenshotWhale generieren

Hier verlässt der Workflow für ein paar Minuten Cursor. Roh-Simulator-Screenshots sehen entwicklerhaft aus: leere Balken, harte Hintergründe und schlechte Ausschnitte. Für Conversion, um auszusehen wie die Leute hinter Headspace oder Calm, benötigen Sie markenkonforme Frames, Geräte-Rahmen und prägnante Text-Overlays. Figma-Vorlagen erfüllen den Zweck (irgendwie), aber für Geschwindigkeit und Konsistenz generiere ich meine mit ScreenshotWhale. Dort gibt es editierbare Templates für moderne Geräte-Rahmen und App Store/Google Play Größen. Laden Sie Ihre PNGs hoch, fügen Sie Screenshots in die Templates ein, verfassen Sie die Bildunterschriften und wählen Sie Farb-Akzente. Alles exportiert in den exakt vom Store geforderten Pixelmaßen. Kleinere Anpassungen (wie Zuschneiden oder Gerätetyp) lassen sich im Browser vornehmen – das schlägt Sketch oder Affinity Designer für jede kleine Änderung zu starten.

Haben Sie eine Markenfarbe, setzen Sie sie vor dem Export auf Hintergründe. (Es gibt immer Gründer, die Pastellverläufe rocken, als wäre es 2021. Vermeiden Sie ausgewaschenen Text auf hellen Hintergründen – Lesbarkeit gewinnt immer.) Wenn Ihr App-UI im Dark Mode ist, passen Sie den Template-Stil an, um beste Kontinuität zu gewährleisten; zwingen Sie keinen weißen Telefonrahmen auf eine überwiegend schwarze UI.

Schritt 5: Endgültige Sets exportieren und organisieren

Exportieren Sie die einzelnen Größen, die jeder Store verlangt (App Store Connect: 6,7", 6,5"; Google Play: 1080x1920 oder was das Formular für Tablets/Handys fordert). Manche Entwickler überspringen zu Beginn ältere iPhones oder iPads – Apple skaliert 6,7"-Shots runter, aber prüfen Sie, wie Ihre App auf diesen Bildschirmen aussieht, sonst gibt’s ausgecroppte UI und Supportstress. Speichern Sie die Dateien mit klaren Namen: 01-onboarding-iphone15pro.png statt IMG_8432.png. Ich halte Versionshistorien von Screenshot-Runden im Repository, besonders bei Apps, die wöchentlich iterieren oder A/B Tests mit visuellem Text fahren.

Bonus: Automatisierung von Screenshot-Runden

Wenn Sie Builds skripten oder auf einen Markdown-getriebenen Release-Prozess in Cursor setzen, können Sie Shell-Skripte (Simulator-Kommandozeilentools, adb für Android) verbinden, um Screenshots beim Build auszugeben. Leiten Sie die Rohbilder in einen Cloud-Ordner und importieren Sie sie in ScreenshotWhale zur visuellen Erzeugung. Ich habe diesen Schritt noch nicht vollständig mit Store-Upload-APIs verknüpft, aber ich kenne Tester mit automatisierten End-to-End Screenshot-Pipelines. Je mehr Releases Sie fahren, desto wertvoller wird Ihre Zeit – verschwenden Sie sie nicht mit monotonen Aufgaben.

Wie sieht’s mit KI-generierter UI aus?

Wenn Ihre App KI-gestützt oder UI-gesteuert ist (denken Sie an Arc, Lensa AI oder irgendeinen Fotoeditor), müssen Ihre Screenshots sowohl das Produkt als auch die Magie zeigen. Cursors Chat-Kompletierungen oder Code-Snippets helfen da wenig. Sie brauchen visuelle Reize, die Verlangen erzeugen, nicht nur Funktionalität dokumentieren. Manchmal nutze ich Midjourney oder DALL-E als Background-Generator, aber bei 99 % der Apps sind Overlays auf realer UI besser als Fantasie-Renderings. Zu viel Fake-Politur führt dazu, dass Reviewer Ihre App flaggen, wenn diese visuelle Qualität nicht tatsächlich geboten wird.

Einreichen und Aktualisieren

Haben Sie Screenshots, laden Sie sie direkt in App Store Connect oder Play Console hoch. Prüfen Sie Uploads auf hellen und dunklen Hintergründen; speziell der App Store zeigt Ihre Visuals auf Weiß, Google Play verwendet für manche Listings Schwarz. Kleine Fehler bei der Ausrichtung können Ihre Conversion-Rate schnell ruinieren. Wenn Sie Rendering-Bugs in der Store-Vorschau entdecken, generieren Sie neu und exportieren erneut – geben Sie sich nicht mit weniger zufrieden, die Reviewer tun das auch nicht.

Ich teste finale Listings auf echten Geräten mit dem TestFlight Public Beta Flow oder internen Google Play Tracks – nutzen Sie User-DMs oder einen Tweet, um frische Augen zu bekommen. Die meisten Bugs und schlechten Crops werden hier gefunden, nicht im Editor.

Letzter Schritt: Geschwindigkeit vor Perfektion

Cursor ist für Entwicklergeschwindigkeit gebaut, nicht für Design. Setzen Sie auf schnelle, wiederholbare Screenshot-Runden statt pixelperfekter Einzelstücke. Die meisten Indies investieren zu viel in ihr erstes Screenshot-Set und tauschen es nach dem Launch sowieso aus. Veröffentlichen Sie etwas Sauberes und Fokussiertes, aktualisieren Sie es mit Feedback und sparen Sie Ihre Kapazitäten fürs Feature-Shipping und nicht fürs stundenlange Schrauben an Screenshot-Pixeln.