App entwickeln lassen: Wann sich eine native App lohnt

Worum es geht

Es gibt einen Satz, der in Projektbesprechungen erstaunlich früh fällt, meist bevor jemand gefragt hat, welches Problem eigentlich gelöst werden soll: Wir brauchen auch eine App. Er klingt nach Fortschritt, nach Nähe zu den Nutzerinnen und Nutzern, nach einem Platz auf dem Smartphone zwischen Onlinebanking und Wetterbericht. Wer dann nachfragt, was die App können soll, das die Website nicht kann, erntet häufig ein kurzes Schweigen und danach eine Aufzählung dessen, was die Internetpräsenz längst kann: Termine, Programm, Anfahrt, Anmeldung, Neuigkeiten.

Das ist kein Vorwurf. Eine App im Store besitzt eine Strahlkraft, die einer Webadresse fehlt, ungefähr so, wie ein Messingschild neben der Eingangstür mehr hermacht als ein Eintrag im Telefonbuch. Nur bezahlt man dieses Schild nicht einmal, sondern jedes Jahr aufs Neue. Ob sich eine App lohnt, entscheidet sich deshalb selten am Tag ihrer Veröffentlichung. Es entscheidet sich im zweiten, dritten und vierten Jahr.

Eine native App wird für ein bestimmtes Betriebssystem entwickelt und über dessen Store verteilt: für iOS klassischerweise in Swift, für Android in Kotlin, oder mit plattformübergreifenden Frameworks wie Flutter und React Native, die beide Welten aus einer gemeinsamen Codebasis bedienen. Sie hat den direktesten Zugriff auf Hardware und Systemfunktionen. Und sie lebt nach den Regeln von Apple und Google, mit allem, was dazugehört.

Eine Web-App läuft im Browser, unter einer Adresse, auf jedem Gerät, ohne Installation. Die Progressive Web App (PWA) ist eine Web-App mit einigen Fähigkeiten, die früher Apps vorbehalten waren: Sie lässt sich auf dem Homescreen ablegen, startet ohne Browserleiste, kann mit Service Workern auch offline funktionieren und Push-Mitteilungen senden. Dass das Web hier längst aufgeholt hat, ist keine neue Erkenntnis. Neu ist, wie klein der Unterschied für die Nutzenden inzwischen geworden ist, während er für die Budgets erheblich bleibt.

Eine App ist kein Produkt, das man einmal herstellt und dann ins Regal stellt. Apple nimmt seit dem 28. April 2026 in App Store Connect nur noch Builds an, die mit Xcode 26 und dem iOS-26-SDK erstellt wurden, und hebt diese Mindestanforderung regelmäßig an, bislang etwa im Jahresrhythmus. Selbst eine kleine Fehlerkorrektur setzt also voraus, dass die App zuerst auf die aktuelle Werkzeugkette gebracht wird.

Google knüpft die Sichtbarkeit an das Ziel-API-Level: Neue Apps und Updates müssen eine Android-Version ansteuern, die höchstens ein Jahr hinter der jüngsten liegt, und bestehende Apps, deren Ziel-API-Level mehr als zwei Jahre zurückliegt, werden Nutzenden auf neueren Android-Geräten nicht mehr angeboten. Um technische Pflichtupdates kommt deshalb keine App herum, die aktuell und auffindbar bleiben soll, obschon sich inhaltlich nichts an ihr ändert. Bestellt hat sie niemand, bezahlt werden sie trotzdem.

Dazu kommt die Testmatrix. Bildschirmgrößen, Dunkelmodus und vergrößerte Systemschrift muss auch eine gute Website abdecken; mit der App kommen zwei weitere Oberflächen hinzu, jede mit eigenen Systemversionen, Eigenheiten und Fehlerquellen. Und jede neue App-Version durchläuft die Store-Prüfung von Apple und Google. Meist geht das zügig, planbar auf die Stunde ist es nicht. Inhalte, die eine gut konzipierte App von einem Server lädt, etwa ein verlegter Raum oder eine geänderte Anfangszeit, erscheinen auch ohne neue Version. Ein Fehler im Code der App dagegen wartet auf die Freigabe, während er auf einer Website in Minuten behoben wäre. Für Anwendungen, die an einem bestimmten Stichtag funktionieren müssen, ist das ein Risiko, das im Projektplan selten auftaucht.

Der Homescreen ist eine geschlossene Gesellschaft. Wer eine Website nutzen will, tippt auf einen Link. Wer eine App nutzen will, muss den Store öffnen, die richtige App finden und installieren, häufig noch ein Konto anlegen und Mitteilungen erlauben. Jeder dieser Schritte ist klein, zusammen bilden sie eine Download-Hürde, an der ein Teil des Publikums schlicht nicht ankommt. Das trifft vor allem Anwendungen, die nur selten oder zu einem bestimmten Anlass gebraucht werden: Aus Sicht der Nutzenden lohnt sich der Aufwand für sie am wenigsten.

Bei Veranstaltungs-Apps lässt sich das beziffern. Eine Befragung von Eventsforce aus dem Jahr 2019 unter mehr als 190 Veranstaltungsprofis in den USA und Großbritannien ergab, dass die meisten Event-Apps eine Nutzungsquote von 50 bis 75 Prozent erreichen. Die Mehrheit der Teilnehmenden lädt die App erst am Tag vor der Veranstaltung oder am Veranstaltungstag selbst herunter, und zwei Drittel der Veranstalter sehen in der App keinen Nutzen mehr, sobald die Veranstaltung vorbei ist (1). Ein Viertel bis die Hälfte des Publikums erreicht die App also gar nicht, und wer sie installiert, holt sie sich spät.

Am deutlichsten zeigt sich das Missverhältnis bei Apps, die nur an wenigen Tagen gebraucht werden: für eine Messe, ein Festival, eine Tagung, ein Jubiläum oder ein Sportereignis. Sie werden individuell für zwei Plattformen entwickelt, auf Dutzenden Geräten getestet und durch die Store-Prüfung gebracht, um dann kurz und intensiv genutzt zu werden. Den Rest des Jahres ruhen sie als Icon, das irgendwann einer Aufräumaktion zum Opfer fällt, und verlangen trotzdem dieselben Pflichtupdates wie jede andere App. Die Kosten fallen ganzjährig an, der Nutzen an einer Handvoll Tagen: Saisonsoftware im Ganzjahresbetrieb.

Hinzu kommt, dass vieles rund um solche Termine ohnehin am Rechner erledigt wird. Anmeldung, Vorbereitung, Reiseplanung und Nachlese finden eher im Büro statt als unterwegs auf dem Smartphone. Die Webanwendung muss also so oder so gut sein, und die App daneben bildet eine doppelte Infrastruktur, deren zweite Hälfte vor allem repräsentiert.

Apple hat die Kernfrage übrigens selbst aufgeschrieben. Die App Store Review Guidelines verlangen in Abschnitt 4.2, dass eine App Funktionen, Inhalte und eine Oberfläche bietet, die über eine repackaged website hinausgehen; Apps, die das nicht leisten, riskieren die Ablehnung. Daraus kann ein merkwürdiger Anreiz entstehen: Funktionen zu ergänzen, die vor allem der Zulassung dienen und weniger den Nutzenden. Eine Funktionsinflation, deren eigentliches Publikum der Reviewer ist.

Kurze Nutzungsdauer allein ist allerdings noch kein Beleg für geringen Nutzen. Drei intensive Tage können eine App rechtfertigen, wenn sie dort etwas leistet, das eine Website nicht gut kann, etwa zuverlässig offline in einer Messehalle ohne Empfang oder mit einer Indoor-Navigation über Bluetooth-Beacons. Und wer auf eine bestehende Veranstaltungsplattform setzt, die viele Veranstalter gemeinsam nutzen, verteilt die Pflege auf viele Schultern. Für die eigens entwickelte App, die vor allem das Programm der Website zeigt, gilt beides nicht.

Das Prestige-Argument ist real und sollte ernst genommen werden. In der Eventsforce-Befragung nannten die Veranstalter zwar vor allem die Beteiligung der Teilnehmenden als Grund für ihre App, 81 Prozent insgesamt. Knapp ein Drittel gab aber auch an, dass das Publikum eine App schlicht erwartet (1). Sponsoren schätzen die Präsenz in der App, Teilnehmende kennen Apps von anderen Veranstaltungen, und eine Organisation, die keine App hat, wirkt auf manche weniger digital.

Nur ist Erwartung noch keine Nutzung. In vielen Organisationen ist die App weniger Werkzeug als Statussymbol: Sie zeigt, dass man mithalten kann. Daran ist nichts Verwerfliches, solange man das Symbol als solches bilanziert. Die ehrliche Kennzahl lautet aktive Nutzende geteilt durch Teilnehmende, und daneben gehören die jährlichen Kosten für Pflege, Tests und Store-Vorgaben. Legt man beide Zahlen nebeneinander, fällt die Entscheidung meist schon beim Hinsehen.

Es gibt sie, die guten Gründe für eine native App. Einer ist die Nutzungsfrequenz: Wer eine Anwendung täglich oder wöchentlich öffnet, profitiert immer wieder von dem, was native Apps oft besser können, vom schnelleren Start über die flüssigere Bedienung bis zur tieferen Einbindung ins System. Jeder kleine Vorteil vervielfacht sich mit jeder Nutzung, und damit rechnet sich der Aufwand. Ein weiterer ist der Hardwarezugriff: Bluetooth-Geräte, Standortbestimmung im Hintergrund, Sensoren, Augmented Reality oder rechenintensive Darstellung gelingen nativ zuverlässiger, als es der Browser heute erlaubt. Der dritte betrifft Mitteilungen: Wenn Push-Nachrichten an ein breites Publikum das Herzstück sind, ist die native App auf iOS im Vorteil, weil Web-Push dort eine zusätzliche Hürde hat.

Weniger überzeugend sind dagegen viele Argumente, die in Projekten häufig fallen. QR-Codes scannen gelingt inzwischen auch im Browser. Ein digitaler Mitgliedsausweis passt als Pass in die Wallet, ohne dass dafür eine App installiert werden muss. Und der Store als Vertriebskanal bringt Organisationen wie Verbänden oder Veranstaltern kaum neue Nutzende; gefunden werden sie über ihre Mitglieder, ihre Mailings und ihre Internetpräsenz, nicht über die Suche im App Store.

Seit iOS 16.4, erschienen im Frühjahr 2023, können auch auf iPhone und iPad Web-Apps, die auf dem Homescreen abgelegt wurden, Push-Mitteilungen empfangen. Sie nutzen dafür denselben Push-Dienst wie native Apps, eine Mitgliedschaft im Apple Developer Program ist nicht nötig, und auch das kleine Zahlen-Badge am Icon funktioniert (2). Unter Android ist das ohnehin seit Langem möglich. Eine PWA wird direkt von der Website aus installiert, lässt sich ohne Store-Freigabe aktualisieren und beruht auf einer einzigen Codebasis. Für eine Veranstaltung heißt das: ein QR-Code auf Ticket oder Namensschild, der das persönliche Programm öffnet, und wer möchte, legt es sich auf den Homescreen.

Die Einschränkungen gehören zur Wahrheit. Web-Push auf iOS setzt voraus, dass die Web-App zuvor auf dem Homescreen abgelegt wurde, ein Schritt, den viele nicht kennen. Offlinefähigkeit und Update-Verhalten wollen gezielt konzipiert sein, sie entstehen nicht von selbst. Und auch das Web ist nicht frei von Plattformabhängigkeit: Im Februar 2024 kündigte Apple an, Homescreen-Web-Apps in der EU mit iOS 17.4 zu entfernen, und begründete das mit dem Digital Markets Act; nach Protesten von Entwicklern und der Aussicht auf ein Verfahren nahm das Unternehmen die Entscheidung am 1. März 2024 zurück (3). Die Abhängigkeit ist kleiner als bei einer nativen App, verschwunden ist sie nicht. Der Kern bleibt aber in jedem Fall über eine Adresse erreichbar.

Fällt die Entscheidung für eine native App, sollte sie auf derselben Datenbasis und denselben Schnittstellen aufsetzen wie die Website. Inhalte werden dann nur einmal gepflegt, die App wird zur zusätzlichen Oberfläche statt zum zweiten System, und die Folgekosten bleiben in einem Rahmen, den man im vierten Jahr noch erklären kann. Bleibt die Frage, mit der jedes App-Projekt beginnen sollte: Welchen konkreten Vorteil bietet die App gegenüber einer guten mobilen Website, und rechtfertigt dieser Vorteil ihre Folgekosten über Jahre? Wer darauf eine überzeugende Antwort hat, sollte entwickeln, und zwar gründlich. Wer keine hat, investiert in ein Symbol. Eine App, die nur die Website spiegelt, ist das teuerste Lesezeichen, das sich eine Organisation leisten kann.