So erstellst du eine App mit KI

Du hast eine Idee für eine App und kein Entwicklerteam. KI-Tools können inzwischen den Großteil des Codes schreiben, ausführen und korrigieren. Dieser Leitfaden deckt den ganzen Weg ab, vom ersten Satz deiner Idee bis zu einer App, die man herunterladen kann.

Die neun Schritte

Schreib ein Briefing. Entscheide, welche Art von App du brauchst. Wähle ein Tool. Melde dich beim Apple Developer Program an. Bau eine erste Version. Teste sie mit TestFlight auf einem echten iPhone (oder iPad). Bereite den Eintrag und die Datenschutzangaben vor. Reiche ein. Kümmere dich um die Prüfung und verbessere die App weiter.

1. Schreib das Briefing, bevor du ein Tool öffnest

KI baut, was du beschreibst. Ein vager Prompt ergibt eine vage App. Bevor du irgendetwas in einen Builder tippst, schreib einen Absatz, der vier Fragen beantwortet:

• Für wen ist sie? „Läufer, die für ihren ersten Halbmarathon trainieren“, nicht „alle“.
• Welches Problem löst sie? Ein Satz.
• Was kann die erste Version? Drei bis fünf Dinge. Nicht alles.
• Was braucht sie? Konten, eine Datenbank, Zahlungen, Mitteilungen, die Kamera, den Standort.

Heb diesen Absatz auf. Du fügst ihn in das Tool ein, verwendest ihn für die App-Store-Beschreibung wieder und prüfst die fertige App daran.

2. Entscheide, welche Art von App du brauchst

Es gibt drei Arten von Ergebnis, und die Wahl prägt alles, was danach kommt.

Wenn der App Store das Ziel ist, plane keine Website in einer dünnen Hülle. Apples Richtlinie 4.2 verlangt Apps, die „über eine neu verpackte Website hinausgehen“; ein einfacher Wrapper riskiert also eine Ablehnung. Die Prüfung achtet auf Funktionen, Inhalte und Oberfläche, und kein Wrapper kommt garantiert durch.

3. Wähle ein Tool, das weit genug geht

Die meisten KI-Tools schreiben guten Code. Sie unterscheiden sich darin, wie viel vom Rest sie übernehmen. Frag jedes:

• Was erzeugt es: Web, React Native oder SwiftUI?
• Kann ich den Code exportieren?
• Baut es die App und reicht sie ein, oder gibt es mir ein Projekt?
• Hilft es, wenn App Review die App ablehnt?

Wenn du programmieren kannst, unterstützt Xcode inzwischen selbst Coding-Agenten und Modelle deiner Wahl, darunter die von Anthropic, Google und OpenAI. Wenn nicht, übernimmt ein KI-App-Builder das Programmieren und, je nach Tool, mehr. Unser Leitfaden zu KI-App-Buildern für iOS vergleicht die Optionen. Wenn du schon etwas in Lovable gebaut hast, sieh dir Lovable-Alternativen für iOS-Apps an.

4. Melde dich früh beim Apple Developer Program an

Für die Veröffentlichung im App Store und für Einladungen an externe TestFlight-Tester brauchst du eine kostenpflichtige Mitgliedschaft. Sie kostet 99 USD pro Mitgliedsjahr oder den lokalen Preis, wo verfügbar.

Fang jetzt an, nicht erst am Tag der Veröffentlichung. Du wählst zwischen einem Konto für Einzelpersonen und einem für Organisationen, und Organisationen brauchen eine D‑U‑N‑S-Nummer, was Tage dauern kann. Unser Leitfaden zum Apple-Developer-Konto erklärt jeden Schritt.

5. Bau die erste Version und grenz sie dann ein

Füg dein Briefing in das Tool ein und lass es bauen. Arbeite dann mit kleinen, konkreten Anfragen:

1. Prüfe zuerst den Hauptablauf

   Kann jemand das eine, wofür die App da ist, von Anfang bis Ende erledigen? Behebe das vor allem anderen.

2. Ändere eine Sache pro Nachricht

   „Verschieb den Hinzufügen-Button nach oben rechts“ funktioniert besser als eine Liste mit zehn Änderungen.

3. Beschränk die erste Version auf vollständige, testbare Abläufe

   Begrenze den Umfang auf das, was das Briefing verspricht, und sorg dafür, dass jeder dieser Abläufe vollständig funktioniert. Eine fertige kleine App lässt sich leichter testen als eine große mit Lücken.

4. Füge Anmeldung und Daten bewusst hinzu

   Wenn man ein Konto anlegen kann, verlangt Apple eine Möglichkeit, es in der App zu löschen (Richtlinie 5.1.1(v)).

Bei Pace Log umfasst die erste Version die drei Dinge aus dem Briefing. Die erste Prüfung gilt dem Hauptablauf: einen Lauf erfassen und sehen, wie sich die Wochensumme ändert. Eine Änderungsnachricht könnte lauten: „Zeig auf dem Wochenbildschirm unter der Summe die verbleibende Distanz bis zum Ziel an.“ Eine Nachricht, eine Änderung. Wenn das Tool einen Social Feed ergänzt, um den niemand gebeten hat, entferne ihn; er steht nicht im Briefing.

6. Teste mit TestFlight auf einem echten iPhone (oder iPad)

Eine Vorschau im Browser oder Simulator ist nicht dasselbe wie die App auf einem Smartphone. TestFlight ist Apples Beta-Dienst: Du lädst einen Build hoch, lädst Tester ein, und sie installieren ihn mit der TestFlight-App.

• Interne Tester: bis zu 100 Personen aus deinem App-Store-Connect-Team.
• Externe Tester: bis zu 10,000 Personen per E-Mail oder öffentlichem Link. Der erste Build, den du einer Gruppe hinzufügst, geht an App Review; spätere Builds brauchen womöglich keine vollständige Prüfung.
• Jeder Build ist 90 Tage gültig. Danach können Tester ihn nicht mehr öffnen.

Bitte die Tester, den Hauptablauf auf ihren eigenen Geräten mit ihren eigenen Daten auszuprobieren. Bei Pace Log ist der Test einfach: Jeder Tester erfasst über eine Woche drei Läufe, und Wochensumme und verbleibende Distanz müssen mit den eigenen Summen übereinstimmen. Unser TestFlight-Leitfaden führt durch Einladungen, Installation und häufige Probleme.

7. Bereite den Eintrag und die Datenschutzangaben vor

In App Store Connect liegt die Store-Seite. Bevor du einreichen kannst, brauchst du:

• Einen App-Eintrag mit einem Namen (höchstens 30 Zeichen), einer Bundle ID und einer SKU.
• Eine Beschreibung, Keywords und eine Support-URL.
• Screenshots, die die App in Benutzung zeigen, nicht nur einen Start- oder Anmeldebildschirm (Richtlinie 2.3.3).
• Eine URL zur Datenschutzrichtlinie, verlinkt in App Store Connect und in der App (Richtlinie 5.1.1(i)).
• App-Privacy-Angaben, die dem entsprechen, was die App und ihre Drittanbieter-SDKs tatsächlich erfassen.
• Hinweise für die Prüfung und ein funktionierendes Demokonto, wenn die App eine Anmeldung hat.

Wenn deine App personenbezogene Daten an einen KI-Dienst eines Drittanbieters sendet, verlangt Richtlinie 5.1.2(i), dass du das offenlegst und vorher eine ausdrückliche Erlaubnis einholst. Das betrifft viele Apps, die um eine KI-Funktion herum gebaut sind.

Unser Leitfaden zu App Store Connect behandelt jedes Feld. Für Screenshots kann dir der App Store Screenshots Skill beim Gestalten und Exportieren helfen.

8. Reiche zur Prüfung ein

Wähle in App Store Connect auf der Versionsseite den Build aus und klicke auf Add for Review. Damit landet er nur in einem Entwurf. Öffne dann die Entwurfseinreichung und klicke auf Submit for Review. Erst dann ist die App in der Warteschlange.

Laut Apple prüft App Review in der Regel 50 % der Einreichungen in weniger als 24 Stunden und 90 % in weniger als 48 Stunden. Apple sagt auch, dass sich mehr als 40 % der ungelösten Probleme auf Richtlinie 2.1, App-Vollständigkeit, beziehen: Abstürze, Platzhalterinhalte und unvollständige Informationen. Teste noch einmal, bevor du auf den Button klickst.

9. Kümmere dich um die Prüfung und mach weiter

Wird die App abgelehnt, nennt die Nachricht in App Store Connect die Richtlinie. Lies sie, behebe, was sie beschreibt, und antworte oder reiche erneut ein. Wenn du glaubst, dass der Prüfer die App missverstanden hat, antworte zuerst mit konkreten Angaben; ein Einspruch beim App Review Board kommt erst danach. Unser Beitrag App Store Review Guidelines einfach erklärt behandelt fünf Bereiche, die du vor dem Einreichen prüfen solltest, und wie du auf eine Ablehnung reagierst.

Nach der Zulassung geht die Arbeit weiter: Lies Bewertungen, behalte Abstürze und Bindung im Blick und veröffentliche Updates als neue Versionen desselben App-Eintrags.

Wo AirBuild hineinpasst

AirBuild deckt die Schritte 5 bis 9 mit einem KI-Team ab. Agenten für Produkt, Design und Entwicklung bauen aus deinem Briefing eine native iOS-App. Builds kommen über TestFlight auf dein iPhone, und Änderungen wünschst du dir in ganz normaler Sprache. Wenn die App fertig ist, bereitet AirBuild den App-Store-Eintrag, die Screenshots und die Hinweise für die Prüfung vor, reicht ein, verfolgt die Prüfung, antwortet auf Feedback, behebt Probleme und reicht erneut ein.

Du musst nicht programmieren können und brauchst keinen Mac: Das Team arbeitet auf deinem Mac oder in der Cloud, und du kannst die Arbeit auf deinem iPhone prüfen. Du brauchst allerdings deine eigene Mitgliedschaft im Apple Developer Program. Die App-Review-Automatisierung ist in den Tarifen Basic, Plus und Ultra enthalten; siehe Preise. AirBuild befindet sich im Early Access, per Einladung von der Warteliste.

Häufige Fragen

Kann ich mit KI eine App erstellen, wenn ich nicht programmieren kann?

Ja. Mehrere KI-App-Builder arbeiten mit einer Beschreibung in normaler Sprache. Du triffst trotzdem die Produktentscheidungen, testest die App auf einem echten iPhone (oder iPad) und bist Inhaber des Apple-Developer-Kontos, unter dem die App veröffentlicht wird.

Wie lange dauert es, mit KI eine App zu erstellen?

Die erste funktionierende Version kann in Stunden fertig sein. Tests, Store-Eintrag und Prüfung kommen hinzu. Laut Apple werden in der Regel 50 % der Einreichungen in weniger als 24 Stunden und 90 % in weniger als 48 Stunden geprüft, aber eine Ablehnung bedeutet einen weiteren Zyklus.

Was kostet es, eine mit KI erstellte App zu veröffentlichen?

Das Apple Developer Program kostet 99 USD pro Mitgliedsjahr oder den lokalen Preis, wo verfügbar. Hinzu kommen die Kosten für das KI-Tool und für Backend oder Dienste, die deine App nutzt.

Brauche ich einen Mac, um mit KI eine iPhone-App zu erstellen?

Apps, die in App Store Connect hochgeladen werden, müssen mit Xcode 26 oder neuer gebaut werden, und Xcode läuft auf dem Mac. Manche KI-Builder übernehmen diesen Build für dich auf Macs in der Cloud, sodass du selbst keinen brauchst.

Lehnt Apple eine App ab, weil sie mit KI erstellt wurde?

Wir haben in den Richtlinien keine Regel dazu gefunden, wie der Code geschrieben wird; sie stellen Regeln für die App selbst auf. Häufige Ablehnungsgründe sind Abstürze und Platzhalterinhalte, fehlende Datenschutzangaben, Apps, die kaum mehr bieten als eine neu verpackte Website (ein Risiko nach Richtlinie 4.2), und Kopien von Apps, die es im Store schon gibt.