Die Kostenfaktoren der Apperstellung
„Was kostet eine App?“ Das ist eine Frage, die man als App-Entwickler häufiger zu hören bekommt. Genauso wie auf die Frage „Was kostet ein Auto?“ kann hier die Antwort nur lauten: „Kommt drauf an!“ Worauf, das soll dieser Artikel versuchen zu umreißen. Der tatsächliche Preis hängt natürlich vom jeweiligen Dienstleister und seinen Tagessätzen ab und wie genau jeder der hier umrissenen Faktoren umgesetzt werden soll. Dieser Artikel soll helfen, sich bei der Planung über die anfallenden Kostenblöcke Gedanken machen zu können und die Kalkulation von technischen Dienstleistern besser nachzuvollziehen.
Zielplattformen
Die wichtigste Frage ist: Auf welchen Geräten soll meine App laufen?
Der Grund, warum diese Frage so wichtig ist: Auf jeder Plattform wird in einer anderen Programmiersprache und -umgebung entwickelt. Man muss also die App mehrmals entwickeln, möchte man mehrere Plattformen unterstützen. Dies ist definitiv der größte Kostenfaktor, denn es ist ein Multiplikator für die gesamten Entwicklungskosten.
Bei der Entscheidung dieser Frage hilft es, sich jeweils die aktuelle Marktverteilung anzuschauen. Die genauen Statistiken schwanken, je nachdem, wer sie erhoben/gefälscht hat, aber in einem stimmen die meisten überein: Android + iOS dominieren mit zusammen weit über 90 Prozent den Smartphone-/ Tablet-Markt. Weit, weit abgeschlagen folgen Blackberry und irgendwann Windows Phone. In der Regel lautet die Frage also: Möchte ich eine Android-App, eine iOS-App oder beides.
Aufgrund der minimalen Verbreitung der Konkurrenten beschränkt sich die weitere Betrachtung also auf iOS und Android.
Formfaktoren
Die nächste Frage ist, möchte ich meine App für Phones, Tablets oder beides anbieten? Die guten Neuigkeiten hier sind, dass man, anders als bei der Plattform-Frage, nicht gleich mit doppelten Entwicklungskosten rechnen muss, wenn man zum Beispiel sowohl iPhone und iPadunterstützen will. Ganz umsonst kommt man allerdings nicht davon. Man hat im Grunde die Wahl aus drei „Ausbaustufen“:
- Man macht gar nichts und deaktiviert den nicht gewünschten Formfaktor (meist das Tablet, Android wie iOS bieten diese Option an). Die App lässt sich nun zum Beispiel nur auf Smartphones installieren.
- Man implementiert Layouts nur für Phone-Formfaktoren, deaktiviert aber die Installation auf Tablets nicht. Die App lässt sich nun auch auf Tablets nutzen. Unter iOS geht dies über den sogenannten „Compatibility Mode“ – man hat einfach einen „Trauerrand“ um die App, damit sie auf das größere Display passt. Unter Android kann man mit intelligenten Layouts bereits einiges erreichen und den zusätzlichen Platz sinnvoll nutzen, da Android-Apps sich – bedingt durch die massive Marktfragmentierung – ohnehin an verschiedene Bildschirmgrößen anpassen müssen.
- Man setzt die Layouts für die Benutzeroberfläche zweimal um: für Tablets und Phones jeweils optimiert. Dies verdoppelt allerdings den Aufwand für das Design und die Umsetzung der Layouts.
Komplexität in der Benutzerführung: Anzahl der Layouts
Nach diesen grundlegenden Überlegungen geht es ans Eingemachte: Zunächst sollte man grob überschlagen, wie viele „Ansichten“ oder Layouts die App haben soll. Jede dieser Ansichten muss designed und das Layout dafür für jede Plattform umgesetzt werden. Man sollte also die Bedienung so einfach und intuitiv wie möglich gestalten – das schont nicht nur das Budget, es macht die App in der Regel auch benutzerfreundlicher und besser zu verstehen.
Orientierung: Landscape/Portrait
Soll die App nur im Portrait-, im Landscape- oder in beiden Modi laufen? Möchte man beide Orientierungen unterstützen, muss man meist die Layouts für jede Benutzeransicht doppelt erstellen. Dies erhöht zwar nicht den Programmieraufwand, aber den Aufwand für die Erstellung der Benutzeroberflächen. So kann abhängig von anderen Entscheidungen die Anzahl der zu implementierenden Nutzeransichten in die Höhe schnellen.
Möchte man zum Beispiel eine iOS- und Android-App mit zehn Screens sowohl für Phones als auch für Tablets in Portrait und Landscape umsetzen, müssen 2 (Plattform) * 2 (Formfaktor) * 2 (Orientierung) * 10 = 80 Layouts erstellt und programmiert werden.
Custom-UI-Elemente und Eye Candy
Wichtig bei der grafischen Umsetzung einer App ist immer die Frage, ob individuelle Bedienelemente gewünscht sind oder ob der Programmierer zur Umsetzung der Bedienung der App mit „Bordmitteln“ arbeitet. Jedes individuelle Bedienelement muss – manchmal mit einem Aufwand von mehreren Tagen – in Handarbeit erstellt werden, während es zum Beispiel nur eine Frage von ein paar Minuten ist, einen Standardbutton oder eine Liste einzubauen.
Auch bei der Verwendung von Standardkomponenten wiederum ist die Frage, wie stark sie individualisiert werden sollen und ob die gewünschte Individualisierung leicht und von der Plattform vorgesehen ist, oder ob sie Hacks und Workarounds erfordert. Drei Beispiele aus der Android-Welt:
- leicht: Button in anderer Farbe/mit anderem Hintergrund, es müssen lediglich Hintergrundgrafiken erstellt werden und zur App gepackt werden
- mittel: Button (oder Textfelder et cetera) in anderem Font als den Plattformfonts: Hierfür muss bereits ein wenig programmiert werden, Fonts müssen geladen werden et cetera
- schwer: Die Farben im Dialog zur Datumsauswahl ändern. Ein Beispiel für eine scheinbar triviale Aufgabe, die einen enormen Aufwand erfordert, da die Änderung dieser Farbe unter Android einfach nicht vorgesehen ist.
Man sieht an diesen Beispielen, wie eine handvoll grafischer Wünsche die Kalkulation deutlich beeinflussen kann. Generell empfiehlt es sich, die grafischen Anforderungen zusammen mit dem Dienstleister durchzusprechen, um die Lösung zu finden, die den besten optischen Eindruck im Rahmen der Budgetgrenzen erziehlt.
Komplexität der App-Logik
Eine der wichtigsten Fragen ist natürlich die Komplexität der Logik in der App – dies ist ein separater Kostenblock, der immer sehr individuell ist. Das Gute ist, dass dieser relativ konstant und von anderen Entscheidungen unabhängig ist – der Programmlogik ist es egal, ob ein Buttonklick außergewöhnlich aufwändig animiert wird oder nicht.
Tracking
Sehr beliebt ist der Einbau von sogenannten Tracking Frameworks in eine App. Hiermit kann der Herausgeber der App überwachen, wie seine App genutzt wird. Eine interessante Frage ist zum Beispiel, was der Nutzer gemacht hat, bevor es zu einer In-App Purchase oder zu einer Bestellung kam. Bei einer Tracking-Lösung fallen zum einen unter Umständen Lizenzkosten für das Tracking-Framework selber, als auch den Einbau des Trackings an sich an. Jede zu überwachende Aktion muss manuell mit dem Tracking „verdrahtet“ werden. Hier sollten neben Datenschutz also auch Nutzen und Kosten abgewogen werden.
App nach Hause telefonieren!: Server-Anbindung nicht vergessen
Ein Teil der Kalkulation, der eigentlich einen eigenen Artikel rechtfertigt: Fast jede App, die irgendetwas Sinnvolles macht, muss mit einem Server kommunizieren, um der Welt etwas mitzuteilen. Beispiele sind Gewinnspiele, Shops, Bestellungen aller Art, Synchronisation von Daten und Benutzerkonten und vieles mehr. Hierfür muss entweder ein komplett neuer Server entworfen, implementiert und betrieben werden (wodurch zusätzlich laufende Kosten anfallen) oder aber eine App an ein bestehendes System angebunden werden – meist ein besonders großer Posten, der oft leider nicht „auf dem Schirm“ ist.
All work and no play makes Jack a dull boy: Spiele
Spiele sind ein ganz eigenes Thema und werden in der Komplexität meist enorm unterschätzt. Die Erstellung eines professionellen Spiels, selbst im Casual-Bereich, braucht qualitativ hochwertige Grafiken und Sounds, und wenn der Spielspaß stimmen soll, ebenfalls viel Testing und Feinabstimmung. Auch ist die Programmierung oft wesentlich anspruchsvoller als bei einer „normalen“ App. Animationen, Künstliche Intelligenz für Computergegner, Effekte und vor allem eine schnelle und ruckelfreie Grafik katapultieren die Kosten schnell in den sechsstelligen Bereich. The Sky is the limit.
Ein interessanter Effekt: oft ist die Portierung auf mehrere Plattformen dann wieder erstaunlich günstig, da man mit guten Game Engines wie zum Beispiel Unity in der Tat fast plattformunabhängig und trotzdem (praktisch) nativ entwickeln kann.
Sonstiges
Es gibt noch eine ganze Reihe von Wünschen, die sich in der Kalkulation niederschlagen können. Dies können wirkliche Kleinigkeiten sein, wie zum Beispiel die Einbettung eines Barcode Readers, was in ein paar Stunden erledigt ist, oder aber ein anspruchsvoller Augmented-Reality-View, der schnell aufwändiger werden kann als der ganze Rest der App.
Typische weitere Kostenblöcke beinhalten: Facebook/Twitter/Google+ et cetera. Integration, Abspielen von Video und Audio (was durch Streaming wieder aufwändiger wird), Individuelle Touch-Gesten, Lokalisierung, lokale Datenbanken in der App, Erstellung von PDFs oder Bilddateien, Versenden von Emails, In-App Purchases, Bluetooth/ NFC/ USB/ WLAN – Anbindung von externen Geräten u.v.a.. Auch sollte bedacht werden, wer die fertige App in den/die Store(s) stellt und wer die dafür notwendigen Teaser, Grafiken und Texte in allen notwendigen Sprachen erstellt.
Wichtig: Transparente Offenlegung der Kosten
Dieser Artikel sollte einen ersten Leitfaden für die möglicherweise anfallende Posten einer App-Entwicklung geben, sodass Angebote besser eingeschätzt und im Vorfeld die Entwicklung der eigenen App besser geplant werden kann. Der eigene Dienstleister/ das Entwicklungsteam sollte eine transparente Kalkulation geben, durch welche Posten welche Kosten zustande gekommen sind, um hier gegebenenfalls Nutzen und Kosten besser abzuwägen, um gegebenenfalls durch wenige Änderungen Kosten signifikant anpassen zu können.
