Mit Vibe Coding eine App im App Store veröffentlichen: die LevelUpStudy-Erfahrung

„Vibe Coding" ist der Begriff des Jahres: Statt jede Zeile selbst zu tippen, beschreibst du, was du willst, das Modell schreibt es, und du beurteilst das Ergebnis. Die naheliegende Frage lautet, ob dabei eine App herauskommt, die tatsächlich im App Store erscheint.

Sie kommt heraus. LevelUpStudy ist genau so entstanden: SwiftUI-Oberfläche, ein mit SceneKit erzeugter 3D-Schreibtisch, eine PHP-+-MySQL-API, Firebase-Authentifizierung und eine veröffentlichte Version im App Store. Hinter dem Satz „sag es einfach der KI" steckt allerdings eine Menge Detailarbeit. Dieser Artikel beschreibt die Methode, die funktioniert hat, drei konkrete Wände, gegen die ich gelaufen bin, und was ich allen mitgeben würde, die denselben Weg gehen.

Was Vibe Coding nicht ist

Zuerst die Erwartungen sortieren. Vibe Coding:

• Trifft keine Architekturentscheidungen für dich. Fragst du das Modell, wo Daten liegen sollen, wem zu trauen ist oder wann ein „Tag" endet, klingt die Antwort plausibel — und bleibt über die Codebasis hinweg widersprüchlich.
• Prüft sich nicht selbst. Das Modell weist dich nicht auf Duplikate, tote Funktionen oder stille Brüche in seinem eigenen Code hin. Wer nicht fragt, sieht sie nicht.
• Trifft keine Produktentscheidungen. „Sollen Pausenminuten Punkte bringen?" ist eine Produktfrage; technisch lassen sich beide Antworten umsetzen.

Was Vibe Coding wirklich beschleunigt, ist die Umsetzung nach der Entscheidung: Screens bauen, Modelle definieren, Endpunkte schreiben, Tests erweitern, refaktorieren. Das ist der Großteil der Arbeit in jeder App — der Gewinn ist also real.

Was LevelUpStudy ist

In einem Satz: eine soziale App, die misst, wie lange jemand wirklich lernt, diese Minuten in Punkte verwandelt und die Punkte in einen 3D-Schreibtisch fließen lässt. In Zahlen:

• 94 Swift-Dateien, komplett SwiftUI
• Eine 3D-Schreibtischszene, im Code aus Geometrie erzeugt — keine importierten Modelldateien
• Eine eigene PHP-API und ein eigenes MySQL-Schema; Firebase nur für Anmeldung, Benachrichtigungen, Analyse und Absturzberichte
• 39 Unit-Tests für reine Logik und 24 Integrationstests gegen eine echte Datenbank
• 12 Prüfungsarten und 40 Erfolgsabzeichen

Diese App habe ich allein an Abenden veröffentlicht. So bin ich vorgegangen.

Die Methode: erst Dokumente, dann Code

Die Gewohnheit mit dem größten Effekt war, Entscheidungen vor dem Code aufzuschreiben. Im Projekt liegen zwei Dokumente:

• ARCHITECTURE.md — wie das System funktioniert, wo die Vertrauensgrenze liegt, welcher Wert woher kommt.
• NEW_VERSION.md — die Phasen der nächsten Version: welche Datei, welche Spalte, welcher Endpunkt.

Diese Dokumente sind zugleich ein Vertrag für die KI. Statt „schreib den Endpunkt zum Abschließen einer Session" kannst du sagen: „schreib den Abschluss gemäß der Vertrauensgrenze — die Dauer ist die Differenz zweier Server-Zeitstempel, der vom Client gemeldete Wert dient nur als Obergrenze". Die Wahrscheinlichkeit für korrekten Code steigt dadurch erheblich.

Die wichtigste Regel der App stammt aus genau diesem Dokument:

Kein Wert, der die Spielökonomie bestimmt, kommt jemals vom Client.

In der Praxis:

Dauer = min(Server-Differenz, geplante Dauer, vom Client gemeldete Dauer)

Ein Client kann nicht behaupten, „ich habe drei Stunden gelernt"; er kann nur melden, dass er früher aufgehört hat. Diese eine Zeile hält die Bestenliste aussagekräftig.

Wand 1: eine Zeitzone, die allen die Serie zerstörte

In der ersten Architektur setzte ein nächtlicher Job die Serie aller zurück, die „gestern" nicht gelernt hatten. Der Job lief um 00:00 Istanbuler Zeit, der Server aber in UTC — der Tag, den der Server „gestern" nannte, lag für die Nutzer zwei Tage zurück. Jeden Morgen war die Serie fleißiger Nutzer gerissen.

Diesen Fehler hat nicht die KI erfunden: Er entstand, weil ich nie definiert hatte, was ein „Tag" ist. Die Lösung war eine Definition an genau einer Stelle: Ein Tag ist immer Europe/Istanbul. Auf dem Client AppConfig.appTimeZone, auf dem Server Domain\Time. Calendar.current, date('Y-m-d') und new Date().setHours(0,0,0,0) sind im Projekt verboten — alle drei hängen von der lokalen Uhr der ausführenden Maschine ab.

Lehre: Wer „korrekten" Code vom Modell will, muss zuerst aufschreiben, was korrekt bedeutet.

Wand 2: 800 Zeilen toter Code

Die Datei, die die 3D-Objekte baut, war auf 2.615 Zeilen angewachsen. Beim Lesen fand ich acht Funktionen, die doppelt definiert waren: die alten Versionen ohne Parameter, die neuen mit itemName — und aufgerufen wurde ausschließlich der neue Satz. Der Rest eines halb fertigen Refactorings: rund 800 Zeilen, die von nirgendwo erreichbar waren.

Das ist der typischste Nebeneffekt von Vibe Coding. Statt eine Funktion zu ändern, schreibt das Modell eine neue, die alte bleibt liegen. Swift warnt bei einer nicht aufgerufenen private-Funktion nicht, also schweigt auch der Compiler.

Lehre: Frage regelmäßig „gibt es in dieser Datei unerreichbaren Code?". Prüfe vor dem Löschen jede Aufrufstelle noch einmal mit grep; ein erfolgreicher Build allein ist kein Beweis.

Wand 3: Zuordnung über Anzeigenamen

Das 3D-Modell eines Objekts wurde anhand seines türkischen Anzeigenamens ausgewählt:

if itemName.contains("Kalem Kutusu") { ... }
else if itemName.contains("Kalem") { ... }   // reihenfolgeabhängig!

Es funktionierte — und hatte drei Probleme: Ein neu in die Datenbank eingetragenes Objekt erschien in der App als graue Kiste (jedes neue Objekt bedeutete also ein App-Update), ein umbenanntes Objekt verlor still sein Modell, und mit der ersten englischen Übersetzung wäre die gesamte Zuordnung zusammengebrochen.

Die Lösung: Zuordnung weg vom Anzeigenamen, hin zu einem stabilen Schlüssel — eine Spalte model_key in shop_items und ein switch modelKey auf dem Client. Katalogexperimente wie Preis, Level-Sperre oder saisonale Objekte laufen jetzt allein über den Server.

Lehre: Die KI bringt das Gewünschte auf dem kürzesten Weg zum Laufen. Nach dem Unterschied zwischen „funktioniert" und „wartbar" musst du selbst fragen.

Der Weg in den App Store

Mit dem Code ist die Arbeit nicht zu Ende. Auf der Veröffentlichungsseite kostete Zeit:

1. Screenshots. Die Größen für 6,5"-iPhone und iPad sind Pflicht. Die rohen Simulator-Aufnahmen mit einer kurzen Überschrift zu versehen, wirkt sich spürbar auf die Conversion aus.
2. Datenschutzangaben. In App Store Connect erklärst du Punkt für Punkt, was erhoben wird und ob es mit der Identität verknüpft ist. Das muss dem tatsächlichen Verhalten entsprechen; eine Abweichung ist ein Ablehnungsgrund.
3. Datenschutzerklärung und Support-URL. Beides müssen erreichbare Adressen sein. Deshalb liegen die Datenschutzerklärung und die Support-Seite von LevelUpStudy auf meiner eigenen Website: Eine dauerhafte Adresse wirkt sowohl im Review als auch für Nutzer deutlich vertrauenswürdiger als ein geteilter Dokumentenlink.
4. Altersfreigabe. Wegen sozialer Funktionen und nutzergenerierter Inhalte liegt die App bei 13+.
5. Kontolöschung. Eine App, die Konten anlegt, muss deren Löschung in der App anbieten. Plane das von Anfang an ein, statt es nachzurüsten.

Die meisten Review-Probleme entstehen daraus, dass diese Punkte nicht zur App passen. Der Code selbst ist selten das Problem.

Checkliste für denselben Weg

• Triff Architekturentscheidungen selbst, schreib sie auf und gib dem Modell dieses Dokument.
• Halte Aufgaben klein: nicht „bau den Session-Ablauf", sondern „schreib den Abschluss-Endpunkt in einer Transaktion, sodass dieselbe Session nie zweimal abgeschlossen werden kann".
• Sichere die Korrektheit von Geld, Punkten, Dauer und Identität mit Tests ab. Genau diese wenigen Tests verhindern, dass das Modell beim nächsten Umbau dieselbe Stelle zerlegt.
• Frage nach jeder Phase: unerreichbarer Code, doppelte Funktionen, magische Strings?
• Schreib die Veröffentlichungsanforderungen — Datenschutz, Support-URL, Kontolöschung, Screenshot-Größen — an den Anfang der Entwicklung, nicht ans Ende.

Entwicklung mit KI macht gute Entwicklerinnen und Entwickler nicht überflüssig. Sie verändert, wie viel eine gute Person liefern kann. Entscheidungen treffen, Grenzen setzen und das Ergebnis prüfen muss weiterhin ein Mensch — nämlich du.

Häufig gestellte Fragen

Kann man mit Vibe Coding wirklich eine App von Grund auf veröffentlichen?

Ja. LevelUpStudy ist ein Beispiel: SwiftUI-Oberfläche, 3D-Szene, eigene API und Tests, live im App Store. Architekturentscheidungen, Sicherheitsgrenzen und Produktfragen müssen jedoch von einem Menschen kommen; das Modell beschleunigt deren Umsetzung.

Wie prüft man die Qualität von KI-geschriebenem Code?

Achte auf drei Dinge: unerreichbaren oder doppelten Code, Zuordnungen über magische Strings und die Testabdeckung kritischer Berechnungen. Werte wie Dauer, Punkte und Identität in reine, durch Tests abgesicherte Funktionen zu ziehen, zahlt sich am stärksten aus.

Woran scheitern Apps im App-Store-Review am häufigsten?

Weit häufiger als am Code an widersprüchlichen Angaben: Datenschutzangaben, die nicht zum tatsächlichen Verhalten passen, eine nicht erreichbare Datenschutzerklärung oder Support-Seite, oder eine kontobasierte App ohne Löschmöglichkeit in der App.

Firebase oder eigener Server?

Beides zusammen ist möglich. Bei LevelUpStudy laufen Anmeldung, Benachrichtigungen, Analyse und Absturzberichte über Firebase, während Daten, Spielökonomie und geplante Jobs auf meiner eigenen PHP-+-MySQL-API liegen. So bleibe ich in den kostenlosen Kontingenten und kann Aggregationen wie Bestenlisten in einer einzigen SQL-Abfrage berechnen.

Wie lange hat die Veröffentlichung gedauert?

Von der Idee bis zur ersten App-Store-Version einige Monate, jeweils abends. Verlängert hat den Zeitraum nicht das Programmieren, sondern die Release-Vorbereitung: Screenshots, Datenschutzangaben, der Löschablauf für Konten und die Review-Schleife.