App-Entwicklung: nativ, plattformübergreifend oder Web?

„Wir brauchen eine App." Der Satz klingt eindeutig und ist es nicht. Dahinter stecken drei sehr unterschiedliche Vorhaben mit Kostenunterschieden um den Faktor zwei bis drei – und mit Folgen, die man erst nach einem Jahr spürt.

Dieser Beitrag vergleicht die drei Wege, benennt die Fälle, in denen jeder von ihnen richtig ist, und behandelt danach den Teil, der in fast jeder Kalkulation fehlt: alles, was nach dem fertigen Code kommt.

Die drei Wege

Nativ

Für iOS wird in Swift entwickelt, für Android in Kotlin. Zwei getrennte Anwendungen, zwei Codebasen, zwei Teams oder ein Team mit doppelter Arbeit.

Der Vorteil ist Unmittelbarkeit. Jede Funktion des Betriebssystems steht am Tag der Veröffentlichung zur Verfügung, ohne auf eine Zwischenschicht zu warten. Die Bedienung fühlt sich für den Nutzer richtig an, weil die Bausteine des Systems selbst verwendet werden. Bei allem, was tief ins Gerät greift – Hintergrundverarbeitung, Bluetooth, Kamera mit Bildverarbeitung, Gesundheitsdaten – ist nativ nicht nur besser, sondern oft der einzige gangbare Weg.

Der Preis: Eine Funktion wird zweimal gebaut, zweimal getestet, zweimal gepflegt. Rechnen Sie mit vierzig bis fünfzig Prozent Mehraufwand gegenüber einer plattformübergreifenden Lösung, nicht mit hundert – ein Teil der Arbeit, etwa Konzept, Gestaltung und Server, fällt ohnehin nur einmal an.

Plattformübergreifend

Ein Code, beide Plattformen. Die verbreiteten Ansätze unterscheiden sich darin, wie sie zur Oberfläche kommen: Einige verwenden die Bedienelemente des Systems und steuern sie aus einer gemeinsamen Logik, andere zeichnen die Oberfläche selbst.

Das ist für die große Mehrheit der Geschäftsanwendungen der richtige Weg. Eine App, die Einsätze anzeigt, Zeiten erfasst, Formulare ausfüllt und Push-Nachrichten empfängt, profitiert kaum von nativer Entwicklung – wohl aber vom halbierten Pflegeaufwand.

Die Grenzen zeigen sich an drei Stellen: bei sehr aufwendigen Animationen, bei tiefen Systemzugriffen und bei brandneuen Betriebssystemfunktionen, für die es noch keine Anbindung gibt. Der letzte Punkt ist in der Praxis der ärgerlichste, weil er unvorhersehbar auftritt.

Web-App

Kein Store, keine Installation, ein Link. Moderne Web-Apps lassen sich auf dem Startbildschirm ablegen, funktionieren eingeschränkt offline und können Push-Nachrichten empfangen – auf Android zuverlässig, auf iOS mit Einschränkungen, die sich zwar gebessert haben, aber weiterhin existieren.

Für interne Werkzeuge ist das häufig die klügste Wahl. Kein Freigabeverfahren, Aktualisierungen erscheinen sofort, keine Store-Gebühren. Wenn Ihre App ohnehin nur mit Internetverbindung sinnvoll ist und keine Gerätefunktionen braucht, sparen Sie sich mit dem Web-Weg einen erheblichen Teil des Aufwands.

Der Nachteil ist Sichtbarkeit. Wer im App Store gefunden werden will, braucht eine App im App Store.

Eine Entscheidungshilfe

Wenn …	dann …
die App ohne Internet nutzbar sein muss	plattformübergreifend oder nativ
Bluetooth, Hintergrunddienste oder Gesundheitsdaten im Spiel sind	nativ
es ein internes Werkzeug für bekannte Nutzer ist	Web-App
Sie im Store gefunden werden wollen	plattformübergreifend oder nativ
das Budget unter 30.000 € liegt	Web-App oder plattformübergreifend, eine Plattform zuerst
die Oberfläche das Produkt ist (Spiele, Bildbearbeitung)	nativ
Sie zwei Plattformen brauchen und begrenztes Budget haben	plattformübergreifend

Eine Ergänzung zur vorletzten Zeile: Bei knappem Budget ist es fast immer besser, eine Plattform richtig zu machen, als zwei halb. Welche zuerst kommt, entscheidet die Zielgruppe – nicht das Telefon des Auftraggebers. In Deutschland liegt Android bei Geschäftsanwendungen im Handwerk und in der Pflege oft deutlich vorn, während zahlungsbereite Verbrauchergruppen eher auf iOS unterwegs sind.

Der Teil, den alle vergessen

Der Code ist fertig. Damit ist typischerweise die Hälfte des Weges geschafft.

Store-Konten und Zertifikate

Für Apple braucht es ein Entwicklerkonto zu 99 US-Dollar im Jahr, für Google eine einmalige Gebühr von 25 US-Dollar. Wichtiger als die Beträge ist die Frage, auf wen die Konten laufen. Unsere klare Empfehlung: immer auf den Auftraggeber. Eine App, die unter dem Konto der Agentur veröffentlicht ist, ist ein Abhängigkeitsverhältnis, das sich nur mit Mühe auflösen lässt.

Für Unternehmenskonten verlangt Apple eine D-U-N-S-Nummer. Die zu beantragen dauert Tage bis Wochen. Wer damit erst anfängt, wenn die App fertig ist, verschiebt den Start ohne Not.

Dazu kommen Signaturzertifikate und Bereitstellungsprofile. Die laufen ab. Ein abgelaufenes Zertifikat verhindert nicht, dass die App bei bestehenden Nutzern läuft – aber es verhindert jede Aktualisierung, bis es erneuert ist.

Die Prüfung im App Store

Apple prüft jede Einreichung manuell. Die Antwort kommt heute meist innerhalb von ein bis zwei Tagen, früher dauerte es deutlich länger. Google prüft ebenfalls, in der Regel schneller, bei neuen Konten aber spürbar gründlicher.

Abgelehnt wird regelmäßig aus Gründen, die nichts mit der Qualität zu tun haben:

• Es gibt eine Möglichkeit, Geld auszugeben, die nicht über die Bezahlfunktion des Systems läuft
• Die App erklärt nicht, warum sie eine Berechtigung braucht
• Es fehlt eine Möglichkeit, das Konto in der App zu löschen – bei Apple seit Jahren Pflicht und ein Klassiker unter den Ablehnungsgründen
• Es gibt keine Testzugangsdaten für die Prüfer
• Datenschutzangaben stimmen nicht mit dem überein, was die App tatsächlich tut

Planen Sie für den ersten Veröffentlichungsvorgang zwei Wochen ein, nicht zwei Tage. Bei den Folgeversionen geht es dann schnell.

Was danach kommt

Beide Plattformen verlangen regelmäßig, dass Apps gegen eine aktuelle Version des Betriebssystems gebaut sind. Wer das versäumt, kann irgendwann keine Aktualisierung mehr einreichen. Das heißt konkret: Auch eine App, an der Sie fachlich nichts ändern, braucht ein- bis zweimal im Jahr Zuwendung.

Rechnen Sie dafür mit etwa fünfzehn bis zwanzig Prozent der ursprünglichen Entwicklungskosten pro Jahr. Bei einer App für 40.000 € sind das 6.000 bis 8.000 € jährlich – für Systemaktualisierungen, Bibliotheken, Fehlerbehebungen und kleine Anpassungen. Dieser Posten fehlt in fast jeder ersten Kalkulation, und er ist der häufigste Grund, warum Apps nach zwei Jahren aus den Stores verschwinden.

Was eine App wirklich kostet

Die Spannen am deutschen Markt liegen grob bei:

• Einfaches MVP, eine Plattform, wenige Bildschirme, bestehendes Backend: ab etwa 15.000 bis 25.000 €
• Mittelkomplexe App, beide Plattformen, Konten, Offline-Fähigkeit, Push: etwa 35.000 bis 80.000 €
• Umfangreiche Anwendung mit Fachlogik, Schnittstellen und mehreren Nutzergruppen: ab 80.000 €

Was diese Zahlen treibt, ist selten die Anzahl der Bildschirme. Es sind vier andere Dinge: Offline-Fähigkeit, Nutzergruppen, Schnittstellen und Push-Nachrichten.

Offline-Fähigkeit ist der größte einzelne Kostentreiber. Eine App, die Daten nur anzeigt, wenn Netz da ist, ist ein überschaubares Projekt. Eine App, in der eine Betreuungskraft im Keller ohne Empfang Zeiten erfasst, die später zuverlässig synchronisiert werden – das ist eine andere Größenordnung. Es geht nicht ums Zwischenspeichern, sondern um Konflikte: Zwei Geräte ändern denselben Datensatz, wer gewinnt? Diese Frage ist fachlich zu beantworten, nicht technisch.

Push-Nachrichten klingen nach einer Funktion und sind ein kleines Teilsystem: Geräteverwaltung, Einstellungen pro Nutzer, Ruhezeiten, Bündelung, Zustellung auch dann, wenn die App geschlossen ist, und der Umgang mit Geräten, die es nicht mehr gibt.

Unser Vorgehen

Bei Ayla, unserer App zum Babyschlaf, war die Entscheidung eindeutig: Verbraucherprodukt, iOS zuerst, weil dort die Zahlungsbereitschaft höher ist. Bei CyberNotruf zählte, dass die App im Ernstfall sofort verfügbar ist – also Android, wo die Zielgruppe sitzt.

Bei Geschäftsanwendungen für Betreuungsdienste und Kitas ist es fast immer plattformübergreifend. Die Mitarbeitenden bringen ihre eigenen Geräte mit, beide Plattformen müssen bedient werden, und das Budget verträgt keine doppelte Entwicklung. Die Funktionen – Listen, Formulare, Zeiterfassung, Nachrichten – profitieren nicht von nativer Entwicklung.

Die drei Fragen vor der Entscheidung

Wenn Sie vor der Wahl stehen, beantworten Sie diese drei Fragen, bevor Sie über Technik sprechen:

1. Muss die App ohne Netz funktionieren? Wenn ja, wird es deutlich teurer – und Sie sollten genau wissen, welche Teile offline funktionieren müssen und welche nicht.
2. Brauchen Sie wirklich beide Plattformen ab dem ersten Tag? Meistens nicht. Eine Plattform, die gut funktioniert, bringt mehr als zwei mittelmäßige.
3. Wer soll die App in drei Jahren pflegen? Diese Antwort bestimmt die Technologiewahl mehr als alles andere. Eine Technik, für die Sie regional niemanden finden, ist die falsche – unabhängig davon, wie gut sie ist.

Die dritte Frage wird am seltensten gestellt und rächt sich am härtesten.

Offline: der Kostentreiber im Detail

Weil dieser Punkt so viel Budget bewegt, lohnt ein genauerer Blick. Offline-Fähigkeit bedeutet je nach Anspruch drei sehr verschiedene Dinge.

Stufe eins: Lesen ohne Netz. Zuletzt geladene Daten bleiben sichtbar. Das ist überschaubar – ein lokaler Zwischenspeicher, der beim Start aktualisiert wird. Wenige Tage Aufwand.

Stufe zwei: Erfassen ohne Netz. Eingaben werden lokal gespeichert und später übertragen. Jetzt braucht es eine Warteschlange, einen Wiederholungsmechanismus und eine Anzeige, die ehrlich sagt, was bereits übertragen ist. Zwei bis vier Wochen, je nach Umfang.

Stufe drei: Vollständig arbeiten ohne Netz, mit mehreren Geräten. Hier kommt das eigentliche Problem: Zwei Betreuungskräfte ändern denselben Einsatz, beide offline, beide synchronisieren später. Wer gewinnt?

Diese Frage ist nicht technisch zu beantworten. Sie ist fachlich zu beantworten, und zwar für jeden Datentyp einzeln. Bei einer Zeiterfassung gilt vielleicht: beide Einträge behalten, die Leitung entscheidet. Bei einer Stammdatenänderung eher: die spätere gewinnt. Bei einer Dokumentation womöglich: nichts überschreiben, alles anhängen.

Wer Stufe drei braucht, sollte damit rechnen, dass allein die Synchronisierung so viel kostet wie ein kleines Nebenprojekt. Wer sie nicht wirklich braucht, sollte bei Stufe zwei bleiben. Der Unterschied im Angebot liegt schnell bei 15.000 €.

Barrierefreiheit: früher einplanen als gedacht

Bei Apps für den öffentlichen Sektor ist Barrierefreiheit Pflicht. Im privaten Bereich ist sie es zunehmend auch – und unabhängig davon betrifft sie mehr Nutzer, als die meisten annehmen: Menschen mit eingeschränktem Sehvermögen, ältere Nutzer, Menschen mit motorischen Einschränkungen.

Das Gute: Die Grundlagen kosten fast nichts, wenn man sie von Anfang an mitdenkt. Ausreichender Kontrast, vernünftige Berührungsflächen, sinnvolle Beschriftungen für Vorlesefunktionen, keine reine Farbcodierung für wichtige Zustände, Unterstützung für vergrößerte Systemschrift.

Das Unangenehme: Nachträglich eingebaut, betrifft es jeden Bildschirm. Wir rechnen mit etwa fünf Prozent Mehraufwand, wenn es von Beginn an gilt – und mit dem Zehnfachen davon, wenn es nachträglich gefordert wird.

Besonders der letzte Punkt oben wird unterschätzt. Eine App, deren Layout bei doppelter Systemschriftgröße auseinanderfällt, ist für einen erheblichen Teil älterer Nutzer unbenutzbar – und das fällt im Test auf dem Gerät des Entwicklers nie auf.

Testgeräte und Vorabverteilung

Ein Punkt, der in Angeboten fehlt und Zeit kostet: Wie kommt die App vor der Veröffentlichung zu den Testern?

Beide Plattformen haben dafür eigene Wege, und beide brauchen Einrichtung. Bei Apple läuft es über einen Testdienst, bei dem externe Tester eine eigene, kürzere Prüfung durchlaufen. Bei Google gibt es gestufte Testspuren. In beiden Fällen gilt: Der erste Durchlauf kostet einen halben bis ganzen Tag, danach ist es Routine.

Zu den Testgeräten: Ein Emulator reicht nicht. Mindestens ein echtes Gerät je Plattform gehört dazu, und zwar eher ein älteres als das neueste. Die Fehler, die Nutzer melden, treten auf drei Jahre alten Telefonen mit vollem Speicher auf, nicht auf dem aktuellen Modell im Büro.

Was die Zeitplanung wirklich bestimmt

Die Entwicklungsdauer einer App wird selten von der Anzahl der Bildschirme bestimmt. Vier andere Dinge treiben sie:

Abhängigkeiten von Dritten. Eine Schnittstelle zu einem Warenwirtschaftssystem, die es noch nicht gibt. Ein Zahlungsanbieter, dessen Freigabeprozess drei Wochen dauert. Ein Kunde, der Testzugänge zu einem Altsystem beschaffen muss. Diese Wartezeiten stehen in keinem Entwicklungsplan und verschieben trotzdem Termine.

Entscheidungswege beim Auftraggeber. Wenn jede Rückmeldung durch drei Ebenen muss, dauert eine Freigabe zwei Wochen statt zwei Tagen. Bei acht Freigaben im Projekt sind das drei Monate Unterschied.

Inhalte. Texte, Bilder, Logos, Rechtstexte, Stammdaten. Der häufigste Grund, warum eine fertige App nicht veröffentlicht wird, ist nicht Technik – es ist ein fehlender Datenschutztext.

Der Veröffentlichungsvorgang selbst. Konten, Zertifikate, D-U-N-S-Nummer, erste Prüfung. Zwei bis vier Wochen, wenn man früh anfängt. Deutlich mehr, wenn man es ans Ende schiebt.

Wer diese vier Punkte im Projektplan sichtbar macht, statt sie unter Entwicklung zu verstecken, bekommt einen Termin, der hält.

Woran Sie ein belastbares Angebot erkennen

Wenn Ihnen jemand eine App anbietet, prüfen Sie, ob diese sechs Punkte darin einzeln benannt sind:

1. Welche Plattformen, in welcher Reihenfolge, ab welcher Systemversion
2. Was offline funktionieren muss – und was ausdrücklich nicht
3. Wer die Store-Konten hält und wer die Veröffentlichung übernimmt
4. Ob Push-Nachrichten enthalten sind und in welchem Umfang
5. Was nach der Veröffentlichung passiert und was das im Jahr kostet
6. Auf wen die Nutzungsrechte am Quellcode übergehen

Fehlt einer dieser Punkte, fehlt er nicht aus Versehen. Er fehlt, weil er Geld kostet und im Vergleich schlecht aussieht.

Ein Angebot, das bei allen sechs Punkten konkret wird, ist fast immer das ehrlichere – auch wenn es auf den ersten Blick teurer wirkt.