Share with your friends










Submit
CrossPlatform

Die beiden vorherrschenden Entwicklungsansätze

Weil der Markt für mobile Endgeräte so heterogen und dynamisch ist, stellt es eine gewaltige und sich ständig erneuernde Herausforderung bei der App-Entwicklung dar, verschiedene Plattformen, Betriebssysteme und -versionen abzudecken. Mobile App-Entwicklung gilt deshalb als schwierig und teuer, und hat auch sonst nicht den besten Ruf.

Die beiden aktuell vorherrschenden Ansätze sind der Silo- und der Magic-Box-Ansatz, jeweils mit spezifischen Vor- und Nachteilen.

Der ‘Silo-Ansatz’ (oder: Schreibe diesselbe App mehrmals.)

Aktuell ist der gebräuchlichSiloste Ansatz der, eine App komplett neu zu schreiben für jede mobile Plattform, die unterstützt werden soll. Es ist gebräuchlich, dass es eine iOS-, eine Android- und evtl. eine WinPhone-App gibt, jede mit ihrer eigenen Codebasis, geschrieben in der jeweils vom Hersteller vorgegebenen Sprache (Objective C/Swift, Java, C#), entwickelt von jeweils eigenen Entwicklungsteams.

Jede einzelne App ist also auf der technischen Ebene vollständig getrennt von allen anderen und bildet ein sog. Silo. Anders ausgedrückt: Sie erfordert einen komplett eigenen Satz von Ressourcen (Entwickler, Knowhow, Tools, Programmiersprache etc.). Das nebenstehende Bild illustriert diesen Ansatz.

Die wichtigsten Vorteile dieser Herangehensweise sind:

  • Alle plattform-spezifischen Features können jeweils vollständig genutzt werden.
  • Man erhält eine zu 100% native User-Experience [1].
  • Die Performance der so entwickelten App reizt die Möglichkeiten der jeweiligen Plattform voll aus und ist allen anderen Entwicklungsansätzen überlegen [2].

Dem gegenüber stehen folgende Nachteile:

  • Der Code der Anwendung erfordert einen sehr hohen Wartungsaufwand.
  • Durch die Erfordernis, mehrere Code-Projekte parallel zu halten und zu warten, ist im Vergleich zu “herkömmlichen” Anwendungen (etwa einem Windows-Programm oder einer Web-Anwendung) die Fehlerwahrscheinlichkeit deutlich erhöht.
  • Die beiden vorigen Punkte machen diese Art der App-Entwicklung extrem kostenintensiv.
  • Zudem ergibt sich daraus eine relativ lange Time-to-Market.
  • Soll eine neue Plattform unterstützt werden, so muss die App ein weiteres Mal komplett neu geschrieben werden.
  • Es entsteht eine gefährlich enge Bindung an den jeweiligen Hersteller [3].

Der ‘Magic Box-Ansatz’ (oder: Einmal entwickelt, läuft auf allen Geräten.)

Die Idee hinMagic Boxter diesem Ansatz klingt zunächst bestechend: Man schreibt die App einmal und schickt sie dann durch eine “magische Box”, welche die App dann für die verschiedenen Plattformen und Formfaktoren jeweils entsprechend aufbereitet. Diesen Weg gehen etwa PhoneGap/Cordova, Adobe Air, Java SWING und ähnliche Cross-Platform Toolkits [4].

Die wesentlichen Vorteile dieser Art der App-Entwicklung sind denn auch vor allem wirtschaftlicher Natur:

  • Der Entwicklungsaufwand ist im Vergleich zum oben beschriebenen Silo-Ansatz deutlich geringer.
  • Dadurch ist diese Form der Entwicklung deutlich kostengünstiger.
  • Ebenso resultiert daraus eine relativ gesehen wesentlich kürzere Time-to-Market.

Jedoch ergeben sich auch eine Reihe von gewichtigen Nachteilen überwiegend technischer Natur:

  • Das Feature-Set der so entwickelten App ist recht limitiert. Es beschränkt sich auf den kleinsten gemeinsamen Nenner aller angesprochenen Plattformen.
  • Dadurch bleibt die User Experience deutlich hinter dem eigentlich Möglichen zurück [5].
  • Ebenso ist die Performance der resultierenden App wenig überzeugend [6].
  • Evtl. auf allen Plattformen vorhandene, aber verschieden implementierte Features können nicht genutzt werden.

Als Fazit kann man festhalten, dass die traditionellen Entwicklungs-Ansätze für mobile Apps entweder technisch sehr schnell an ihre Grenzen stoßen oder, gerade für kleinere und mittlere Unternehmen, völlig unwirtschaftlich sind. Die nächste Seite zeigt mit Xamarin einen alternativen und vielversprechenden Ansatz, mit dessen Hilfe den genannten Problemen begegnet werden kann.

Der ZielmarktEntwicklung mit Xamarin




Referenzen und Anmerkungen

[1] Dies ist ein entscheidender Punkt, da sich – besonders im Bereich der mobilen Anwendungen – gezeigt hat, dass der Erfolg einer App sehr stark davon abhängt, dass sie sich für den User vertraut “anfühlt” und sich so bedienen läßt, wie er es von anderen Apps der jeweiligen Plattform gewohnt ist. Siehe z.B. hier.
[2] Die Performance einer App ist ebenso wichtig. Genau wie bei der allgemeinen User Experience sind App-Benutzer auch in Performance-Fragen sehr anspruchsvoll.
[3] Der Fall Apples neuer Programmiersprache Swift zeigt, was es bedeuten kann, wenn man sich an einen Anbieter bindet und dieser plötzlich einen Richtungswechsel einschlägt: Langjährige Objective-C – Entwickler traf die Umstellung wie ein Blitz aus heiterem Himmel. Und auch Java-Entwickler könnten auf der Android-Plattform ein ähnliches Schicksal erleben: Google streitet mit Oracle um die Oberhoheit bezüglich aller Angelegenheiten rund um Java – und hat mit go/golang bereits eine alternative Programmiersprache in der Schublade. Auch hier gilt es, die weitere Entwicklung genau zu beobachten.
[4] Als extreme Ausprägung dieses Prinzips kann auch eine Webanwendung mit Responsive Design gelten. Obwohl naturgemäß in ihren Anwendungsmöglichkeiten recht limitiert, gibt es durchaus sinnvolle Anwendungsfälle – etwa in der Produktion, wenn nur relativ einfach strukturierte Daten erfasst werden sollen, wie etwa Lagerbestände oder Transportwege, oder wenn es hauptsächlich um die Darstellung von statischen Inhalten (z.B. Text/Bilder) geht.
[5] Dieses Argument ist eng verwandt mit [1]. Untersuchungen haben gezeigt, dass sich die Benutzer auch sehr stark an jeweils plattformspezifischen Schlüsselreizen (Icons, Menüs, Control-Anordnungen usw.) orientieren.
[6] Siehe z.B. hier: Mobile Development Platform Performance (Native, Cordova, Classic Xamarin, Xamarin.Forms) (multi-part) und Mobile App Performance Redux.