Eine App entwickeln lassen: was wirklich dazugehört

Wer „App entwickeln lassen” sucht, denkt meist zuerst an Programmierer. Der Code ist aber nur ein Teil des Auftrags. Eine App, die im App Store und bei Google Play tatsächlich ankommt, braucht ein Store-Listing, Screenshots, einen Review-Prozess und — sobald sie etwas verkauft — eine funktionierende Abo- oder Kauf-Infrastruktur. Wer das vorher nicht einplant, erlebt die Überraschung erst kurz vor dem geplanten Launch-Termin, meist genau dann, wenn Marketing, Pressetermin oder Messeauftritt bereits feststehen und sich nicht mehr verschieben lassen.

Das betrifft nicht nur Start-ups mit einer Produktidee. Ebenso häufig fragen etablierte Mittelstandsfirmen nach einer App als Ergänzung zu einem bestehenden Geschäft — eine Kundenkarte, ein Buchungstool, ein Zugang zu einem Portal, das bisher nur über den Browser lief. Die Fragen, die dabei entscheiden, sind fast immer dieselben.

Ein Code, zwei Stores

Wir bauen mobile Apps mit Flutter: eine Codebasis für iOS und Android statt zwei getrennter Teams mit zwei getrennten Bugs. Das hält die Entwicklungszeit planbar und heißt vor allem, dass eine Änderung nicht zweimal gemacht, zweimal getestet und zweimal vergessen werden kann. Ein Bugfix, der auf iOS greift, greift automatisch auch auf Android — es gibt keine zweite Version, die den Fix erst noch nachträglich bekommt. Simtegre, unsere eigene eSIM-App, läuft nach demselben Prinzip, und wir verlassen uns im Alltag selbst darauf.

Was zwischen „fertig programmiert” und „im Store” liegt

Store-Einträge. Titel, Beschreibung, Keywords und Screenshots für App Store Connect und Google Play sind eigene Arbeit, keine Fußnote. Apple und Google reviewen nach unterschiedlichen Regeln, und ein abgelehnter Build kostet Zeit, die im Zeitplan meist nicht eingeplant war.

Der Review-Prozess. Google prüft in der Regel schneller, Apple gründlicher — Berechtigungen, Datenschutzangaben und In-App-Käufe werden geprüft, bevor eine App live geht. Wer eine App zum ersten Mal einreicht, sollte einen Puffer von mehreren Tagen bis wenigen Wochen für Rückfragen einplanen, nicht null.

Abos und Käufe. Sobald eine App etwas verkauft — ein Abo, ein Einmalkauf, eine In-App-Funktion — kommt eine Zahlungsschicht dazu. Wir setzen dafür RevenueCat ein, weil es Apples und Googles unterschiedliche Abrechnungslogik hinter einer Schnittstelle vereinheitlicht, statt beide Store-APIs einzeln zu pflegen.

Bestandsapps. Nicht jedes Projekt startet bei null. Wenn eine bestehende App übernommen werden soll — ein Freelancer ist nicht mehr erreichbar, der Code ist undokumentiert — prüfen wir sie zuerst, bevor wir irgendetwas versprechen: welche Abhängigkeiten sind veraltet, welche Store-Richtlinien haben sich seit dem letzten Update geändert, was lässt sich übernehmen und was nicht. Dieses Audit ist selbst schon eine eigene, klar abgegrenzte Aufgabe, keine kostenlose Vorstufe zum eigentlichen Projekt.

Datenschutzangaben. Beide Stores verlangen inzwischen eine detaillierte Auskunft darüber, welche Daten eine App sammelt und wofür — Apples „Datenschutz-Kennzeichnung” und Googles Datensicherheitsformular. Diese Angaben müssen mit dem übereinstimmen, was die App tatsächlich tut, sonst folgt eine Ablehnung mit Verweis auf genau diese Diskrepanz. Wer das erst beim Einreichen ausfüllt, statt es während der Entwicklung mitzuführen, verliert an dieser Stelle regelmäßig Zeit.

Was eine App-Idee von einem App-Projekt unterscheidet

Eine Idee lässt sich in einem Satz beschreiben. Ein Projekt braucht eine Antwort auf konkretere Fragen: Muss die App offline funktionieren, etwa auf einer Baustelle oder einem Schiff ohne durchgängige Verbindung? Muss sie Standortdaten im Hintergrund erfassen, und wenn ja, wofür genau — beides sind Berechtigungen, die Nutzer aktiv gewähren müssen und die beide Stores besonders genau prüfen. Wird sie an ein bestehendes System angebunden, etwa ein Warenwirtschaftssystem oder ein CRM, oder steht sie für sich allein? Jede dieser Antworten verschiebt, wie lange ein Projekt dauert und welche Tests es vor der Einreichung braucht.

Was den Aufwand wirklich treibt

Faktor	Wirkung auf den Aufwand
Zahl der Bildschirme und Nutzerflüsse	direkt proportional
Offline-Fähigkeit	erhöht ihn spürbar
Push-Benachrichtigungen, Standort, Kamera	jede Geräte-Berechtigung ist eigener Code
Abo- oder Kauf-Logik	eigene Schicht, nicht nebenbei erledigt
Bestehende App übernehmen	Audit zuerst, Schätzung danach

Eine App mit drei Bildschirmen und einem Formular ist in Wochen zu bauen. Eine App mit Offline-Modus, Standortverfolgung und Abo-Verwaltung ist ein anderes Projekt — nicht weil der Code komplizierter aussieht, sondern weil jede dieser Fähigkeiten eigene Fehlerfälle mitbringt, die getestet werden müssen, bevor Apple oder Google sie akzeptieren. Was passiert etwa, wenn die Verbindung mitten in einer Eingabe abbricht, oder wenn ein Nutzer eine Berechtigung zunächst verweigert und später doch erteilt — jeder dieser Fälle muss durchdacht sein, nicht nur der Idealfall, der in der Demo gezeigt wird.

Der Teil, den viele vergessen: danach

Eine App, die einmal im Store steht, ist nicht fertig. Betriebssystem-Updates brechen gelegentlich Funktionen, die vorher liefen. Apple und Google ändern Richtlinien und verlangen irgendwann ein Update, nur um weiter zugelassen zu bleiben — ein neues Betriebssystem-Ziel, eine neue Pflichtangabe, eine Programmierschnittstelle, die abgekündigt wurde. Wer eine App bauen lässt, sollte vorher wissen, wer sie in einem Jahr noch pflegt — nicht nur, wer sie heute schreibt.

Das gilt auch für die Store-Präsenz selbst. Bewertungen sammeln sich, Screenshots veralten, wenn sich die Optik der App ändert, und eine Beschreibung, die vor zwei Jahren geschrieben wurde, passt selten noch zum aktuellen Funktionsumfang. Wir betreuen die Store-Einträge deshalb als laufende Aufgabe, nicht als einmaligen Vorgang beim Launch.

Die Regel, nach der wir Apps planen

Store-Listing, Review und Abrechnung sind Teil des Projekts, nicht der letzte Schritt danach. Wer sie erst am Ende einplant, verliert am Ende Zeit.

Ein Gespräch am Anfang klärt, ob eine App neu gebaut, übernommen oder zuerst nur geprüft werden sollte — bevor irgendjemand eine Zeile Code schreibt, und bevor ein Store-Termin gesetzt wird, der sich später als zu knapp herausstellt. Mehr zum Vorgehen steht auf der Seite zu mobilen Apps.