Eine Lovable-Alternative für iOS-Apps

Du hast eine App beschrieben, Lovable hat sie gebaut, und Leute nutzen sie im Browser. Jetzt willst du sie in den App Store bringen. Das ist eine andere Aufgabe, und Lovable sagt das selbst.

Die kurze Antwort

Lovable veröffentlicht Web-Apps. Für eine native iOS-App verpackst du die Web-App entweder in einen Wrapper, baust sie in React Native neu oder baust sie in SwiftUI neu. Rork, Bolt mit Expo, Xcode mit einem KI-Agenten und AirBuild gehen jeweils einen dieser Wege. Sie unterscheiden sich darin, was sie erzeugen, wer die App baut und einreicht und wer sich um App Review kümmert.

Was Lovable dir bietet und was nicht

Die Veröffentlichungsdokumentation von Lovable beantwortet die iOS-Frage direkt. Lovable baut Web-Apps, und Veröffentlichen stellt immer unter einer Web-URL bereit, entweder yourproject.lovable.app oder deiner eigenen Domain. Es gibt keinen eingebauten Ablauf, der dein Projekt verpackt und im App Store einreicht.

Dieselbe Seite nennt zwei Wege, näher ans Smartphone zu kommen:

• Eine Progressive Web App. Nutzer legen deine Website auf ihren Home-Bildschirm und öffnen sie im Vollbild. Eine PWA allein ist kein App-Store-Paket; um dort gelistet zu werden, müsste sie verpackt oder als native App neu gebaut werden.
• Ein Capacitor-Wrapper. Du verpackst die veröffentlichte URL außerhalb von Lovable in eine native Hülle und reichst diese Hülle selbst ein.

Lovable schreibt außerdem, dass es keine React-Native-Projekte erzeugt. Für eine React-Native-App schlägt es vor, die Bildschirme in Lovable als Prototyp zu entwerfen und sie dann außerhalb neu zu bauen. Und die mobile Lovable-App dient dazu, Projekte vom Smartphone aus zu bauen; sie macht aus deinem Projekt keine App für deine Nutzer.

Nichts davon ist ein Mangel. Es ist ein klarer Funktionsumfang. Die Frage ist, was du ergänzt, um in den App Store zu kommen.

Warum „einfach verpacken“ ein Glücksspiel ist

Apples App Store Review Guidelines legen in Abschnitt 4.2 eine Mindestanforderung fest:

Eine Hülle, die nur deine veröffentlichte URL lädt, kann an 4.2 scheitern. Die Prüfung achtet darauf, ob die App nützliche Funktionen, Inhalte und eine Oberfläche über die Website hinaus bietet, nicht auf die Technik im Inneren. Apple veröffentlicht keine Zulassungsquote für Wrapper, die Chancen lassen sich also nicht vorab abschätzen. Sicher ist nur: Eine Ablehnung kostet einen Prüfungszyklus. Wenn du verpacken willst, plane auch die nativen Funktionen ein und betrachte die Zulassung als etwas, das du dir verdienen musst, nicht als selbstverständlich. Unsere verständliche Erklärung der App Store Review Guidelines behandelt 4.2 und weitere Bereiche, die du vor dem Einreichen prüfen solltest.

Fünf Wege im Vergleich

Jeder Weg setzt eine Mitgliedschaft im Apple Developer Program voraus, bevor die App veröffentlicht werden kann.

1. Lovable behalten und einen Wrapper ergänzen

Das ist der kürzeste Weg von dem, was du schon hast. Capacitor beschreibt sich als plattformübergreifende native Laufzeitumgebung für Web-Apps: Dein Webcode läuft in einem nativen Container, mit Plugins für Gerätefunktionen.

Wähle ihn, wenn die Web-App das Produkt ist, du einen Entwickler hast, der ein natives Projekt pflegen kann, und du bereit bist, native Funktionen zu ergänzen, damit die App mehr ist als ihre Website.

Nachteile. Die Bildschirme bleiben HTML, das eine Browser-Engine darstellt. Das native Projekt, die Signierung, der Upload und die Prüfung liegen bei dir. Und das oben beschriebene Risiko bei 4.2 musst du selbst managen.

2. Rork

Rorks eigene FAQ beschreibt zwei Produkte. Rork Pro baut plattformübergreifende Apps mit React Native und Expo. Rork Max baut native SwiftUI-Apps, kompiliert mit Xcode auf echten Macs in der Cloud, für iPhone, iPad, Apple Watch und Vision Pro. Rork nennt eine eingebaute Veröffentlichung im App Store; du brauchst ein Apple-Developer-Konto, und Rork Pro braucht für den Build zusätzlich ein Expo-Konto. In kostenpflichtigen Tarifen kannst du den Code über eine Zwei-Wege-Synchronisierung mit GitHub exportieren. Rork bietet außerdem einen AI App Store Reviewer, der einen Build vor dem Einreichen auf Ablehnungsrisiken prüft.

Wähle ihn, wenn du eine neue mobile App aus einem Prompt starten willst und browserbasierte Builder magst, oder wenn du mit Rork Pro iPhone und Android aus einem Projekt willst.

Nachteile. Es ist ein neues Projekt, nicht deine übernommene Lovable-App. Die Tarife basieren auf Credits; die aktuellen Limits findest du auf Rorks Preisseite.

3. Bolt mit Expo

Laut Bolts Dokumentation nutzt Bolt Expo, wenn du nach einer mobilen App fragst, sodass die App mit demselben Code auf iPhone und Android läuft. Bolt rät, schon im allerersten Prompt „mobile App“ zu sagen, weil sich Projekte, die für das Web angelegt wurden, nicht leicht umstellen lassen. Die Vorschau siehst du mit Expo Go auf deinem Smartphone.

Die Veröffentlichung findet außerhalb von Bolts Editor statt. Die Dokumentation nennt die Voraussetzungen: einen Computer mit Node.js LTS und Git, ein Expo-Konto und ein Apple-Developer-Konto. Du lädst den Code herunter, installierst die EAS CLI und baust und reichst im Terminal ein.

Wähle ihn, wenn du beide Plattformen willst und ein paar Befehle im Terminal für dich kein Problem sind.

Nachteile. Ein bestehendes Bolt-Webprojekt wird nicht von selbst zu einem mobilen Projekt. Build, Store-Eintrag und App Review liegen bei dir. Wenn du schon eine Bolt-Web-App hast, kannst du sie zu AirBuild mitbringen.

4. Xcode mit einem KI-Coding-Agenten

Apples eigener Weg. In Xcode 27 kannst du Coding-Agenten und Modelle deiner Wahl nutzen, darunter die von Anthropic, Google und OpenAI, sowie jeden Agenten, der das Agent Client Protocol unterstützt. Apple verlangt außerdem, dass App-Store-Uploads mit Xcode 26 oder neuer gebaut werden; jede native iOS-App läuft also irgendwann durch Xcode.

Wähle ihn, wenn du programmieren kannst oder es lernen willst und die volle Kontrolle über das Projekt willst.

Nachteile. Xcode läuft auf dem Mac. Ein Agent schreibt Code; er meldet dich nicht beim Programm an, legt keinen Eintrag in App Store Connect an, schreibt keine Datenschutzangaben und antwortet nicht auf App Review. Unser Leitfaden zu App Store Connect führt durch diesen Teil. Wenn du diesen Weg gehst, helfen Agent Skills: Sieh dir unseren Leitfaden zu SwiftUI Agent Skills an.

5. AirBuild

AirBuild ist ein KI-Team für native iOS-Apps. Agenten für Produkt, Design und Entwicklung bauen die App in SwiftUI. Die App kommt über TestFlight auf dein iPhone, und Änderungen wünschst du dir in ganz normaler Sprache. Wenn sie fertig ist, bereitet AirBuild den App-Store-Eintrag vor, reicht ein, verfolgt die Prüfung, antwortet den Prüfern, behebt, was sie bemängeln, und reicht erneut ein.

Wenn du schon eine Lovable-App hast, kannst du sie zu AirBuild mitbringen:

1. Hinterlege den Link

   Die veröffentlichte Adresse deiner Lovable-App oder das GitHub-Repository, mit dem sie synchronisiert wird, und einen Satz dazu, was die iOS-App tun soll und für wen sie gedacht ist.

2. Dein KI-Team baut sie in SwiftUI neu

   Die Agenten lesen die Bildschirme und Abläufe deiner App und bauen daraus eine native iOS-App. Deine Web-App bleibt unangetastet, und du entwickelst sie weiter in Lovable. AirBuild kann deine Änderungen automatisch übernehmen.

3. Probiere sie auf deinem iPhone aus

   Die App kommt über TestFlight. Wünsch dir Änderungen in ganz normaler Sprache.

4. App Review

   AirBuild bereitet den Eintrag vor, reicht ein, antwortet den Prüfern, behebt, was sie bemängeln, und reicht erneut ein.

Dein Backend bleibt, wo es ist. Sag AirBuild, womit die App kommuniziert, ob Lovable Cloud, ein eigenes Supabase-Projekt oder eine API, und die iOS-App wird darauf ausgerichtet. Du brauchst weder einen Mac noch Xcode: AirBuild lässt dein KI-Team auf einem Mac oder in der Cloud arbeiten. Für die Veröffentlichung brauchst du allerdings eine Mitgliedschaft im Apple Developer Program. Der Code gehört dir: Dein Lovable-Code bleibt deiner, und das gilt auch für das SwiftUI-Projekt, das AirBuild daraus baut.

Wähle es, wenn du eine native iPhone-App willst und App Review für dich erledigt werden soll, statt wieder bei dir zu landen.

Nachteile. AirBuild konzentriert sich auf natives iOS und ist daher nicht der Weg für eine Android-App. Das Mitbringen eines Projekts aus Lovable befindet sich im Early Access, per Einladung von der Warteliste.

So triffst du die Wahl

Fang beim Ergebnis an, nicht beim Tool. Mit Vibe Coding bekommst du in jedem dieser Tools schnell einen funktionierenden Prototyp einer iOS-App; über den Weg entscheidet, was du am Ende brauchst.

Stell dem Tool deiner Wahl dann drei Fragen:

• Kann ich den Code mitnehmen? Prüfe, ob der Export in jedem Tarif oder nur in kostenpflichtigen enthalten ist.
• Wer reicht ein, und wer antwortet auf App Review? Ein Tool, das beim Build aufhört, überlässt dir den Eintrag, die Datenschutzangaben und die Ablehnungen.
• Wo liegen meine Daten? Wenn deine Lovable-App schon Lovable Cloud oder Supabase nutzt, nimm lieber einen Weg, der die Daten dort lässt.

Einen breiteren Überblick über die Kategorie findest du unter KI-App-Builder für iOS. Den ganzen Weg von der Idee bis zur Zulassung beschreibt So erstellst du eine App mit KI.

Häufige Fragen

Kann Lovable eine native iOS-App bauen?

Nein. Laut der Dokumentation von Lovable baut es Web-Apps, und Veröffentlichen stellt immer unter einer Web-URL bereit. Sie schlägt eine Progressive Web App oder einen Capacitor-Wrapper um die veröffentlichte URL vor, und Lovable erzeugt keine React-Native-Projekte.

Was ist die beste Lovable-Alternative für eine iOS-App?

Das hängt davon ab, was am Ende herauskommen soll. Für iPhone und Android aus einer Codebasis schau dir Tools auf Basis von React Native und Expo an, etwa Rork Pro oder Bolt mit Expo. Für eine native SwiftUI-App schau dir Rork Max, Xcode mit einem Coding-Agenten oder AirBuild an.

Akzeptiert Apple eine Lovable-App in einem Wrapper?

Das hängt von der App ab. Richtlinie 4.2 verlangt Funktionen, Inhalte und eine Oberfläche, die eine App über eine neu verpackte Website hinausheben. Eine Hülle, die nur deine veröffentlichte URL lädt, hat nach dieser Regel ein hohes Risiko. Apple veröffentlicht keine Zulassungsquote für Wrapper, und native Funktionen hinzuzufügen garantiert keine Zulassung.

Brauche ich einen Mac, um eine iOS-App per Vibe Coding zu bauen?

Nicht immer. Xcode läuft auf dem Mac, der Weg über Xcode braucht also einen. Rork Max baut auf Macs in der Cloud, und AirBuild lässt dein KI-Team auf einem Mac oder in der Cloud arbeiten. Für die Veröffentlichung brauchst du auf jedem Weg eine Mitgliedschaft im Apple Developer Program.

Kann ich meine Lovable-Web-App behalten, wenn ich eine iOS-Version baue?

Ja. Keiner dieser Wege verlangt, dass du die Web-App abschaltest. Mit AirBuild bleibt die Web-App, wo sie ist, und du bearbeitest sie weiter in Lovable.