App-Entwicklung: der Ablauf von der Idee bis in den Store und danach

Die App ist fertig, die Screenshots sind erstellt, der Build geht an den App Store, und zwei Tage später kommt die Ablehnung: Das Prüfteam ist nicht über den Anmeldebildschirm hinausgekommen, weil niemand ein Demokonto hinterlegt hat. Bei Google Play ist es anders, aber nicht weniger ärgerlich. Ein neu angelegtes privates Entwicklerkonto schaltet die Produktion erst nach einem geschlossenen Test mit mindestens zwölf Personen frei. In beiden Stores ist Code nur ein Teil der Arbeit.

Dieser Beitrag beschreibt den Ablauf der App-Entwicklung so, wie ihn Auftraggeber kennen sollten: Technologiewahl, Design und Plattformrichtlinien, Backend und Benachrichtigungen, Datenschutzangaben, Veröffentlichung, Regeln für In-App-Käufe, Release-Management, Absturzberichte und Wartung. Wenn Sie noch nicht sicher sind, ob Sie überhaupt eine App brauchen, lesen Sie zuerst unseren Beitrag „App oder mobil optimierte Website?“.

Der Ablauf im Überblick: Phasen und Ergebnisse

Die Tabelle zeigt die Phasen einer typischen Business-App, die in beide Stores soll. Dauern lassen wir weg, weil sie von Projekt zu Projekt stark schwanken; wichtig ist, dass jede Phase mit etwas Greifbarem endet.

Nativ oder plattformübergreifend?

Bei nativer Entwicklung entsteht die iOS-App in Swift (meist mit SwiftUI) und die Android-App in Kotlin (mit Jetpack Compose), jeweils getrennt. Sie nutzen jede neue Plattformfunktion vom ersten Tag an, und die Oberfläche verhält sich genau wie die Plattform selbst. Der Preis dafür sind zwei Codebasen und oft zwei Spezialistenteams.

Plattformübergreifende Entwicklung erzeugt beide Apps aus einer Codebasis. Die beiden verbreitetsten Optionen:

• Flutter: von Google entwickelt, in Dart geschrieben, mit eigener Rendering-Engine für die Oberfläche. Die App kann auf beiden Plattformen identisch aussehen; ein plattformtypisches Gefühl kostet zusätzliche Arbeit.
• React Native, von Meta gestartet, in JavaScript oder TypeScript geschrieben und mit den Oberflächenkomponenten der jeweiligen Plattform. Seit Version 0.76 ist die „New Architecture“ Standard, und die React-Native-Dokumentation empfiehlt, neue Projekte mit einem Framework wie Expo zu beginnen. Für Teams, die im Web bereits React einsetzen, ist die Einarbeitung kurz.

Ein dritter Weg gewinnt an Gewicht: Kotlin Multiplatform. Hier wird die Geschäftslogik geteilt, die Oberfläche kann auf jeder Plattform nativ bleiben. JetBrains hat die iOS-Unterstützung von Compose Multiplatform im Mai 2025 für stabil erklärt.

Für die meisten Business-Apps, also Bestellung, Buchung, Kundenbindung, Außendienst oder Inhalte, ist plattformübergreifende Entwicklung eine vernünftige und wirtschaftliche Wahl. Nativ spielt seine Stärken aus, wenn eine App nah an der Hardware arbeitet: intensive Kamera- und Bildverarbeitung, ständige Kommunikation mit Bluetooth-Geräten, leistungshungrige Grafik. Ein Hinweis noch: Auch plattformübergreifend brauchen Widgets, Apple Watch oder Live Activities etwas Swift und Kotlin. Fragen Sie im Angebot nach, wer das übernimmt.

Design: Plattformrichtlinien und der Blick des Stores

Apples Human Interface Guidelines (HIG) und Googles Material Design 3 beschreiben, welches Verhalten die Nutzer der jeweiligen Plattform erwarten. Das ist Muskelgedächtnis, keine Geschmacksfrage. Unter Android muss die System-Zurück-Geste auf jedem Bildschirm einheitlich funktionieren; iOS-Nutzer erwarten, mit einer Wischgeste vom linken Rand zurückzukommen. Auch Tab-Leisten, Hinweisdialoge und Teilen-Menüs unterscheiden sich zwischen beiden.

Beide Designsprachen wurden zuletzt erneuert. Apple hat mit der 2025 vorgestellten Designsprache Liquid Glass das Aussehen von iOS 26 verändert, Google hat Material 3 um das Update „Expressive“ erweitert. Wer diese Sprachen respektiert und trotzdem Markenfarben und Schrift beibehält, verhindert, dass die App wie eine verpackte Website wirkt.

Die Formulierung ist bewusst gewählt: Richtlinie 4.2 der App Review Guidelines von Apple weist Apps zurück, die nicht über eine neu verpackte Website hinausgehen. Der Store erwartet Funktionen und ein Erlebnis, die wirklich nach App aussehen.

Barrierefreiheit gehört zum Design. Apple empfiehlt Tippflächen von mindestens 44 mal 44 Punkt, Material mindestens 48 mal 48 dp. Bildschirme dürfen nicht zerfallen, wenn Nutzer die Schrift vergrößern (unter iOS Dynamic Type), VoiceOver und TalkBack müssen jede Schaltfläche vorlesen können, und der Dunkelmodus sollte von Anfang an mitgedacht sein. Richtet sich Ihre App an Verbraucher und dient dem elektronischen Geschäftsverkehr, gilt seit dem 28. Juni 2025 zudem das Barrierefreiheitsstärkungsgesetz (BFSG), mit Ausnahmen für Kleinstunternehmen.

Backend, API und Benachrichtigungen

Hinter der App, die Ihre Nutzer sehen, läuft ein Backend für Anmeldung, Daten, Zahlungen, Benachrichtigungen und eine Verwaltungsoberfläche. Das kann eine eigene API sein oder ein Dienst wie Firebase oder Supabase. Fertige Dienste beschleunigen den Start, binden Ihr Datenmodell und Ihre Kostenstruktur aber an deren Regeln.

Mobil gilt eine Besonderheit, die es im Web nicht gibt: Alte Versionen bleiben monatelang im Umlauf, weil manche Nutzer automatische Updates abschalten. Die API braucht deshalb eine Versionierung, ältere App-Versionen sollten eine Zeit lang weiter unterstützt werden, und ab der ersten Version gehört ein Mechanismus für Pflicht-Updates in die App, der sagen kann: „Diese Version wird nicht mehr unterstützt, bitte aktualisieren.“

Auch für die Anmeldung gibt es eine Store-Regel. Nach Apples Richtlinie 4.8 müssen Apps, die für das Hauptkonto einen Drittanbieter-Login wie Google oder Facebook anbieten, zusätzlich eine gleichwertige Option bereitstellen, die die Datenerhebung auf Name und E-Mail-Adresse beschränkt und das Verbergen der E-Mail-Adresse erlaubt. Sign in with Apple erfüllt diese Anforderung. Nutzen Sie nur Ihr eigenes Kontosystem, entfällt die Pflicht.

Benachrichtigungen

Unter iOS laufen Push-Nachrichten über den Apple Push Notification service (APNs), unter Android meist über Firebase Cloud Messaging (FCM), das iOS-Geräte ebenfalls über APNs erreichen kann. Beide Plattformen verlangen die Zustimmung der Nutzer. Seit Android 13 (API-Level 33) hängen Benachrichtigungen an einer Laufzeitberechtigung namens POST_NOTIFICATIONS und bleiben bei neu installierten Apps aus, bis der Nutzer zustimmt.

Fragen Sie deshalb nicht beim ersten Start, sondern in dem Moment, in dem der Nutzen offensichtlich ist. „Sollen wir Ihnen Bescheid geben, wenn Ihre Bestellung versendet wurde?“ bekommt deutlich mehr Zustimmung als ein Systemdialog, der beim Öffnen der App aufspringt. Planen Sie Häufigkeit, Themen und den Zielbildschirm jeder Nachricht (Deep Link) von Anfang an. Huawei-Geräte ohne Google-Dienste brauchen AppGallery und Huaweis eigenen Push-Dienst, ein eigenes Arbeitspaket.

Datenschutz: Labels, Data-safety-Formular und Kontolöschung

Beide Stores verlangen, dass Sie den Nutzern zeigen, welche Daten die App erhebt. Bei Apple ist das der Bereich „App-Datenschutz“ in App Store Connect, der auf der Produktseite als Datenschutzlabel erscheint. Das Gegenstück bei Google Play ist das Formular zur Datensicherheit (Data safety) in der Play Console. In beiden Fällen geben Sie nicht nur an, was Ihr eigener Code erhebt, sondern auch, was Ihre Analyse-, Werbe-, Absturz- und Zahlungs-SDKs sammeln.

Apple verlangt außerdem ein Privacy Manifest von Apps, die bestimmte System-APIs nutzen, und von verbreiteten Drittanbieter-SDKs, wobei jedes SDK sein eigenes Manifest mitbringen muss. Wer Nutzer über Apps und Websites anderer Unternehmen hinweg verfolgt, braucht zusätzlich die Zustimmung über App Tracking Transparency.

Die Kontolöschung ist eine gemeinsame Pflicht. Kann man in der App ein Konto anlegen, verlangt Apple, dass es sich auch in der App löschen lässt. Google Play fordert im Data-safety-Formular zusätzlich einen Weblink, über den Nutzer die Löschung von Konto und Daten beantragen können, ohne die App neu zu installieren.

Bleibt die Altersfreigabe. Apple hat 2025 die Altersstufen überarbeitet: 12+ und 17+ sind entfallen, 13+, 16+ und 18+ kamen hinzu, und die neuen Fragen zur Altersfreigabe in App Store Connect müssen beantwortet sein. Google Play nutzt den IARC-Fragebogen. Für Kinder-Apps haben beide Stores eigene, strenge Regeln.

Veröffentlichung: App Store und Google Play

Entwicklerkonten

Legen Sie die Konten auf Ihr Unternehmen an, nicht auf die Agentur. Für die Teilnahme am Apple Developer Program als Organisation brauchen Sie eine juristische Person, eine Website mit zur Organisation passender Domain und eine D-U-N-S-Nummer; auch Google Play verlangt für neue Organisationskonten eine D-U-N-S-Nummer. Weil die Vergabe oder Aktualisierung der Daten dauern kann, erledigen Sie das zu Entwicklungsbeginn und nicht in der Launch-Woche.

App Store

Testversionen werden über TestFlight verteilt: bis zu 100 interne und 10.000 externe Tester, jeder Build bleibt 90 Tage verfügbar. Der erste Build für externe Tester durchläuft eine kurze Prüfung.

Apple gibt an, mindestens die Hälfte aller Einreichungen in weniger als 24 Stunden und 90 Prozent in weniger als 48 Stunden zu prüfen; unvollständige Einreichungen dauern länger oder werden abgelehnt. Nach Apples Angaben betreffen mehr als 40 Prozent der ungelösten Probleme die Richtlinie 2.1 zur Vollständigkeit: abstürzende Bildschirme, Platzhalterinhalte, defekte Links, Anmeldemasken ohne Demokonto. Ein funktionierendes Demokonto samt Hinweisen im Bereich App Review Information ist die billigste Vorsorge überhaupt.

Nach der Freigabe können Sie Updates schrittweise veröffentlichen. Apples Phased Release erstreckt sich über sieben Tage und erreicht nacheinander 1, 2, 5, 10, 20, 50 und schließlich 100 Prozent der Nutzer mit aktivierten automatischen Updates; insgesamt lässt sich die Auslieferung bis zu 30 Tage pausieren. Und seit dem 28. April 2026 müssen Apps, die in App Store Connect hochgeladen werden, mit Xcode 26 und dem iOS-26-SDK gebaut sein. Apple hebt diese Latte jedes Jahr an.

Google Play

Die Play Console kennt vier Tracks: interner Test, geschlossener Test, offener Test und Produktion. Für private Entwicklerkonten, die nach dem 13. November 2023 angelegt wurden, gilt eine Zusatzhürde: Vor der Produktion braucht es einen geschlossenen Test mit mindestens 12 Testern, die mindestens 14 Tage ununterbrochen teilgenommen haben.

Danach beantragen Sie im Dashboard den Zugang zur Produktion; laut Google dauert diese Prüfung in der Regel sieben Tage oder weniger. Organisationskonten sind davon ausgenommen, durchlaufen aber das D-U-N-S-Verfahren. Planen Sie Ihren Zeitplan nach Kontotyp.

Auch Googles Vorgabe zum Ziel-API-Level steigt jedes Jahr. Ab dem 31. August 2026 müssen neue Apps und Updates Android 16 (API-Level 36) als Ziel haben. Updates lassen sich gestaffelt ausrollen und bei Problemen anhalten; gestaffelte Rollouts funktionieren nur bei Updates, nicht bei der Erstveröffentlichung. Der Pre-Launch-Bericht der Play Console testet Ihre App vorab automatisch auf echten Geräten und ist oft Ihre erste Absturzliste.

Lassen Sie auch den Store-Eintrag nicht bis zum letzten Tag liegen. App-Name, Kurzbeschreibung, Screenshots und Suchbegriffe entscheiden darüber, ob die App im Store gefunden wird, und sie sollten für jede Sprache eigens geschrieben werden.

In-App-Käufe und Store-Regeln

Verkaufen Sie in der App etwas Digitales, werden Store-Regeln Teil Ihres Geschäftsmodells. Nach Apples Richtlinie 3.1.1 brauchen Sie In-App-Käufe, wenn Sie in der App Funktionen oder Inhalte freischalten (Abos, Premium-Inhalte, Spielwährung). Bei physischen Waren und Dienstleistungen, die außerhalb der App genutzt werden, gilt das Gegenteil: Ein Paket oder ein Friseurtermin wird per Karte oder Apple Pay bezahlt, nicht per In-App-Kauf. Auch Googles Zahlungsrichtlinie setzt für digitale Güter auf Google Play Billing.

Die Regeln unterscheiden sich je nach Region. In der US-Storefront erlaubt Apple nach einem Gerichtsurteil aus dem Jahr 2025 Schaltflächen und Links zu externen Kaufmöglichkeiten. In der Europäischen Union hat der Digital Markets Act alternative App-Marktplätze, Webvertrieb sowie alternative Zahlungs- und Verlinkungsoptionen ermöglicht, und Google betreibt für den Europäischen Wirtschaftsraum Programme für alternative Abrechnung und externe Angebote. Jede Option hat eigene Vertrags- und Provisionsbedingungen, und diese haben sich in den letzten zwei Jahren mehrfach geändert. Lesen Sie vor der Entscheidung die aktuellen EU-Bedingungen beider Stores und prüfen Sie sie mit Ihrer Rechtsberatung.

Drei technische Punkte gehen leicht unter. Bauen Sie für wiederherstellbare Käufe eine Schaltfläche „Käufe wiederherstellen“ ein; Apples Richtlinien nennen das ausdrücklich. Prüfen Sie Käufe auf dem Server statt auf dem Gerät, mit der App Store Server API und der Google Play Developer API. Und verfolgen Sie den Lebenszyklus von Abos (Verlängerung, Kündigung, Erstattung, Zahlungsprobleme) über die Server-Benachrichtigungen der Stores; Werkzeuge wie RevenueCat können einen Teil davon übernehmen.

Release-Management, Absturzberichte, Analyse und Wartung

Release-Management

Jede Veröffentlichung trägt zwei Nummern: die Version, die Nutzer sehen (etwa 2.4.0), und die Build-Nummer, die der Store bei jedem Upload höher erwartet. Ein gleichmäßiger Rhythmus, zum Beispiel alle zwei Wochen, ist sicherer als seltene, große Versionen. Unfertige Funktionen hinter Feature Flags zu verstecken, entkoppelt den Release-Plan von der Funktionsentwicklung.

Teams mit React Native und Expo können Korrekturen in der JavaScript-Schicht drahtlos (OTA) ausliefern, ohne auf die Store-Prüfung zu warten. Ein nützliches Werkzeug mit klarer Grenze: Apples Richtlinie 2.5.2 erlaubt nicht, nachträglich Code herunterzuladen und auszuführen, der Funktionen oder Funktionsweise der App ändert. Fehlerbehebungen ja; neue Bildschirme und Funktionen gehören in eine Store-Version.

Absturzberichte und Analyse

Ein Werkzeug für Absturzberichte wie Firebase Crashlytics oder Sentry gehört vor den Livegang, nicht danach. Auch das Android-vitals-Dashboard von Google Play ist ein Schiedsrichter. Liegt die vom Nutzer wahrgenommene Absturzrate insgesamt über 1,09 Prozent, die ANR-Rate (App reagiert nicht) über 0,47 Prozent oder eine der beiden Raten auf einem einzelnen Smartphone-Modell über 8 Prozent, kann Google die Sichtbarkeit der App im Store verringern. Unter iOS liefert der Xcode Organizer Absturz- und Energieberichte.

Der häufigste Fehler bei der Analyse ist der Ansatz „Wir messen erst einmal alles“. Schreiben Sie zuerst einen kurzen Messplan. Schließen Nutzer die Registrierung ab? Wie viele Schritte braucht es bis zur ersten Bestellung? Wo steigen sie aus? Denken Sie daran, dass Analyse-SDKs nach TDDDG und DSGVO eine Einwilligung erfordern können.

Wartung und Betriebssystem-Updates

Apple stellt jede neue iOS-Version im Juni auf der WWDC vor, erscheinen tut sie meist im September. Auch Google veröffentlicht jedes Jahr eine neue Android-Version und hebt die Vorgabe zum Ziel-API-Level an. Eine Live-App braucht also mindestens ein Kompatibilitätsupdate pro Jahr, selbst wenn Sie nichts Neues hinzufügen: Build mit dem neuen SDK, geänderte Berechtigungsmodelle, entfernte APIs, neue Bildschirmgrößen.

Halten Sie das im Wartungsvertrag ausdrücklich fest. Wer testet im Sommer gegen die Betaversionen? Wie oft werden Bibliotheken aktualisiert? Wer behält Änderungen der Store-Richtlinien im Blick? Apps, die jahrelang niemand anfasst, gehen zuerst auf neuen Geräten kaputt und verlieren dann ihre Sichtbarkeit in den Stores.

Wo fangen Sie an?

1. Schreiben Sie auf eine Seite, welche Aufgabe die App für ihre Nutzer erledigt und wie oft.
2. Legen Sie die Entwicklerkonten bei Apple und Google auf Ihr Unternehmen an und starten Sie das D-U-N-S-Verfahren sofort.
3. Wählen Sie die Technologie auch danach aus, wer den Code in fünf Jahren pflegt.
4. Lassen Sie das Design nach den Richtlinien beider Plattformen erstellen und den klickbaren Prototyp von echten Nutzern testen.
5. Versionieren Sie die API und bauen Sie den Mechanismus für Pflicht-Updates in die erste Version ein.
6. Erstellen Sie ein SDK-Verzeichnis und bereiten Sie damit Datenschutzlabels, Data-safety-Formular, Einwilligungsabfrage und Datenschutzerklärung vor.
7. Wenn Sie über ein privates Google-Play-Konto veröffentlichen, planen Sie den 14-tägigen geschlossenen Test fest ein.
8. Richten Sie Absturzberichte und Messplan vor dem Livegang ein.
9. Schließen Sie vor dem Livegang einen Wartungsvertrag ab, der die jährliche Betriebssystem-Kompatibilität abdeckt.

Wir bei AYTE Digital begleiten Apps von der Konzeption über die Veröffentlichung bis zur laufenden Wartung und legen Konten und Code-Repositories auf den Namen des Kunden an. Stehen Sie am Anfang, gehen wir Ihre Idee gern Phase für Phase mit Ihnen durch und klären, welche Technologie und welcher Zeitplan zu Ihnen passen.