1. Unterstützte mobile Plattformen

Die erste und wichtigste Entscheidung, die Unternehmen vor der Entwicklung einer mobilen Business-App treffen sollten, ist, auf welchen Plattformen die Anwendung laufen soll. Diese Entscheidung hat unmittelbare Auswirkung auf alle weiteren Entscheidungen hinsichtlich der User Experience der Anwendung, der Entwicklungsplattformen, der -geschwindigkeit und -kosten sowie zukünftiger Einsatzszenarien.

Soll die Anwendung nur auf ein oder maximal zwei Zielplattformen laufen und deckt die Anwendung selbst einen begrenzten oder fixen Funktionsumfang ab, ist eine native Entwicklung je Plattform durchaus eine sinnvolle Option. Entwicklungskosten und -geschwindigkeit sind hier in aller Regel deutlich besser. Zudem kann das User Interface (UI) spezifisch auf die Plattform ausgerichtet werden, Hardware-nahe Funktionen sind einfacher zu integrieren und Performance-Themen einfacher zu lösen.

Auf eine plattformunabhängige Entwicklung zu setzen lohnt sich dagegen umso eher, je variabler oder größer der Funktionsumfang ist, beziehungsweise sein soll. Beispiel dafür wären etwa verschiedene individuelle Kundenszenarien oder eine große Menge an Funktionen, die es über die Zeit in der App umzusetzen gilt.

Dies trifft selbstverständlich auch dann zu, wenn die Anwendung auf einer Vielfalt an Plattformen bereitgestellt werden muss. Hier sind die initialen Kosten zwar in der Regel höher als bei einer rein nativen Entwicklung, dies ändert sich dann aber mit der Zeit, da neue Funktionen im Idealfall nur einmal für alle Plattformen zu entwickeln sind.

Da Business-Anwendungen im Gegensatz zu "Consumer-Apps" in der Regel eine deutliche längere Laufzeit aufweisen, ist eine plattformunabhängige Entwicklung auch hier von Vorteil. Sie bietet Investitionssicherheit, sowohl für einen selbst als auch für die Kunden, da eine Portierung auf neue Plattformen in der Regel schneller und kostengünstiger möglich ist.

2. Hybride versus webbasierte App

Für die plattformunabhängige Entwicklung stehen im Wesentlichen zwei Möglichkeiten zur Verfügung: Auf der einen Seite gibt es hybride Systeme, in denen die eigentliche Anwendung in einem nativen Container läuft, der wiederum Zugriff auf Betriebssystem-Funktionen ermöglicht. Diese sind für jede Plattform zu schreiben, während die eigentliche Anwendung in einer plattformunabhängigen Sprache erstellt wird. Hier nimmt Cordova/PhoneGap mit JavaScript als Entwicklungssprache und HTML für das UI eine führende Position ein.

Mittlerweile gibt es mit "React Native" von Facebook einen sehr vielversprechenden neuen Ansatz, bei dem das UI nativ gerendert wird, aber dennoch weite Teile (auch des UI) in JavaScript implementiert werden können und somit einen "Best-of-both-worlds"-Ansatz bieten.

Auf der anderen Seite stehen die reinen Web-Apps, die ohne einen nativen Container im Browser laufen und dessen (eingeschränkte) Funktionen für den Zugriff auf das Betriebssystem nutzen. Dies ist für einfache Anwendungen ohne große Offline-Fähigkeit eine sehr gute Wahl. Es gibt keine Probleme mit dem Deployment und dem Update von Anwendungen. Die modernen Browser, auch auf mobilen Geräten, sind heute leistungsstark genug, um auch komplexere UIs performant darzustellen.

Mittlerweile ist es zudem auch möglich, auf wichtige betriebssystemnahe Funktionen, wie Kamera oder Geokoordinaten, per Browser zuzugreifen. Eingeschränkte Möglichkeiten zum Zwischenspeichern von Daten für Offline-Fälle sind ebenfalls kein Problem mehr.

Neben diesen beiden Varianten stehen noch Plattformen zur Verfügung, bei denen die Entwicklung in einer Programmiersprache erfolgt und der ausführbare Code von der Plattform für das jeweilige Zielbetriebssystem kompiliert wird.

Xamarin, das Anfang 2016 von Microsoft aufgekauft wurde, ist hier einer der prominentesten Vertreter. Auch wenn diese Form der plattformunabhängigen Entwicklung viele Vorteile mit sich bringt, hat sie sich noch nicht in dem breiten Maße, wie zum Beispiel Cordova, durchgesetzt. Meist sind die Möglichkeiten, das UI plattformunabhängig zu schreiben, nur begrenzt.

Des Weiteren ist man stark vom Anbieter abhängig, was insbesondere beim Aufkommen neuer Plattformen dazu führen kann, dass diese nicht oder nicht schnell unterstützt werden.

3. Zukunftssicherheit der Entwicklungssysteme

Bei der Entwicklung nativer Apps stellt sich nicht wirklich die Frage nach der Zukunftsfähigkeit, da Entwicklungssysteme der Hersteller genutzt werden. Allerdings müssen Unternehmen über Entwickler mit entsprechendem Know-how für jede einzelne Plattform (Objective C für iOS, Java für Android und C# für Windows) verfügen.

Entwicklungssysteme im Bereich Web -und Hybrid-Entwicklung sind sehr vielfältig. Große Teile an (Basis-)Bibliotheken stehen als "Open Source" zur Verfügung. Dies bedeutet Fluch und Segen zugleich, da die Auswahl zum einen schwer zu überblicken ist, es zum anderen aber auch ermöglicht, das optimale Tool zu finden und an die eigenen Bedürfnisse anzupassen.

JavaScript und HTML5 bieten als Standard im Web hohe Zukunftsfähigkeit und Investitionssicherheit in der Entwicklung. Wissen kann einfach sowohl für klassische Web-Anwendungen als auch mobil geteilt und Entwicklungs-Artefakte über die Anwendungen hinweg wiederverwendet werden.

Aktuell besteht aber noch eine hohe Dynamik in der gesamten Entwicklungs-Infrastruktur nach dem Motto: "Gestern war Angular das Framework der Wahl, heute ist es React und morgen gibt es wieder was Neues". Werkzeuge und Bibliotheken sind daher zum Teil noch nicht ausgereift und stabil.

Daher empfiehlt es sich, eine eher konservative Strategie bei der Entwicklung von Apps im Business-Bereich zu wählen und abzuwarten, bis der Hype-Zyklus Richtung "Pfad der Erleuchtung" geht. Ansonsten besteht die Gefahr, sich in eine Abhängigkeit von Herstellern zu begeben, wenn man auf integrierte Umgebungen und Frameworks setzt.

4. Entwicklungskosten

Bei einer rein nativen Entwicklung müssen Unternehmen initial mit den geringsten Kosten rechnen und erhalten sofort eine hohe Produktivität. Je mehr Plattformen unterstützt werden, desto höher sind bei diesem Ansatz allerdings die Kosten für Ressourcen, was die Anzahl der Entwickler sowie deren Recruiting und Aus- und Weiterbildung betrifft.

Bei einem Cross-Platform-Ansatz lässt sich dieser Aufwand für die Entwicklung verschiedener Plattformen zwar reduzieren. Allerdings hängt dies auch sehr von der Komplexität der Anwendung und den Anforderungen an die Widerverwendung ab. Sind diese entsprechend hoch, steigen damit auch der Aufwand und die Kosten bei einem JavaScript/HTML5-Ansatz. Besonders den initialen "Forschungsaufwand" sollten Unternehmen bei komplexen Anforderungen nicht unterschätzen.

Der große Show-Stopper bei Xamarin waren in der Vergangenheit die hohen Kosten pro Entwickler und Jahr. Nachdem Microsoft das Framework nach der Übernahme nun kostenlos zur Verfügung stellt, dürfte es zukünftig deutlich mehr Zulauf bekommen.

In allen Fällen sollten Unternehmen versuchen, schnell mit einem geringen Funktionsumfang produktiv zu gehen, um möglichst früh Feedback von der Zielgruppe in die Weiterentwicklung einfließen zu lassen.