iOS App erstellen 2026: was du wirklich brauchst — und die vier Wege dahin

Einen Mac. Native iOS-Apps werden in Xcode gebaut, und Xcode läuft nur auf macOS. Das ist keine Werkzeug-Entscheidung, sondern Apples Regel. Ein gebrauchter Mac mini oder ein MacBook Air reicht; wichtig ist, dass er die aktuelle macOS-Version fährt, weil Xcode sie voraussetzt. Was der Satz „iOS App erstellen ohne Mac“ wirklich bedeutet, klären wir weiter unten ehrlich.

Xcode. Kostenlos im Mac App Store. Darin stecken der Compiler, der iPhone-Simulator, die Vorschau für SwiftUI-Oberflächen und der Upload in den App Store. Rechne mit einer großen Installation und plane Speicherplatz ein.

Ein Apple-Konto — und zum Veröffentlichen das Apple Developer Program. Zum Bauen, im Simulator testen und auf dem eigenen iPhone ausführen reicht ein normales Apple-Konto. Sobald die App zu anderen Menschen soll — TestFlight oder App Store — brauchst du die Mitgliedschaft im Apple Developer Program: laut Apple „99 USD per membership year“. Zwei Dinge, an denen Einzelpersonen scheitern: Die Zwei-Faktor-Authentifizierung muss aktiv sein, und der Name muss dein rechtlicher Name sein — Apple schreibt ausdrücklich, kein Alias, kein Spitzname, kein Firmenname im Namensfeld. Für Firmen kommt eine D-U-N-S-Nummer dazu, und die dauert; die komplette Anmeldung mit allen Wartezeiten steht in unserem Leitfaden zum Apple-Entwicklerkonto (auf Englisch).

Ein iPhone zum Testen — optional, aber ehrlich gesagt nötig. Der Simulator ist höflich; ein echter Daumen auf einem echten Display ist ehrlich. Ein älteres Gerät reicht.

Eine Beschreibung der App. Das ist der Punkt, den alle Checklisten weglassen und der am meisten entscheidet: Was tut die App, für wen, und welche drei Dinge macht ein Nutzer darin? Fünf Sätze. Jeder der vier Wege unten verbraucht genau dieses Dokument — die Agentur als Lastenheft, der Baukasten als Vorlagenwahl, du selbst als Bauplan, der KI-Agent als Prompt.

Der klassische Weg: du beschreibst, ein Team baut. Für iOS heißt das im besten Fall natives Swift mit SwiftUI — Apples eigener Stack — und im schlechteren Fall ein Cross-Platform-Projekt, bei dem das iPhone die Version „für beide“ bekommt.

Was es kostet, hängt so stark von Umfang und Anbieter ab, dass jede Pauschalzahl gelogen wäre — deshalb steht hier keine. Wie du ein Angebot prüfst (Lastenheft, Code-Eigentum, wer das Apple-Konto besitzt, Wartung nach der Übergabe), steht in App entwickeln lassen. Ein Punkt ist iOS-spezifisch und wird oft vergessen: Das Apple-Entwicklerkonto sollte auf dich laufen, nicht auf die Agentur. Wer das Konto besitzt, besitzt den App-Store-Eintrag, die Bewertungen und die Nutzer.

Für wen richtig: Budget vorhanden, keine Zeit oder Lust auf Eigenbau, komplexes Projekt mit langem Horizont. Der Haken: jede Änderung nach der Übergabe kostet wieder Geld — und du bist im Änderungs-Takt deines Dienstleisters gefangen.

Baukästen versprechen die App ohne Code, per Drag-and-drop. Für iOS gilt eine Regel, die auf keiner Startseite steht: Prüfe, ob der Tarif eine echte App-Store-App liefert oder eine Web-App. Viele günstige Tarife liefern eine PWA — eine Website, die sich auf den Homescreen legen lässt. Das ist für eine Speisekarte in Ordnung und für alles, was Push-Benachrichtigungen, Kamera, Offline-Nutzung oder Käufe über den App Store braucht, nicht. Und der zweite Punkt: Apple prüft jede eingereichte App, und dünne Hüllen um eine Website werden regelmäßig abgelehnt — die App muss mehr können als der Browser.

Welcher Baukasten in welchem Tarif was liefert, mit Quelle und Datum: App-Baukasten-Vergleich 2026.

Für wen richtig: Standard-Anwendungsfälle — Termine, Speisekarte, Mitglieder-App — bei denen eine Vorlage reicht. Der Haken: die Monatsmiete läuft ewig, der Code gehört fast nie dir, und „ohne Programmierung“ endet oft bei der ersten Funktion, die nicht in der Vorlage steckt.

Der Weg mit der steilsten Kurve und dem größten Eigentum. Swift ist eine gut lesbare Sprache, SwiftUI zeigt dir die Oberfläche beim Tippen in der Vorschau, und Apples eigene Tutorials sind kostenlos und gut. Alles, was du zahlst, sind die 99 US-Dollar im Jahr, sobald du veröffentlichen willst — und deine Zeit, und davon ehrlicherweise viel.

Was sich 2026 geändert hat: Selbst Apple hat KI-Agents in Xcode eingebaut, die durch Build-und-Fix-Schleifen iterieren. Wer Swift lernt, lernt es heute mit einem Agenten daneben — das macht dich schneller, ersetzt aber nicht das Verständnis dafür, was ein View, ein Zustand und ein Netzwerkaufruf sind.

Für wen richtig: Du willst Entwickler werden, nicht nur eine App besitzen. Dann ist das der nachhaltigste Weg. Der Haken: Monate bis zur ersten brauchbaren App. Wer ein Produkt validieren will, statt einen Beruf zu lernen, nimmt einen anderen Weg — und liest den Schritt-für-Schritt-Leitfaden, bevor er Code anfasst.

Der neue Weg, und der Grund, warum diese Seite existiert: 2026 kann ein KI-Agent eine echte native iPhone-App schreiben — Swift, SwiftUI, in Xcode kompiliert, Fehler selbst behoben — während du in normalem Deutsch beschreibst, was die App tun soll. Das Prinzip dahinter heißt Vibe Coding, und wie es sich von Chatbots und Baukästen unterscheidet, erklärt App erstellen mit KI.

Modaal — unser Produkt, deshalb die Offenlegung oben — ist dafür gebaut. Du bringst den KI-Agenten mit, den du ohnehin abonniert hast (Claude Code, Codex, Cursor oder einen von 13); Modaal gibt ihm die Architektur, den Arbeitsbereich und die Build-Schleife. Für jede Funktion schreibt der Agent zuerst einen Plan — Szenarien, Vorgehen, Risiken — den du liest und freigibst; erst dann entsteht Code. Das Ergebnis ist ein normales Xcode-Projekt auf deinem Mac, vom ersten Build an. Und wenn die App später auch auf Android soll: Duet, unser Open-Source-Framework, baut aus demselben Projekt echtes Kotlin mit Jetpack Compose — die Logik wird geteilt, die Oberflächen bleiben jeweils nativ. Wie das in der Praxis aussieht, steht auf der Android-Seite.

Zur Ehrlichkeit gehört der Rest des Feldes: Mehrere KI-Builder erzeugen für das iPhone React Native — plattformübergreifendes JavaScript, das über eine Brücke läuft, meist in Credits abgerechnet; ein paar erzeugen wie wir echtes Swift, teils nur für iOS. Die Frage, die du jedem stellen solltest, ist dieselbe: Was kommt heraus, und in welchem Tarif darf ich es mitnehmen?

Für wen richtig: Du willst eine echte, native iPhone-App besitzen, ohne Swift zu lernen oder eine Agentur zu bezahlen — und du willst iterieren können, ohne dass jeder Versuch Geld kostet. Der Gratis-Plan ist ein Projekt mit unbegrenzten Prompts auf einer Plattform; Pro kostet 9 € pro Monat bei jährlicher Zahlung und bringt beide Plattformen sowie TestFlight- und App-Store-Distribution — Details auf der Preisseite. Der Haken: ein Mac ist Voraussetzung, und komplexe Spezialfälle brauchen weiterhin Entwickler-Review.

Die ehrliche Antwort in drei Sätzen. Bauen ohne Mac: ja, bei Werkzeugen, die in der Cloud kompilieren — das sind in der Regel Cross-Platform-Builder und Baukästen, deren Ergebnis dann auch entsprechend aussieht. Echtes natives Swift in einem Xcode-Projekt, das dir gehört: dafür braucht es einen Mac, weil Xcode einer ist — das gilt für Weg 3 und für Modaal gleichermaßen, und wir sagen es lieber hier als nach dem Download. Ein Mac, den du nicht besitzt: gemietete Macs in der Cloud sind eine reale Option für Menschen, die nur zum Bauen einen brauchen.

Was auf keinem Weg ohne Apple geht: Veröffentlichen. Das Entwicklerkonto, TestFlight und die Prüfung laufen über Apple, egal womit du gebaut hast.

Egal welcher der vier Wege — die letzten Schritte sind für alle gleich, und sie sind der Teil, den Erstveröffentlicher am häufigsten unterschätzen.

TestFlight zuerst. Apples eigener Beta-Dienst: Du lädst einen Build hoch, lädst Tester per Link ein — bis zu 10.000 externe Tester, jeder Build 90 Tage gültig — und bekommst Abstürze und Rückmeldungen, bevor die Öffentlichkeit sie sieht. Der erste externe Build wird von Apple kurz geprüft.

Der Store-Eintrag. Name, Untertitel, Beschreibung, Screenshots in den geforderten Größen, Datenschutzangaben, Altersfreigabe. Das ist Schreibarbeit, keine Programmierarbeit — und der Punkt, an dem deine Fünf-Sätze-Beschreibung von oben zum zweiten Mal Arbeit spart.

Die Prüfung. Apple schreibt selbst, dass 90 Prozent der Einreichungen in weniger als 24 Stunden geprüft werden. Mehr Zeitangaben machen wir nicht, weil Apple keine macht. Wird eine erste Einreichung abgelehnt, liegt es meistens an Vollständigkeit — fehlende Angaben, ein Testkonto, das nicht funktioniert, eine Funktion, die im Review abstürzt — nicht an der Idee. Wie die Einreichung im Detail abläuft, Schritt für Schritt: How to publish an app on the App Store (auf Englisch).

Und was es insgesamt kostet — Konto, Werkzeug, laufende Kosten, mit jeder Zahl nachprüfbar — rechnet App entwickeln: Kosten durch.