Was kostet eigentlich eine App? – 9 Aufwandstreiber, die fast niemand auf dem Schirm hat

Kurz & knapp: Worum geht's?

1. Mobile Apps für Smartphone & Tablet.
2. Warum immer mehr als eine Variante einer App entwickelt wird.
3. First Things First: Worauf im Vorfeld der App-Entwicklung geachtet werden sollte.
4. Warum App-Kosten von Servern und Netzkommunikation abhängen.
5. Nicht immer ist eine App die beste Lösung.

Viele Unternehmen treten an uns heran und wünschen sich eine App – entweder als nettes Add-On für ihre Kunden oder als Hauptgeschäftsmodell. Eine der ersten Fragen, die uns gestellt wird, ist die nach dem Preis: Was kostet eigentlich eine App? Unsere Antwort ist regelmäßig: Das kommt darauf an…

Jede App hat andere Anforderungen, daher lässt sich keine pauschale Aussage über die Kosten einer App treffen. Dabei bestimmt die Komplexität der Anwendungsfälle den preislichen Rahmen. Je konkreter solche Anwendungsfälle im Vorfeld definiert werden, desto sicherer lässt sich der Aufwand einschätzen.

Wir beleuchten neun Aufwandstreiber, die uns regelmäßig im Entwicklungsalltag begegnen, um bösen Überraschungen bei App-Angeboten vorzubeugen.

Hier geht’s zum Business Breakfast von Konstantin Diener zum Thema “Was kostet eigentlich eine App?“:

Web-Anwendung versus App

Apps sind ohne Frage eine smarte Lösung und eine Bereicherung für viele Anwendungsfälle. Allerdings sollte man schon während der Konzeptionsphase überlegen, welchen Mehrwert eine App gegenüber einer Web-Anwendung hat. Es gibt durchaus Szenarien, bei denen Web-Apps sinnvoller sind. Dabei gibt es zwei wichtige Punkte zu beachten:

1. Nutzer haben andere Benutzungsmuster in Web-Anwendungen. Die Desktop-Variante der Navigator-App der Deutschen Bahn beispielsweise, hat eine klare User Journey für mobile Anwendungen. Nutzer überprüfen damit ihre Zugverbindungen und schauen, wo ihr Sitzplatz ist. Obwohl sie genauso gut Tickets über die App buchen können, ist der klassische Anwendungsfall eher der eines elektronischen Fahrtbegleiters.
2. Bei eigenständigen mobilen Anwendungen gibt es bestimmte Use Cases zu beachten, die es bei Web-Anwendungen nicht gibt. Apps werden überwiegend für Smartphones entwickelt. Und auch wenn sie smart sind, in erster Linie sind diese kleinen Multitalente nach wie vor Telefone. Eingehende Anrufe haben daher betriebssystemseitig die höchste Priorität und lassen nicht zu, dass Anwendungen das Telefonsignal überlagern. Was passiert also mit der Anwendung während eines Anrufs? Wird sie sofort gestoppt, wenn man gerade mitten in einem spannenden Hörbuch steckt und einen Anruf entgegennimmt? Im schlechtesten Fall läuft das Hörbuch im Hintergrund weiter, die Nutzer telefonieren eine halbe Stunde und ärgern sich, weil sie zum Weiterhören erst mühsam die richtige Stelle heraussuchen müssen. Selbst ausgereifte Apps haben Probleme mit eingehenden Anrufen: Bei einem eingehenden Telefonanruf wird die Nutzung mancher Apps einfach unterbrochen, unabhängig davon, ob man den Telefonanruf annimmt oder nicht. Weitere Use Cases, die die Anwendung unterbrechen sind beispielsweise ein leerer Akku oder eine beeinträchtigte Netzwerk-Verbindung zwischen Endgeräten.

Wie finanziert sich die App?

Im Zusammenhang mit der Frage nach dem Mehrwert einer App darf man die Monetarisierung nicht außen vor lassen. Schließlich müssen sich die entstandenen Entwicklungskosten rentieren. Um die Investitionskosten der App auszugleichen, gibt es unterschiedliche Geschäftsmodelle. Bevorzugte Monetarisierungsmethoden sind bezahlte Downloads, In-App-Käufe und In-App-Werbung.

Bezahlte Downloads Ein naheliegendes Erlösmodell ist der direkte Verkauf des Produktes. Es gibt jedoch einen starken Trend Richtung Gratis-Apps. Nutzer geben nur ungern Geld für eine App aus. Hinzu kommen ordentliche Provisionen zwischen 15 – 30 %, die die jeweilige Vertriebsplattform kassiert.

In-App-Käufe Bei diesem Geschäftsmodell bleibt die eigentliche App gratis. Weitere Features innerhalb der App werden kostenpflichtig. Ähnlich zu dem Modell sind auch sogenannte Freemium-Apps. Hierbei wird eine Basisversion der App zur Verfügung gestellt, die Nutzern einen kostenfreien Einblick in die App ermöglichen. Gezahlt wird erst, wenn sie den vollen Funktionsumfang der App benötigen.

In-App-Werbung Eine andere Möglichkeit ist die Schaltung von Werbeanzeigen innerhalb der App. Als App-Betreiber gilt es sicherzustellen, dass die Werbung nicht als zu störend wahrgenommen wird.

Apps sind nicht immer die effizienteste Lösung für eine Anwendungsidee. Maßgeblich für die Entscheidung für beziehungsweise gegen eine App ist die Frage nach ihrem Mehrwert. Das Erlösmodell sollte in Abhängigkeit zur Art der App, sowie der Branche und der Zielgruppe ausgewählt werden. Lassen sich Use Cases sinnvoll in das Format einer App übertragen, steht der App-Entwicklung nichts mehr im Weg – oder?

Rahmenbedingungen: Über Plattformen, Displaygrößen und Betriebssystemversionen

Ist die Entscheidung für die App-Entwicklung erst mal gefallen und die Monetarisierungsstrategie ausgearbeitet, geht es an die Planung der Rahmenbedingungen. Woran denken wir als erstes beim Stichwort Apps? Zunächst mal ans eigene Handy. Dabei gibt es jenseits vom Smartphone auch Apps für Tablets oder gar Smartwatches, die bei der Entwicklung einer App ebenfalls zur Debatte stehen. Die Endgeräte unterscheiden sich deutlich hinsichtlich Hardware und Displaygröße. Dies führt pro zu berücksichtigendem Gerätetyp zu Mehraufwand. Zudem spielt die Ausrichtung des Bildschirms eine Rolle. Apps sind klassischerweise für das Hochformat optimiert. Bei Apps im Landscape-Modus kommen, je nach Gerätetyp, ganz andere Darstellungsformen zum Designentwurf hinzu, weil sich das Verhältnis von Breite zu Höhe maßgeblich ändert. Die gewonnene Breite im Landscape-Modus eröffnet ganz neue Möglichkeiten zur Anordnung einzelner Elemente. Beispielsweise kann ein Text in drei Spalten, anstatt in zwei Spalten angeordnet werden. Oder man lässt einen Chat, der im Hochformat unterhalb des Content-Bereiches lag, stattdessen an einer Seite des Inhalts erscheinen.

Auf welchem Betriebssystem soll die App laufen? Die zwei gängigen Betriebssysteme für Mobile Apps, iOS von Apple und Android von Google, haben jeweils unterschiedliche Zielgruppen und Besonderheiten. Ein kostenentscheidender Faktor sind hierbei die Betriebssystemversionen: Apple forciert sehr stark, dass alle Endgeräte, auf denen es möglich ist, auf das neueste Betriebssystem updaten. Zum Release von iOS 14, hatten gut 70% der iOS-Nutzer innerhalb der ersten zwei Monate auf das neue Betriebssystem geupdatet. Außerdem sind bei Apple Hardware- und Software-Hersteller derselbe.

Bei Android ist es anders: In der Abbildung “Installationsrate bei Android Versionen” ist zu sehen, dass zum Untersuchungszeitpunkt unter 10% der Geräte die neueste Android-Version installiert hatten, bei der Vorgängerversion waren es knapp 30 %. Es gibt derzeit noch Geräte, die mit sehr alten Android-Versionen laufen. Daher ist die Frage, wie viele Android-Nutzer die Auftraggeber mit ihrer App erreichen wollen und wie weit man dafür in der Versionshistorie zurück gehen muss. Die einzelnen Versionen bringen unterschiedliche Features mit, ältere Versionen haben dementsprechend limitierte Möglichkeiten, die aktuellen Features einzubinden. Dem kann man teilweise mit Kompatibilitäts-Kits entgegenwirken, allerdings nicht in jedem Fall.

Installationsrate bei Android Versionen. Quelle: Android Studio, 2020

Diese Versionsvielfalt rührt daher, dass Google mit Android lediglich das Betriebssystem stellt, das auf den Geräten unterschiedlicher Hersteller läuft. Daher kommt es vor, dass ein Hersteller ein neues Feature im Android-Betriebssystem nicht unterstützt. Je weiter man in der Versionshistorie zurückgeht, desto höher werden die Umsetzungskosten. Dadurch steigt gleichzeitig der Testaufwand, da das Entwicklungs-Team alle Features unter realen Bedingungen auf echten Geräten testen muss.

Schon allein bei der Wahl der Plattformen gibt es also mehrere Aufwandstreiber, die den Umfang möglicherweise unnötig aufblasen und die Kosten in die Höhe treiben.

Datenaustausch via Server bzw. Cloud

Wer kann sich heute noch ein Smartphone ohne Timer oder Taschenlampe vorstellen? Diese eigenständigen, rein lokale agierenden Apps sind mittlerweile Standardbestandteile des Betriebssystems. Heutzutage gibt es nur noch wenige dieser isoliert agierenden Apps ohne Bezug zur Außenwelt. Stattdessen besteht bei den meisten Apps eine Interaktion zwischen verschiedenen Geräten. Bei der Datenübertragung via Bluetooth oder Apples Airdrop findet ein direkter Austausch zwischen den Geräten statt, sofern die jeweilige Funktion bei beiden Geräten aktiviert ist. Contact Tracing Apps beispielsweise, wie sie im Kontext der Corona-Pandemie aufgekommen sind, nutzen die direkte Gerät-zu-Gerät-Kommunikation, um einen datensparsamen Austausch zu ermöglichen.

Anders verhält es sich, wenn man Nachrichten per WhatsApp hin- und herschickt. Zwar findet ein Austausch zwischen den Geräten statt, technisch betrachtet landet die abgesendete Nachricht aber nicht direkt im Empfängergerät, sondern macht einen Umweg über einen Server oder eine Cloud. Bei der Datenkommunikation über einen Server fordert das mobile Endgerät Informationen vom Server an oder schickt Daten an diesen. Umgekehrt kann der Server Daten initiativ an das Gerät schicken, etwa um Nutzer via Push-Benachrichtigung auf Eilmeldungen, Terminerinnerungen oder ähnliches aufmerksam zu machen.

Gerät-zu-Gerät-Kommunikation versus Serverkommunikation

Das Backend kann – je nach Projektanforderung – einen einfachen Datenspeicher oder auch eine eher komplexe Business-Logik enthalten. In beiden Punkten fallen Entwicklungs- und Wartungsaufwand an. Dazu kommt der administrative Aufwand. Was passiert, wenn Nutzer ihre Login-Daten vergessen haben oder gegen Richtlinien verstoßen? Werden sie dann ausgesperrt? Gibt es Supportpersonal, das in solchen Fällen eingreift? Die Entwicklung einer Serverumgebung, ggf. mit einer administrativen Oberfläche für Community Services, treibt den Aufwand einer App ebenfalls in die Höhe.

Netzkommunikation

Jede Art von Serverkommunikation erfolgt durch Daten-Uploads bzw. -downloads. Dafür braucht das Endgerät eine entsprechende Netzverbindung, entweder über das Wireless Local Area Network, kurz WLAN, oder über das Mobilfunknetz. In Deutschland haben die meisten Internetnutzer große Internet- und DSL-Verträge. Wer sich also ein Video anschaut, tut dies höchstwahrscheinlich über eine WLAN-Verbindung. Beim mobilen Internet hingegen ist das verfügbare Datenvolumen oft sehr gering im Vergleich zum Nutzungsbedarf. Daraus ergeben sich neue Fragen, die vor Entwicklungsbeginn zu klären sind:

• Welche Netzverbindungsbedingungen liegen vor?
• Welches Netz wird typischerweise für welche Anwendungsfälle genutzt?
• Wie viel Datenvolumen läuft über welches Netz?
• Und was passiert eigentlich, wenn die Internetverbindung mal ganz wegfällt?

Netzverbindungen zwischen Client & Server

Der Musik-Streaming-Dienst Spotify musste sich im Vorfeld genauestens Gedanken darüber machen, wie sie stabiles Musik-Streaming überall und zu jeder Zeit gewährleisten. Wie sie mit geringen Übertragungsraten umgehen, wenn beispielsweise der Zug mal wieder durch einen Tunnel fährt und das Smartphone nur noch Edge anzeigt. Aber auch, wie sie den Nutzer am besten über die gegebene Netzverbindung informieren. Denn diese verlassen sich im Zweifel auf die Aktualität der Daten. Bei On-Demand Streaming von Musik kommt der Aspekt der Offline-Speicherung hinzu. Daten offline zur Verfügung zu stellen, birgt wiederrum neue Herausforderungen:

• In welchem Netz sollen welche Downloads ausgeführt werden? Ausschließlich in einem WLAN oder WiFi?
• Gibt man dem Nutzer Bescheid, dass er gerade Daten mit mobilem Datenvolumen downloaden will?
• Soll der Download automatisch pausiert werden, sobald man das Netzwerk verlässt und automatisch weiter durchgeführt werden, wenn man wieder eine Verbindung hat?
• Und sollen Datenuploads im Cache zwischengespeichert werden, wenn die WLAN-Verbindung unterbrochen wurde?

Netzverbindungen zum Server unterbrochen

Die Offline-Fähigkeit stellt uns vor das Problem der Speicherung der Daten auf dem Gerät. In vielen Fällen geht es um geschäftskritische Assets, so auch bei unserem Beispiel Spotify. Nutzer können zwar Musik downloaden, inwieweit diese Daten allerdings zugänglich für den Nutzer sind, ist Aufgabe der Datenverschlüsselung. Dabei werden Daten wie Musikdateien, gesichert bereitgestellt, sodass sie nicht plötzlich kostenlos im Netz landen und dem Geschäft schaden. Ebenso wenig kann sich ein Unternehmen einen Datenskandal leisten, weil ein cleverer Hacker personenbezogene Nutzerdaten geklaut und veröffentlicht hat. Bei der Offline-Speicherung muss man sich genau überlegen, bis zu welchem Grad man Daten zwecks Anwendungsfall verfügbar macht. Das sind nur einige Punkte im Bereich der Netzkommunikation, die je nach Anwendungsfall durchaus komplex werden können.

Wie soll die App aussehen?

Das Thema Design verdeutlicht, dass hinter der App-Entwicklung weitaus mehr steckt als reiner Code. Bei klassischen Business-Anwendungen besteht die App meist aus einzelnen Benutzermasken bzw. Screens. Vom Start-Screen ausgehend steuert man das Menü an oder wechselt in die Einstellungen. Was den Aufwand treibt, ist neben der Anzahl an gewünschten Screens auch ihr Komplexitätsgrad. Wie umfangreich werden sie und wie viele Eingabemöglichkeiten gibt es? Wie viel Standard ist dabei erwünscht? Als Faustregel gilt: Je weiter man sich von dem standardisierten Maskenlayout entfernt, beispielsweise in Richtung Spieleentwicklung, desto komplexer wird das App-Design.

Hinzu kommen betriebssystemseitige Nutzungsgewohnheiten, sprich sehen die Masken so aus, wie es der Nutzer beispielsweise auf seinem iOS-Gerät erwartet? Dieser Teilaspekt des App-Designs hat in den letzten Jahren zwar immer mehr an Bedeutung verloren, es lassen sich dennoch feine, aber weiterhin entscheidende Unterschiede zwischen Android und iOS feststellen. Die Erinnerungen-App beider Plattformen unterscheiden sich beispielsweise hinsichtlich des Aufbaus, der Buttons, der Gesten und der Navigation durch die App. Ohne groß zu überlegen, wissen wir als Nutzer instinktiv, ob es sich um eine Anwendung von Android oder iOS handelt. Deshalb ist ein wichtiger Faktor beim App-Design, dass das Look & Feel der App zum jeweiligen Betriebssystem passt. Auf der anderen Seite stellt sich die Frage, ob ein angepasstes Design nach Plattform für die Zielsetzung relevant ist oder ob nicht eine ganz eigene User Experience die bessere Wahl ist.

Nutzungsgewohnheiten der Erinnerungen-App bei iOS & Android

Sind Cross Platform Frameworks der heilige Gral?

Natürlich wünschen sich alle unsere Kunden möglichst wenig Entwicklungsaufwand für ihr Projekt, um die Kosten niedrig zu halten. Daher empfehlen wir in geeigneten Fällen häufig, die Anwendung mithilfe sogenannter Cross Platform Frameworks zu realisieren. Sie ermöglichen plattformübergreifende App-Entwicklung – man bekommt also “zwei Apps zum Preis von einer”. Allerdings sollte man sich nicht ohne Weiteres auf solche Frameworks verlassen, vor allem wenn die native User Experience der Anwendung wichtig ist. In Themenbereichen wie Datenverschlüsselung, Hardware-naher Entwicklung oder für High-End-Performance-Anwendungsfälle entwickelt man schnell zwei eigene Apps mit unterschiedlichen User Interfaces. Flutter bietet dahingehend mittlerweile sehr viel mehr Möglichkeiten und kommt nativen Apps deutlich näher als andere Frameworks. Unserer Erfahrung nach ist Flutter besonders empfehlenswert in Puncto Kostenaufwand, User Experience und User Interface. Neben nativen Performance-Möglichkeiten bietet das Framework clevere Lösungen für batterie- und speicherschonende App-Entwicklung.

Cross Platform Frameworks sind bis dato noch nicht die geeignete Lösung für alle Vorhaben. Aber auch wenn sie noch nicht in allen Bereichen die native Performance bieten können, die sich unsere Entwickler wünschen, sind sie dank stetig hinzukommender Features und kontinuierlicher Performanceverbesserungen in vielen Anwendungsfällen eine echte Alternative zur nativen App-Entwicklung geworden.

Was kostet denn jetzt eine App?

Wenn wir die Kosten für eine App realistisch schätzen sollen, brauchen wir Informationen über die wichtigsten Faktoren, die den Entwicklungsaufwand einer App beeinflussen:

1. Anzahl unterstützter Betriebssysteme und Endgeräte 
   Wie vielen Nutzern mache ich meine App zugänglich?
2. Art der Netzverbindungen (WLAN versus Mobilfunk) 
   Wie viel Datenvolumen-Verbrauch mute ich meinen Nutzern zu?
3. App-Design
   Behalte ich das Look & Feel der jeweiligen Plattform bei oder kreiere ich ein einzigartiges Nutzererlebnis?
4. Offline-Speicherung auf dem Gerät
   Wie verschlüssele ich Daten? Wie funktioniert Caching beim Daten-Upload?
5. Anzahl und Komplexität der Benutzermasken
   Wie aufwendig ist die User Journey der App?
6. Benutzermasken versus Spiel 
   Brauchen wir überhaupt klassische Masken oder ist die App wie ein Spiel aufgebaut?
7. Spezifische Logik, rechenintensive Dinge, Hardware-nahe Entwicklung
   Welche Anforderungen stellt meine App an das Endgerät? Kommt beispielsweise Hardware wie die integrierte Kamera zum Einsatz?
8. Cross-Plattform-Entwicklung 
   Passt das zu meinem Einsatzszenario oder wird die Entwicklung dadurch teurer?
9. Wiederkehrende Kosten
   Auf welchen Distributionsplattformen läuft meine App? Welche Kosten entstehen durch die Wartung der App und des Servers?

Bei Anwendungen mit Grundfunktionen wie einem Login, einem angebundenen Backend zur Datenkommunikation, sowie einem den Bedürfnissen angepassten App-Design, kann man als grobe Hausnummer mit einem fünfstelligen Betrag rechnen. Je mehr Funktionen eine App braucht, um den Anforderungen zu entsprechen, desto höher wird der Entwicklungsaufwand und die damit verbundenen Kosten. Das sind erstmal sehr viele Überlegungen, die allerdings notwendig sind, wenn man ein möglichst wertiges Produkt zu einem angemessenen Preis erhalten möchte. Aus diesem Grund gehen wir bei cosee zuerst in die sogenannte Discovery-Phase mit unseren Kunden. Dabei handelt es sich um ein Vorgespräch im Rahmen eines Workshops, in dem wir über Zielsetzungen, Wunschvorstellungen und realistische Umsetzungsmaßnahmen sprechen. Unsere Mobile-Experten stehen beratend zur Seite und helfen aktiv, Potentiale für Kosteneinsparungen aufzudecken.

Discovery-Phase bei cosee

Bei den Discovery Workshops arbeiten wir gemeinsam mit unseren Kunden die Visionen des Produktes möglichst detailliert aus, sodass am Ende alle Beteiligten dasselbe Ziel verfolgen. Eine völlig valide Entscheidung kann nach einem solchen Workshop sein, dass sich das Erlösmodell der angestrebten App nicht mit den Investitionskosten deckt und der Kunde deshalb sein Vorhaben lieber ruhen lässt. Am Ende sollen unsere Kunden sich mit ihrer Entscheidung wohl fühlen und die Sicherheit haben, das bestmögliche Produkt zu einem fair ermittelten Preis zu erhalten.

Ihr habt eine Idee für eine mobile App-Anwendung und benötigt Hilfe bei der Realisierung? Dann vereinbart gerne einen Termin für ein kostenloses Erstgespräch.