iOS-App-Entwicklung mit SwiftUI: Kosten realistisch kalkulieren

Die Kosten einer SwiftUI-App bestehen aus drei Blöcken, die getrennt gerechnet gehören: Entwicklungsaufwand in Stunden, Apple-Fixkosten pro Mitgliedschaftsjahr und Betriebsaufwand ab dem Tag nach dem Release. Wer Ihnen eine Zahl nennt, bevor Deployment-Target, Datenhaltung und Login geklärt sind, schätzt nicht — der rät.

Deshalb steht hier keine Euro-Spanne, sondern eine Rechenlogik in Stunden: Zwölf Bausteine mit Aufwandsbändern, vier Entscheidungen, die stärker durchschlagen als die halbe Feature-Liste, und eine Betriebsrechnung, die in den meisten Angeboten fehlt. Den Stundensatz setzen Sie selbst ein — der steht in Ihrem Angebot, und er schwankt je nach Anbieter, Region und Vertragsmodell zu stark, als dass eine Pauschalzahl Ihnen hier helfen würde.

Die Formel: Drei Summanden, die nicht vermischt werden dürfen

Gesamtkosten = (Aufwand in Stunden × vereinbarter Satz) + Apple-Fixkosten pro Jahr + (Betriebsaufwand pro Jahr × geplante Laufzeit)

Der Fehler sitzt fast immer im dritten Summanden. Ein Angebot über den Erstrelease ist vollständig und trotzdem irreführend, wenn die App drei Jahre laufen soll und niemand über das Wartungsfenster gesprochen hat. Rechnen Sie die Laufzeit von Anfang an mit — sonst vergleichen Sie ein Auto mit einem Auto plus Tankfüllung.

Was bei Apple fix anfällt und was Sie dort selbst nachsehen müssen

Apple nennt für das Apple Developer Program eine Gebühr von 99 US-Dollar pro Mitgliedschaftsjahr beziehungsweise den umgerechneten Betrag in Landeswährung, sofern verfügbar (Apple: Mitgliedschaft auswählen). Auf derselben Seite stellt Apple gegenüber, welche Leistungen ohne kostenpflichtige Mitgliedschaft zur Verfügung stehen und welche an das Programm gebunden sind. Prüfen Sie die Tabelle vor jeder Kalkulation direkt dort — Betrag, Währungsumrechnung und Leistungsumfang können sich ändern, und die Vergleichsseite ist die Quelle, die im Zweifel zählt.

Zwei weitere Fixposten übersieht man leicht: Xcode läuft auf macOS, ein Mac ist also Voraussetzung — gekauft, geleast oder als gemieteter Build-Runner. Und Sie brauchen mindestens ein echtes Testgerät, weil der Simulator Kamera, Sensoren, Push-Zustellung und Energieverhalten nicht vollständig abbildet. Beides ist keine Entwicklungsstunde, taucht aber in der Projektrechnung auf.

Aufwandsmatrix: Zwölf Bausteine einer SwiftUI-App

Die folgenden Bänder sind Modellwerte aus meiner eigenen Kalkulationslogik für iPhone-Apps mit Datenhaltung, nicht für Spiele oder Kamera-Pipelines. Sie sind keine Preisliste, sondern eine Struktur, gegen die Sie ein fremdes Angebot Position für Position prüfen können.

Interessanter als die Gesamtsumme ist der Vergleich zweier Pfade innerhalb dieses Modells. Nehmen Sie jeweils die Bandmitte aus der Tabelle und lassen Baustein 7 (Backend/Sync) und Baustein 9 (In-App-Käufe) weg, kommen Sie auf rund 190 Stunden für eine Offline-First-App. Rechnen Sie beide Bausteine dazu, liegen Sie bei rund 274 Stunden. Das ist keine Messung, sondern eine Beispielrechnung auf Basis der Bänder oben — sie zeigt, dass Sync plus Kauf nicht die App verdoppeln, sondern rund 84 Stunden addieren. Über diesen Block entscheiden Sie zuerst, nicht über die Farbpalette.

Vier Entscheidungen, die stärker durchschlagen als die Feature-Liste

Deployment-Target

Jede zusätzlich unterstützte iOS-Hauptversion unterhalb der aktuellen kostet in meiner Kalkulation 6 bis 10 Stunden — für Verfügbarkeitsprüfungen im Code, Fallback-Varianten neuerer SwiftUI-Komponenten und eine breitere Testmatrix. Zwei Versionen zurück sind also kein Häkchen im Angebot, sondern rund ein Arbeitstag pro Version, jedes Jahr aufs Neue.

Lokal oder synchronisiert

Solange ein Nutzer die App auf einem Gerät verwendet und kein Web-Zugriff geplant ist, ist lokale Persistenz die günstigere Antwort: Baustein 7 fällt komplett weg, und die Datenschutzdokumentation wird kürzer, weil keine personenbezogenen Daten das Gerät verlassen. Eine einfache Tracking-App, etwa für Kalorien, lässt sich bewusst so bauen — kein Account, keine Cloud. Sobald aber ein zweites Gerät oder eine Weboberfläche dazukommt, brauchen Sie Konfliktauflösung, und die kostet unabhängig davon, wie einfach die App aussieht. Bei der Basaltemperatur-App teilen sich Next.js-Web und SwiftUI-Client eine Datenbasis; genau dort sitzt der Aufwand, nicht in den Kurvenansichten.

Login

Ein Login ist selten eine Funktion, sondern ein Rattenschwanz: Registrierung, Wiederherstellung, Session-Handling, Kontolöschung, Rechte im Backend. Wenn die App ohne Konto funktionieren kann, streichen Sie es — das ist die einzige Position in der Matrix, die Sie mit einer Produktentscheidung auf null setzen können, ohne die App zu beschneiden.

Widgets, iPad, Watch

Ein Widget ist kein weiterer Screen, sondern ein eigenes Target mit eigenem Lebenszyklus, eigenem Datenzugriff und eigenem Testpfad. Gleiches gilt für Watch-App und iPad-Layout. Wer diese Surfaces „später einfach nachziehen" will, kauft sich einen Nachtrag in der Größenordnung eines eigenen kleinen Projekts.

SwiftUI oder UIKit: Wo der Unterschied im Budget landet

Bei Listen, Formularen, Detailansichten und Zustandsführung schreiben Sie in SwiftUI deutlich weniger Code als in UIKit — das ist der Regelfall in Baustein 4 und 5. Der Aufwand kippt an drei Stellen: Bei stark angepassten Collection-Interaktionen, bei eigener Rendering-Logik und dann, wenn Ihr Deployment-Target zwei Hauptversionen unter der aktuellen liegt und Sie Komponenten nachbauen oder über `UIViewRepresentable` einbinden müssen.

Praktische Regel für das Angebot: Wenn dort „SwiftUI" steht, aber keine Aussage zum Deployment-Target, fehlt die Hälfte der Information. Fragen Sie nach, bevor Sie unterschreiben.

Cross-Platform: Wann eine geteilte Codebasis wirklich spart

Beispiel: Zeigt die App im Kern nur Formulare, Listen und Diagramme und läuft auf beiden Plattformen praktisch identisch, kann eine geteilte Codebasis in diesem Szenario Entwicklungsstunden sparen, weil Baustein 4 und 5 nur einmal entstehen. Sobald pro Plattform eigene Systemintegrationen dazukommen — Widgets, HealthKit, Live Activities, plattformspezifische Berechtigungen —, kann sich das umkehren: Die vermeintliche Ersparnis fließt dann in Bridge-Code und doppeltes Debugging. Die Entscheidung fällt deshalb nicht am Framework selbst, sondern an der Frage, wie viel der App tatsächlich Betriebssystem-Funktionalität ist.

Betriebskosten ab Release: Die Rechnung, die im Angebot fehlt

Apple veröffentlicht jährlich eine neue iOS-Hauptversion, in der Regel im Herbst. Planen Sie für dieses Fenster 20 bis 30 Stunden: Build gegen das neue SDK, Prüfung veränderter Systemkomponenten, Nachziehen von Layout- und Berechtigungsänderungen, neue Gerätetests. Dazu kommen Zertifikate und Provisioning-Profile, die auslaufen — ein Termin im Kalender, kein Zufall.

Als eigene Budget-Faustregel setze ich 15 bis 25 Prozent des Erstaufwands pro Jahr für dieses Wartungsfenster an — ein Erfahrungswert aus meinen Projekten, keine Branchenkennzahl. Beispielrechnung auf Basis des Sync-Pfads von oben (rund 274 Stunden): Das ergibt etwa 41 bis 69 Stunden jährlich, über drei Jahre summiert etwa 123 bis 206 Stunden. Das entspricht grob 45 bis 75 Prozent eines zweiten Erstprojekts, nur um die App lauffähig zu halten. Wer diesen Posten nicht im Angebot sieht, hat ihn nicht wegverhandelt, sondern nur verschoben.

Was in solchen Projekten typischerweise schiefgeht

Design vor Datenmodell. Wird das UI fixiert, bevor klar ist, welche Entität wozu gehört, kommt der Umbau in Baustein 2 und 4 gleichzeitig — und beide sind die teuersten Positionen der Matrix.

Das nachgeschobene Backend. „Erstmal lokal, Sync machen wir später" ist zulässig, wenn das Datenmodell von Anfang an sync-fähig entworfen wird. Passiert das nicht, ist der Nachtrag größer als der ursprüngliche Baustein 7.

Store-Unterlagen zu spät. Screenshots, Beschreibung, Support-URL und die Datenschutzangaben in App Store Connect entstehen nicht nebenbei am Abgabetag. Prüfen Sie früh die aktuell geltenden App Review Guidelines und die Pflichtfelder in App Store Connect, statt sie in der Review-Runde zum ersten Mal zu lesen.

Betrieb ohne Vereinbarung. Ist im Vertrag kein Wartungsfenster festgelegt, ist nach dem Release oft niemand konkret zuständig — bis die App bei der nächsten iOS-Version bricht. Dann wird aus einer planbaren Position ein Notfall, und Notfälle sind in der Regel die teuerste Form von Wartung.

Acht Fragen, die den Preis eines Angebots erklären

1. Welches Deployment-Target, und welche Geräteklassen sind im Test enthalten?
2. Wo liegen die Daten — nur auf dem Gerät, oder synchronisiert?
3. Ist ein Konto vorgesehen, und wer baut Registrierung, Wiederherstellung und Löschung?
4. Sind Widgets, iPad-Layout oder Watch-App im Preis oder ausdrücklich ausgeschlossen?
5. Wer betreibt das Apple-Developer-Konto, wer hält die Zertifikate?
6. Sind Store-Assets, Metadaten und Datenschutzangaben Teil des Auftrags?
7. Wie viele Review-Iterationen sind eingerechnet?
8. Was kostet das jährliche Wartungsfenster nach dem nächsten iOS-Release?

Jede Frage ohne Antwort ist eine offene Position, die später als Nachtrag zurückkommt. Wie sich solche Positionen in ein belastbares Festpreis-Angebot übersetzen lassen, steht in Web App Entwicklung zum Festpreis: Modell, Voraussetzungen und Risiken; die Struktur für die Anfrage selbst finden Sie in der Checkliste für Anfrage und Angebotsvergleich. Für die Kostenlogik auf der Web-Seite desselben Produkts habe ich die Faktoren in Web App Entwicklung Kosten aufgeschlüsselt.

Häufige Fragen

Was kostet ein Entwickler-Account bei Apple?

Apple gibt die Gebühr für das Apple Developer Program mit 99 US-Dollar pro Mitgliedschaftsjahr an, alternativ mit dem umgerechneten Betrag in Landeswährung, sofern verfügbar (Apple: Mitgliedschaft auswählen). Kalkulieren Sie die Gebühr pro Jahr der geplanten Laufzeit, nicht einmalig, und prüfen Sie den aktuellen Betrag vor Vertragsschluss auf der verlinkten Seite.

Ist Apple Developer kostenlos?

Apple stellt auf seiner Vergleichsseite die Leistungen ohne kostenpflichtige Mitgliedschaft den Leistungen gegenüber, die das kostenpflichtige Apple Developer Program voraussetzen; die Veröffentlichung im App Store gehört laut dieser Übersicht zum kostenpflichtigen Programm (Apple: Mitgliedschaft auswählen). Für ein Lernprojekt, das nie veröffentlicht wird, kann die Rechnung deshalb anders aussehen als für ein Produkt, das über den Store vertrieben werden soll — prüfen Sie den aktuellen Leistungsumfang direkt auf der verlinkten Seite.

Was kostet es, eine App im App Store zu veröffentlichen?

Neben der Programmgebühr entsteht Arbeitsaufwand: In der Matrix oben sind das die Bausteine 11 und 12, zusammen 24 bis 44 Stunden für Testmatrix, TestFlight-Beta, Store-Assets, Metadaten, Datenschutzangaben und Review-Runden. Rechnen Sie eine Nachbesserungsschleife ein, statt auf die Freigabe im ersten Anlauf zu setzen.

Wie fange ich mit Swift und SwiftUI konkret an?

Mac mit Xcode, ein neues Projekt mit SwiftUI-Lifecycle, dann in dieser Reihenfolge: Datenmodell, ein Screen mit echten Zuständen, Navigation, danach erst Feinschliff. Wer mit dem Screen beginnt und das Modell nachzieht, baut denselben Bildschirm zweimal — das ist der häufigste Grund, warum Baustein 4 aus dem Band läuft.