Das Rezept für eine großartige iOS-App 🍳

Du kennst dieses Gefühl: Du öffnest eine App und sie funktioniert – nicht nur im Sinne von „sie kompiliert“, sondern weil sie dich versteht. Alles sitzt am richtigen Platz, nichts hakt, und am Ende denkst du: „Das war angenehm.“ Und du kennst das Gegenteil: ein träger Button, ruckelndes Scrollen, ein Berechtigungs-Popup, das dir entgegenspringt, bevor du überhaupt weißt, wofür die App gut ist. Zwischen beidem liegt eine ganze Welt. Sie entsteht fast nie durch ein magisches Feature. Sie entsteht durch ein Rezept.

Ich veröffentliche Apps seit den ersten Tagen des App Store, seit 2008. Rund vierzig Apps, zusammen mehrere hundert Millionen Downloads und etwa fünfzehn WWDCs später bekomme ich immer noch dieselbe Frage: Was macht eine App großartig und nicht bloß funktionsfähig? Ich schreibe diese Zeilen direkt nach der WWDC26, noch etwas benommen von Apple Park. Nach meiner Rückkehr habe ich mit Claire einen Vortrag zu zweit gehalten. Er hieß The Recipe to Build a Great iOS App. Hier kommt die lange Fassung: das vollständige Rezept, für das auf der Bühne nie genug Zeit bleibt.

Warum ein Rezept?

Zwei Menschen mit denselben Eiern kochen nicht dasselbe Gericht. In der iOS-Entwicklung haben alle dieselben Zutaten: Swift, SwiftUI und Xcode, kostenlos; Hunderte frei verfügbare WWDC-Sessions; Schritt-für-Schritt-Tutorials; und die Human Interface Guidelines, Apples Design-Bibel, nur einen Klick entfernt. Niemand hat eine geheime Zutat versteckt. Eine großartige App unterscheidet sich dadurch, wie diese Zutaten zusammengesetzt werden. Und das kann man lernen.

Apple zeigt es jedes Jahr. 2026 erhielten unter mehr als zwei Millionen Apps nur zwölf einen Apple Design Award – ausgewählt aus 36 Finalisten in sechs Kategorien. Die Messlatte liegt hoch. Aber schau dir an, wer sie überwindet: ein Zwei-Personen-Studio in den Niederlanden neben einem Team, das seit zehn Jahren iteriert; ein Soloentwickler in Indien neben CD Projekt Red. Apples Botschaft ist eindeutig: Design ist weder eine Frage des Budgets noch der Teamgröße oder Reichweite. Es geht um Sorgfalt.

Das Lustigste daran: Diese Apps nutzt du wahrscheinlich schon. Du weißt nur noch nicht warum sie funktionieren. Im Laufe des Rezepts begegnen uns einige davon – nicht zum Namedropping, sondern weil jede einen bestimmten Punkt besser verkörpert als eine lange Erklärung.

Mit Absicht gestalten – das Ziel vor dem Code

Auf der WWDC26 veröffentlichte Apple eine grundlegende Session: Principles of great design (Session 250, siebzehn Minuten – sieh sie dir zweimal an). Apple nennt darin acht Prinzipien: Purpose, Agency, Responsibility, Familiarity, Flexibility, Simplicity, Craft, Delight. Und Apple betont etwas, das Junior-Entwickler ungern hören: Es gibt keine Formel. „Du musst dein Wissen und deine Intuition einsetzen.“ Ein Prinzip zu stärken kann ein anderes beeinträchtigen. Abwägen – das ist der Beruf. Die acht Prinzipien sind kein Rezept, das man sklavisch befolgt; sie sind deine Zutaten. Gekocht wird selbst.

Auf der Bühne übernahm Claire vier Prinzipien, ich die anderen vier. Hier bekommst du alle acht, in der Reihenfolge des Rezepts statt der Folien. Alles beginnt mit dem undankbarsten Punkt, den man immer überspringt: Purpose. Die Vorbereitung. Beim Kochen bedeutet das, alles bereitzustellen, bevor man den Herd einschaltet. Im Design heißt es, vor der ersten Codezeile die wichtigste Frage zu stellen: Hat das, was ich tue, einen echten Zweck? Wenn das nicht klar ist, ist es noch nicht bereit.

Mein erstes Beispiel ist grug, Gewinner des Apple Design Award 2026 in der Kategorie Delight & Fun. Das niederländische Studio Ocho besteht aus zwei Personen: Jip van der Velde und Michel Elings, die seit 2012 zusammenarbeiten. grug hat eine Idee: jeden Tag eine Aussage in neolithischem Grunzen. „only walking grug find breakthrough… sitting grug find nothing.“ Kein Login, keine Cloud, keine sozialen Funktionen. Die Stärke liegt nicht darin, was die beiden talentiert hinzugefügt haben, sondern in allem, was sie mutig weggelassen haben. Sie haben sogar eine handgezeichnete Schrift-Engine und eine eigene Statusleiste gebaut. Ihr Q&A auf Apples Website lohnt sich. Weglassen zählt genauso wie Hinzufügen. Zu entscheiden, was man baut, heißt auch zu entscheiden, was nicht hineinkommt.

Wie findest du den Zweck ganz praktisch? Schreib ihn in einen Satz: [was die App tut] für [wen], in [welchem Moment ihres Lebens]. Wenn dein Satz ein „und“ braucht, hast du vielleicht zwei Apps statt einer. Schreib danach alles auf, was du bauen könntest, und streiche, was dem Satz nicht dient. Jedes verbleibende Feature muss seine Miete zahlen: Ist es die Zeit, Aufmerksamkeit und das Vertrauen wert, die es verlangt? Das sind die echten Kosten eines Features – nicht Entwicklungsstunden, sondern drei knappe Ressourcen, die du dem Nutzer abverlangst. Die Anfängerfalle ist, etwas hinzuzufügen, weil man es kann („das dauert doch nur zwei Stunden“). Jede Ergänzung verwässert den Zweck. Den Zweck zu verteidigen heißt, oft Nein zu sagen. Der letzte Test: Zeig deinen Satz drei Leuten. Wenn sie nicht erraten, was die App tut, ist der Zweck nicht klar genug. „Visueller Planer für neurodivergente Gehirne.“ „Tägliche Weisheit in prähistorischem Grunzen, ohne Konto.“ Wenn dir das nicht gelingt, geh zurück in die Küche.

Am Steuer – und Fehler verzeihend

Das zweite Prinzip, Agency, bedeutet, Menschen auf ihre eigene Weise handeln zu lassen. Eine Oberfläche darf nie im Weg stehen. Lass Nutzer eintauchen, in ihrem Tempo erkunden, das Onboarding überspringen und die Oberfläche so ordnen, wie es ihnen liegt. Führe sie, aber zwinge sie nicht auf Schienen. Mehr Kontrolle führt zu mehr Engagement – das ist kein Slogan, sondern Mechanik.

Mein Beispiel ist Tiimo, 2025 zur iPhone App of the Year bei den App Store Awards gekürt und bereits 2024 Finalist eines Apple Design Awards. Der visuelle Planer gibt neurodivergenten Menschen mehr Kontrolle über ihre Zeit. Das Team sitzt in Kopenhagen, mehr als eine Million Menschen nutzen die App, und ein wichtiges Detail: Sie ist für immer zu 100 % werbefrei. Tiimo wurde mit Betroffenen gestaltet, nicht nur für sie. Genau das bedeutet Agency: nicht für andere zu entscheiden.

Die Konsequenz von Agency ist Verzeihlichkeit. Menschen senden, ändern und löschen ständig versehentlich Dinge. Deine Aufgabe ist, solche Handlungen rückgängig machen zu können. Apple bietet eine klare Hierarchie für riskante Aktionen. Undo zuerst und standardmäßig: Alles lässt sich rückgängig machen; Nutzer können etwas wagen und es sich anders überlegen. Confirm danach, nur wenn Rückgängigmachen unmöglich ist – etwa bei endgültigem Löschen oder unwiderruflichem Versand. Interrupt als allerletzte Maßnahme, um eine echte Katastrophe zu verhindern. Der typische Anfängerfehler ist, alles bestätigen zu lassen. Nach zu vielen „Bist du sicher?“-Dialogen klicken Nutzer ungelesen auf „Ja“, und die Warnung schützt niemanden mehr. Im Code solltest du drei Dinge kennen: UndoManager, confirmationDialog und die Rolle .destructive für sensible Buttons. Dieses Sicherheitsnetz bremst nicht – es gibt Nutzern Vertrauen, deine App zu erkunden und anzunehmen.

Im Interesse der Menschen – und verantwortungsvolle KI

Das dritte Prinzip, Responsibility, beginnt mit Privatsphäre. Apple hat eine Metapher, die ich liebe: Stell dir vor, ein Fremder spricht dich auf der Straße an und sagt „Gib mir deine Telefonnummer“, ohne zu erklären, warum. Du würdest ihm keine Sekunde vertrauen. Trotzdem tun Tausende Apps genau das: Sie werfen beim Start ein Berechtigungs-Popup auf dich, bevor du verstanden hast, wofür die App da ist. Eine verantwortungsvolle Oberfläche wartet auf den richtigen Moment, fragt nur nach dem Nötigsten und erklärt den Zweck.

Das perfekte Beispiel ist Be My Eyes, 2025 bei den App Store Awards in der Kategorie Cultural Impact ausgezeichnet. Die 2015 von Hans Jørgen Wiberg gegründete App – er selbst begann mit 25 Jahren sein Augenlicht zu verlieren – verbindet blinde und sehbehinderte Menschen mit sehenden Freiwilligen und inzwischen auch mit einer KI namens Be My AI. Das entscheidende Detail: Der Kamerazugriff wird erst dann angefragt, wenn der Nutzer visuelle Hilfe braucht – niemals beim Öffnen der App. Be My AI wurde gemeinsam mit Tausenden blinden und sehbehinderten Testern entwickelt. Die KI ergänzt den Menschen, sie ersetzt ihn nicht. So sollte es sein.

Und wir müssen über KI sprechen, denn 2026 ist sie überall. iOS 27 – auf dieser WWDC angekündigt, Tim Cooks letzte Keynote als CEO – bringt Siri, Apple Intelligence und Foundation Models auf dem Gerät in jeden Winkel des Systems. Diese Modelle laufen lokal, kostenlos und senden keine Daten nach außen. Das ist eine enorme Chance für Entwickler. Aber je mehr Intelligenz du einbaust, desto größer wird deine Verantwortung. Apples Beispiel ist absichtlich alltäglich: eine Rezept-App. Der Nutzer hat eine Allergie angegeben. Das Modell schlägt eigenständig ein Gericht mit dem Allergen vor. Das ist kein kosmetischer Fehler, sondern eine echte Gefahr. Ein Modell kann Unerwartetes, Falsches und Gefährliches ausgeben. Plane den schlimmsten Fall ein und baue Schutzmaßnahmen ein (Vorschau, Bestätigung, Hinweise) – oder streiche das Feature, wenn das Risiko den Nutzen übersteigt. Schutzmaßnahmen gehören von Anfang an ins Design, nicht als Patch nach einer Ablehnung.

Die Sprache der Plattform sprechen – Familiarity & Flexibility

Das vierte Prinzip ist Familiarity. Deine Nutzer bringen ein ganzes Leben an Erfahrung mit: mit der realen Welt und mit den Konventionen der anderen Apps, die sie verwenden. Nutze das. Ein Papierkorb bedeutet Löschen (und Wiederherstellen); gibst du dem Symbol eine andere Bedeutung, zerstörst du sofort die Wiedererkennung. Was gleich aussieht, sollte sich gleich verhalten. Auf dem Mac schließt man ein Fenster links oben – Nutzer müssen darüber nicht nachdenken. Erfinde für häufige Aktionen das Rad nicht neu: Nimm zuerst Systemkomponenten. Die Familiarity von 2026 heißt Liquid Glass: das auf der WWDC25 eingeführte Material, das inzwischen überall in iOS 26 steckt. Im Code sind das .glassEffect(), GlassEffectContainer und .buttonStyle(.glass). Eine Falle kann dich einen Abend kosten: Ein Vorfahr mit .clipped() oder .mask() zerstört den Effekt ohne Warnung. Nutze Systemkomponenten, bevor du überall eigenes Glass einsetzt. Apples Vorzeige-Apps dieses Jahr sind Moonlitt und Tide Guide.

Flexibility bedeutet, dass Menschen dein Design so individuell nutzen, wie sie selbst sind. Apple nimmt Musik als Beispiel: zu Hause über Lautsprecher, beim Laufen mit AirPods und Watch, im Auto freihändig – dieselbe App, drei Erlebnisse. Am greifbarsten wird Flexibilität 2026, wenn du über deinen Bildschirm hinausgehst. Über App Intents stellst du die Aktionen deiner App dem System bereit. Dann lebt sie in Siri, Spotlight, Kurzbefehlen, Widgets, Kontrollzentrum und Apple Intelligence – ohne, dass jemand die App öffnen muss. Das bringt Entdeckung und Bindung zugleich. Bei einer neuen App wählst du ein oder zwei Kernaktionen („Aufgabe hinzufügen“, „Timer starten“), gibst ihnen einen App Intent und verbindest sie über Assistant Schemas mit Apple Intelligence. John Geleynse nannte das schon zu iOS-5-Zeiten „Connected“: Deine App muss über ihr eigenes Fenster hinausreichen. 2026 heißt diese Idee App Intents.

Die richtigen Werkzeuge – Swift, SwiftUI, Xcode

Wir haben die Absicht, das Ziel und die Prinzipien. Jetzt kommen die Utensilien. Drei reichen für den Anfang, alle kostenlos. Kein React Native, kein Flutter, kein Backend am ersten Tag. Zuerst Swift: eine sichere Sprache – Optionals und strenge Typisierung verhindern ganze Fehlerklassen, bevor die App startet –, zugänglich und schnell. Du musst nicht alles sofort beherrschen. Generics, Actors und Concurrency kommen später. Lerne gerade genug, um loszulegen.

Dann SwiftUI: ein deklaratives Framework, in dem du beschreibst, was die Oberfläche tun soll, nicht wie sie gezeichnet wird. Weniger Code und dieselbe Grundlage für iPhone, iPad, Mac, Watch und Vision Pro. Der lebende Beweis ist Moonlitt – Gewinner des Apple Design Award 2026 für Interaction. Die italienische Agentur Flipping Hues (drei Entwickler, die sich an der Apple Developer Academy in Neapel kennenlernten) baute die App vollständig mit SwiftUI. Mondphasen, Foto-Planung, Onboarding mit wenigen Fingertipps und eine Liquid-Glass-Integration, die die Jury als „best-in-class“ lobte. Ein magisches Detail aus 2025/26: Kompilierst du mit dem iOS-26-SDK neu, übernimmt eine App Liquid Glass automatisch. Du musst nicht alles neu schreiben – aber prüfe das Ergebnis visuell, denn „automatisch“ heißt nicht „perfekt“.

Das dritte Werkzeug ist Xcode, die komplette Werkstatt: Editor, Simulator, Debugger, Tests und Distribution. SwiftUI und Previews verändern den Einstieg: Du siehst die Wirkung jeder Zeile sofort, ohne vollständigen Neuaufbau. Setze ein #Preview auf jede nicht triviale View. Und vor allem: Kochen lernt man nicht durch das Lesen von Rezepten. Apple bietet kostenlose geführte Tutorials an. Mach Scrumdinger vollständig durch – die Beispiel-App deckt Listen, Navigation, Persistenz und Barrierefreiheit ab. Eine fertige App bringt dir mehr bei als hundert Videos im Zeitraffer.

Das Fundament – Architektur & Daten

Ein Gericht ohne Struktur fällt auseinander. Bevor du dich um Craft kümmerst, leg ein solides Fundament. Eine App besteht aus drei Dingen, die miteinander sprechen: Views, Daten (die Wahrheit) und Navigation. Wenn du sie früh sauber ordnest, musst du in drei Monaten nicht alles neu schreiben. Die Anfängerfalle sind Daten, die sich von Bildschirm zu Bildschirm widersprechen. Die SwiftUI-Regel: eine einzige Quelle der Wahrheit (@State, @Observable, @Bindable) und Bindings, die alles andere synchron halten. Für die Speicherung zwischen App-Starts reicht SwiftData für eine erste Version meist völlig – dieselbe Idee wie SwiftUI, mehr Leistung und weniger Code als Core Data.

Und dann gibt es die Krankheit, die ich überall sehe: Du liest zehn Architektur-Abkürzungen (MVVM, TCA, VIPER … ~~und andere angsteinflößende Beschwörungen~~) und bist gelähmt, bevor du eine View geschrieben hast. Schluss damit. Halte es einfach, folge den Mustern der Plattform und refaktoriere erst, wenn tatsächlich ein Problem entsteht. Denk daran: grug besteht aus zwei Leuten ohne Architektur-Blog. Tiimo hat zehn Jahre iteriert, bevor es App of the Year wurde. Eine unvollkommene App, die existiert, ist besser als eine perfekte Architektur, die nie fertig wird.

Das Würzen – was gut von großartig trennt

Das Gericht ist fertig gegart. Jetzt kommen die Details – einzeln kaum sichtbar, zusammen aber spürbar. Das ist Craft: „die Liebe zum Detail, die Menschen zeigt, dass dir ihr Erlebnis wirklich wichtig ist“. Ein schlampiges Produkt fühlt man wie eine wackelige Tür oder ein Hemd, das sich auflöst. Ein träger Button, ruckelndes Scrollen, schief ausgerichtete Icons oder ein Layout, das bei Drehung kaputtgeht, wirkt fragil. Deshalb zweifelt man an der Qualität von allem anderen. Craft schafft Vertrauen. Seine „Materialien“ sind klare Typografie auf allen Bildschirmen, Farben für Hell- und Dunkelmodus, reaktionsschnelle Animationen, die dem Finger folgen, und zuverlässige SDKs. Mein Beispiel ist (Not Boring) Camera, Finalist des ADA 2026 in Visuals & Graphics. Die Handschrift des Studios ist seine Besessenheit von Materialien: 3D-Oberfläche, dynamisches Licht, Haptik und Sound sind so realistisch, dass du glaubst, eine analoge Kamera in der Hand zu halten.

Eine Cousine von Craft ist Simplicity – aber Vorsicht: Einfach bedeutet nicht minimalistisch. Alles an einem einzigen Ort zu verstecken ist minimal, aber nicht einfach. Einfach heißt reibungslos und intuitiv: Du findest, was du suchst, ohne Mühe. Das gelingt durch Kürze (klare Sprache, weniger Schritte) und Klarheit (starke Hierarchie aus Reihenfolge, Abstand und Kontrast, damit das Wichtigste am deutlichsten ist). Manchmal heißt Vereinfachen sogar, am richtigen Ort mehr Kontext hinzuzufügen – etwa die verbleibende Zeit auf einer Wiedergabe-/Pause-Taste. Das perfekte Beispiel ist Tide Guide, Gewinner des Apple Design Award 2026 für Visuals & Graphics vom US-Studio Condor Digital. Das Thema ist alltäglich – die Gezeiten –, die Umsetzung außergewöhnlich: Komplexe Stundendaten werden zu einer Grafik, die man auf einen Blick versteht, mit Farben, die sich im Laufe des Tages an die Himmelsfarbe anpassen. Alltägliches Thema, manische Sorgfalt. Darum geht es.

Zum Würzen gehört auch Barrierefreiheit – und ich sage es direkt: Sie ist kein Luxus. Sie bedeutet mehr Nutzer und eine bessere App für alle. VoiceOver, Dynamic Type, ausreichender Kontrast und Touch-Ziele von mindestens 44 × 44 Punkten. Be My Eyes und Tiimo machten Barrierefreiheit von Beginn an zu einem Grundpfeiler. Im Fernsehen gewann HBO Max nach der Einführung amerikanischer Gebärdensprache sogar den App-of-the-Year-Titel 2025 auf Apple TV. Seit iOS 26 gibt es außerdem Accessibility Nutrition Labels auf der App-Store-Seite: neun deklarierbare Funktionen (VoiceOver, Voice Control, Larger Text, Dark Interface, Differentiate Without Color, Sufficient Contrast, Reduced Motion, Captions, Audio Descriptions). Heute freiwillig, später verpflichtend – fang also früh an. Die goldene Regel: Sei ehrlich beim Audit. Alle üblichen Aufgaben müssen mit jeder angegebenen Funktion möglich sein. Sonst gib sie nicht an. Die WWDC25-Session „Evaluate your app for Accessibility Nutrition Labels“ zeigt die Methode.

Und wenn wir schon über Craft sprechen, reden wir über Performance, denn Apples Signal vom Juni 2026 ist eindeutig. iOS 27 wurde von der Presse sofort als „Snow Leopard“-Release bezeichnet – eine Anspielung auf das berühmte Zero New Features von 2009. Kein Feuerwerk, aber Apple veröffentlichte über vierzig echte Optimierungen: App-Starts bis zu 30 % schneller, Fotos erscheinen nach der Aufnahme 70 % schneller, AirDrop ist 80 % schneller, und ein neu geschriebener CPU-Scheduler hilft dem gesamten Gerätepark bis hin zum iPhone 11. Für dich heißt das: Eine App, die langsam wirkt, fällt im Vergleich noch stärker ab. Flüssige Animationen, schneller Start, kein Ruckeln beim Scrollen – teste auf echten Geräten, idealerweise einem iPhone 11 oder 12, nicht nur im Simulator des neuesten Modells. Craft heißt auch Dauerhaftigkeit: Wenn neue Funktionen oder Hardware erscheinen, entwickle dich mit ihnen weiter, damit Nutzer sich unterstützt fühlen. „Design is never really finished“ ist kein ~~Pinterest~~-Zitat, sondern die Realität jeder App of the Year.

Anrichten und servieren – testen & veröffentlichen

Ein großartiges Gericht serviert man nicht auf einem schmutzigen Teller. Vor dem App Store gibt es TestFlight: bis zu 100 interne Tester (Mitglieder deines App-Store-Connect-Teams) und 10.000 externe Tester über öffentlichen Link oder E-Mail. Der erste externe Build durchläuft eine Beta App Review – eine eigene Warteschlange, oft nur wenige Stunden, manchmal länger. Feedback, Screenshots und Abstürze erscheinen direkt in App Store Connect. Und ich wiederhole es, weil es kaum jemand tut: Teste auf echten Geräten. Der Simulator bildet weder Performance noch Batterie oder echte Berechtigungen nach.

Der zweite oft unterschätzte Punkt: Die App-Store-Seite gehört zur App. Icon, Screenshots, Beschreibung, Privacy Nutrition Label und Accessibility Nutrition Label müssen ehrlich zeigen, was die App tut. Apple sagt ausdrücklich: Irreführende Metadaten führen zur Ablehnung (Guideline 2.3). Screenshots müssen die echte App zeigen, keine erfundene Oberfläche und kein „Coming soon“. Lies die App Review Guidelines früh, nicht erst als letzte Hürde: fünf Bereiche (Safety, Performance, Business, Design, Legal). Wenn du In-App-Käufe einführst, lies den Bereich Business vor dem Programmieren, nicht danach. 2026 werden laut Apple etwa 90 % der Einreichungen in 24 Stunden geprüft – vor allem Updates etablierter Apps. Eine erste Einreichung dauert oft zwei bis fünf Tage (im September und Dezember länger, ebenso in regulierten Kategorien wie Gesundheit, Finanzen und Kinder). Behandle jede Ablehnung als konkrete technische Anforderung, nie als Urteil: Kopiere den Text in deine Notizen und arbeite die Punkte nacheinander ab.

Der Einstieg kostet 99 US-Dollar pro Jahr für das Apple Developer Program: TestFlight, App Store Connect, Zertifikate, Push-Mitteilungen und Sign in with Apple sind enthalten. (Zum Programmieren auf dem eigenen iPhone musst du nicht zahlen: Ein kostenloses Entwicklerkonto genügt, mit einem erneuerbaren 7-Tage-Zertifikat. Das kostenpflichtige Programm brauchst du erst für externe TestFlight-Tests und die Veröffentlichung.) In Xcode erstellst du ein Archiv, lädst es hoch und reichst es in App Store Connect ein. Du kannst einen stufenweisen Release aktivieren, der über sieben Tage ausgerollt wird. Dann ist dein Gericht in 175 Storefronts weltweit erhältlich. Denk früh an Lokalisierung – mindestens an Beschreibung und Screenshots für deine Zielmärkte.

Kunden erreichen – und das Gericht lebendig halten

Wir haben ein großartiges Gericht serviert. Doch ein Restaurant, das niemand findet, ist kein großartiges Restaurant. Jede Woche besuchen Hunderte Millionen Menschen den App Store – Sichtbarkeit muss man sich verdienen. Entdeckung bedeutet ASO plus Marketing, und jedes Element deiner App-Store-Seite beeinflusst Downloads. Für die Suche werden 30 Zeichen im Titel, 30 im Untertitel und 100 im Keyword-Feld indexiert: 160 Zeichen SEO-Fläche, die du sorgfältig nutzen solltest. Name und Icon prägen den ersten Eindruck; der erste Satz der Beschreibung wird am häufigsten gelesen, aber nicht indexiert – dafür ist das Keyword-Feld da. Wähle deine Kategorie mit Bedacht und stopfe den Titel nicht mit Suchbegriffen voll, sonst droht eine Ablehnung (Guideline 2.3).

Drei Möglichkeiten übersehen viele. Custom Product Pages: bis zu 70 Varianten deiner Produktseite, jeweils mit eigenen Screenshots, Werbetexten und einer eindeutigen URL (?ppid=…) für Kampagnen – eine Seite für Eltern, eine für Profis, eine für die Saison. Jede wird separat gemessen; seit iOS 18 können sie direkt zum passenden Bildschirm verlinken. Product Page Optimization: natives A/B-Testing in App Store Connect, das Icon-, Screenshot- oder App-Preview-Varianten einer zufälligen Stichprobe zeigt und mit 90 % Konfidenz einen Gewinner ermittelt (mindestens zwei Wochen messen). Dazu Campaign Links (Kanäle in App Analytics zuordnen), Apple Ads (Today-Tab und Suchergebnisse; ein kleines Budget reicht für Keyword-Tests) und Featuring Nominations (ein Formular in App Store Connect, um Apples Redaktion die App vorzuschlagen – erzähle die menschliche Geschichte; Be My Eyes und Tiimo sind gute Vorbilder). Starte mit ein oder zwei Custom Product Pages für deine größten Kanäle. Die Grenze von 70 ist kein Ziel.

Sobald die App online ist, beginnt die eigentliche Arbeit. Eine App ist nie „fertig“. Du hörst auf Feedback (TestFlight, App-Store-Bewertungen, Support-E-Mails), prüfst Abstürze im Xcode Organizer und veröffentlichst regelmäßig Updates. In App Analytics misst du alles: Umwandlung von Produktseite zu Download, Bindung am ersten, siebten und dreißigsten Tag, Sitzungen und die Leistung jeder Custom Product Page. Antworte auf Bewertungen – besonders auf negative und auf die ersten: Der Rezensent wird benachrichtigt und kann seine Bewertung anpassen. Tiimo brauchte zehn Jahre bis zum Titel. Be My Eyes iteriert seit 2015. grug wird von zwei Leuten seit 2012 weiterentwickelt. Keine dieser Apps kam perfekt auf den Markt. Sie haben iteriert.

Die geheime Zutat

Du hast eine geheime Zutat erwartet? Natürlich gibt es eine. Und sie ist weder Framework noch API oder WWDC-Session. Es ist Sorgfalt. Care. Die Absicht bei jedem Schritt, vom ersten Bildschirm bis zu dem Moment, in dem du dich traust, um eine Zahlung zu bitten. Im Grunde sind es Craft und Delight zusammen. Delight, das achte Prinzip, lässt sich schwer definieren, aber sofort erkennen – und ist nie Konfetti, das am Schluss aufgeklebt wird. Es ist die Summe aller Aufmerksamkeit im Produkt, das natürliche Ergebnis, wenn die anderen Prinzipien gut umgesetzt sind. Finde heraus, welches Gefühl du auslösen willst (entspannt, sicher, begeistert), und verstärke es überall. So wird aus „es funktioniert“ ein „ich liebe es“.

Meine vier Beispiele – grug, Be My Eyes, Tiimo und Moonlitt – haben keine Funktion gemeinsam. Ein prähistorischer Spruch, visuelle Hilfe, ein Zeitplaner und eine Mondphasen-App. Aber hinter allen stehen Menschen, denen es wirklich wichtig war. Am Ende zählt nur, wie gut deine App den Bedürfnissen der Menschen dient, für die du sie baust. Alles andere ist Technik. Und Technik kann man lernen.

Der beste Rat, den ich dir geben kann, passt in zwei Worte: Komm kochen. Öffne heute Xcode, nimm ein Apple-Tutorial und baue eine kleine App – ruhig simpel, ruhig hässlich. Eine App, die sich in einem Satz beschreiben lässt; eine TestFlight-Beta, die du drei Freunden schickst; eine ehrliche App-Store-Seite. Durchlaufe den ganzen Zyklus einmal. Ziele darauf, nicht auf Perfektion. Das sagen wir uns bei jedem Meetup der Community ⌘+F. Genau das unterscheidet die, die „bald anfangen“, von denen, die ausliefern.

Und wenn du ein außergewöhnliches Projekt hast, melde dich. Innovation ist das, wofür ich brenne.

Weiterlesen

Für Design: die Human Interface Guidelines (kostenlos, aktuell und seit der WWDC26 um eine Seite zu Design principles erweitert) sowie die Session Principles of great design. Für Code: Swift, SwiftUI, App Intents und Apple-Tutorials. Für Distribution: TestFlight, die App Review Guidelines und Custom Product Pages. Zur Inspiration: die Seiten zu den Apple Design Awards und den App Store Awards 2025 sowie die Produktseiten der genannten Apps, auf denen Junior-Entwickler die Arbeit aus der Nähe sehen können. Danke an Claire für die Hälfte dieses Rezepts. Jetzt bist du dran. 🍳