Im Dschungel der Möglichkeiten

Es gibt Applikationen für den Windows-Desktop, Apps für die UWP, für iOS und für Android, native Apps, hybride Apps und Webapplikationen. Die Ansätze zur Entwicklung sind genauso unübersichtlich, und die Auswahloptionen scheinen unendlich. Hier deshalb ein Versuch, etwas Ordnung ins Chaos zu bringen. Ein Szenario aus der Praxis:

• Kunde: „Wir brauchen eine Software (Applikation, App, was auch immer …), um das nachfolgend beschriebene Problem zu lösen. Können Sie dazu ein Konzept und ein Angebot unterbreiten?“
• Softwareschmiede: „Welche Plattform setzen Sie denn ein? Welches Betriebssystem? Legen Sie Wert auf eine native App, oder genügt eine Web-App?“

Machen wir eine kurze Bestandsaufnahme und beginnen wir bei Windows. Windows-Desktop-Applikationen gibt es schon ewig, und jeder kennt sie. Dann gibt es Apps für die Universal Windows Platform (UWP). Interessanterweise sind diese Apps nicht nur auf der x86-Plattform lauffähig, sondern können auch auf der ARM-Architektur gestartet werden. Das wiederum ist interessant für Windows 10 IoT, wie es zum Beispiel auf dem Raspberry Pi läuft. Problem dabei: Die Akzeptanz dieser Form von Apps ist eher gering. Windows ist aber nicht alleine auf der Welt. Es gibt noch macOS und Linux auf dem Desktop. Und wie sieht es mobil aus? iOS und Android sind hier die Betriebssysteme. Fast unabhängig vom System können Webapplikationen eingesetzt werden. Sie laufen im Browser auf fast jedem System und müssen nicht installiert werden. Mit ein wenig ausgefeilter Technologie kann man eine Webapplikation auch auf den Desktop bringen (Stichwort Electron) oder als native App für Mobilgeräte deployen.Noch unübersichtlicher wird es, wenn man zusätzlich die vielfältigen Möglichkeiten der Entwicklung einbezieht, zum Beispiel Windows Forms, Windows Presentation Foundation (WPF) oder die UWP. Apps nativ mit Java oder Kotlin für Android und Swift für iOS oder plattformübergreifend mit Xamarin oder, oder, oder.Dieser Artikel will etwas Ordnung in die Vielfalt der Optionen aus Nutzer- und Entwicklersicht bringen. Das Ziel: Den Kunden bei der Wahl der richtigen Plattform, der Art der Software und der Entwicklungstechnologie etwas besser zu beraten. Der Beitrag richtet sich damit gleichermaßen an Entwickler, um einem Überblick auch über „fremde“ Gebiete zu erhalten, als auch an IT-Entscheider, denn nur wenn man die technischen Features im Blick hat, kann man auch eine gute Wahl treffen.

Nutzerpräferenzen

Software wird für die Anwender erstellt. Diese wollen damit Probleme lösen (Textverarbeitung, Datenbanken), Spaß haben (Spiele) oder die Kommunikation vereinfachen (Chat, E-Mail) und so weiter. Das bedeutet, dass man alle Aspekte des Nutzerverhaltens erforschen muss. Aus technischer Hinsicht ist zu klären, mit welchen Geräten und Betriebssystemen die Anwender arbeiten möchten. Der Blick in die Statistik ist hilfreich. Man ist heute auf ­allen drei entscheidenden Gerätekategorien – Desktop, Smartphone und Tab­let – unterwegs (Bild 1). Auch zwischen den Altersgruppen gibt es keine wesentlichen Unterschiede. Es zeigt sich aber auch eine Dominanz der mobilen Systeme. Das Smartphone hat man stets dabei und kann jederzeit auf die App und das Internet zugreifen.

Im Verlauf des Tages ändert sich die Präferenz der Gerätekategorie (Bild 2). Für ein produktives Arbeiten setzt man nach wie vor auf größere Bildschirme und leistungsfähigere Hardware. Zu den typischen Bürozeiten wird an Desktop-Geräten am meisten gearbeitet. Am Morgen dominiert die Nutzung des Smartphones. Hier können E-Mail und soziale Netzwerke auf neue Nachrichten geprüft werden. Aber auch über den gesamten Tagesablauf ist das Smartphone ein Begleiter des Anwenders. In den Abendstunden liegt der Höhepunkt der Nutzung von Tablet-PCs. Moderne Tablets sind leistungsfähig und bieten eine annehmbare Bildschirmgröße für die individuelle Unterhaltung, zum Beispiel zum Videoschauen oder zum Surfen im Internet, ganz gemütlich im heimischen Wohnzimmer.

Was schlussfolgern wir daraus? Man ist heute flexibel unterwegs. Innerhalb eines Vorgangs wird durchaus der Gerätetyp gewechselt. Die Fahrkarte wird am PC ausgesucht und gebucht. Die digitale Version wird dem Zugbegleiter als Nachweis vorgezeigt. Der Versicherungsfachmann kalkuliert das Angebot bei Kunden auf dem Tablet und bittet diesen auch gleich zur digitalen Unterschrift. Im Backoffice werden die Dokumente zusammengestellt und dem Kunden im Webportal zur Ansicht zur Verfügung gestellt. Andererseits gibt es auch weiterhin Applikationen, die an eine Geräteklasse gebunden sind.Auch bezüglich der Betriebssysteme gibt es unterschiedliche Präferenzen, die mit den Gerätetypen einhergehen. Auf dem Desktop sind es Windows, macOS und Linux und für mobile Geräte Android und iOS (Bild 3).

Vor dem Treffen von Entscheidungen muss man als Entwickler die Nutzerpräferenzen genau analysieren. Daraus lassen sich dann erste Hinweise zu den App-Typen und zum Vorgehen bei der Entwicklung ablesen.

Vielfalt im Windows-Lager

Bei Desktop-Applikationen hat man grundsätzlich die Wahl zwischen den folgenden App-Plattformen (Tabelle 1):

Tabelle 1: Plattformen für Windows-Applikationen

Eigenschaft UWP WPF Windows Forms Win32 Versionen Windows 10 Ab Windows 7 Ab Windows 7 Ab Windows 7, gegebenenfalls auch früher Programmier- sprachen C#, VB.NET, JavaScript, C++ C#, C++/CLI (verwaltete Erweiterungen für C++), F#, VB.NET C#, C++/CLI (verwaltete Erweiterungen für C++), F#, VB.NET C++ oder über Wrapper, Klassenbibliotheken und Frameworks auch andere Sprachen UI-System XAML XAML Komponenten Komponenten für Klassenbibliotheken IDEs Visual Studio Visual Studio Visual Studio Visual Studio, andere Anbieter Stärken Modernste Windows-Plattform, reichhaltige Grafik, leichtgewichtig, innovativ, MVVM-Support, verwalteter Code Reichhaltige Grafik, bewährt, umfassende Codebasen, MVVM- Support, verwalteter Code Vollständiger grafischer Designer, effizienter Entwicklungszyklus, verwalteter Code Performance, direkte API-Interaktion Schwächen Nutzerakzeptanz umstritten Teilweise schwerfällig Gilt als veraltet, kein direkter Support neuester Features Gestaltungs­optionen eingeschränkt Aufwendig in der Programmierung oder Abhängigkeit von Framework eines Drittanbieters, neueste Innovationen der Windows-Plattform schwer umsetzbar Bevorzugte Szenarien Apps für Geräte mit unterschiedlichen Formfaktoren, wie Desktop, Tablet, und so weiter Windows-Applikationen aller Art, besonders Business-Anwendungen Einfache Windows Applikationen aller Art, besonders Business- Anwendungen Anwendungen mit besonderen Anforderungen an die Performance, wie Spiele

• Universal Windows Platform (UWP),
• WPF (.NET),
• Windows Forms (.NET),
• Win32.

Die UWP ist die führende Plattform für Windows-10-Anwendungen und Spiele. Es ist eine anpassbare Plattform, die XAML-Markup verwendet, um das User Interface zu erstellen. Die UWP eignet sich auch für Desktop-Anwendungen und bietet die neuesten und vielfältigsten Optionen für Windows-Applikationen. Apps für die UWP können zusätzlich auf Xbox, HoloLens und Surface Hub ausgeführt werden. Das Deployment der Apps erfolgt üblicherweise über den Store. Wichtig: Voraussetzung ist Windows 10.WPF ist die Plattform für verwaltete Windows-Anwendungen mit Zugriff auf das vollständige .NET Framework und XAML-Markup für das Erstellen des User Interface (UI). WPF taugt für Desktop-Anwendungen mit grafikintensiven Anforderungen an die Benutzeroberfläche. Die Konzepte der WPF ähneln den Ansätzen der UWP, daher ist eine Migration von WPF zu UWP einfacher als die Migration von Windows Forms. Windows Forms wiederum ist die ursprüngliche Plattform für verwaltete Windows-Anwendungen mit einem einfachen Benutzeroberflächenmodell und dem Zugriff auf das vollstän­dige .NET Framework. Das UI wird komplett im grafischen Designer der Entwicklungsumgebung erstellt. Windows Forms verwendet kein XAML zum Aufbau des UI. Eine Migration zur UWP erfordert es, dass man den größten Teil der Applikation vollständig neu erstellen muss.Mithilfe des Win32-API können Sie Windows-Applikationen aufbauen, ohne das .NET-Framework zu nutzen. In diesem Fall erstellen Sie Applikationen, die keinen verwalteten Code verwenden. Das ermöglicht ein Höchstmaß an Leistung und Effizienz, da Sie mehr Kontrolle über die Zielplattform haben. Der Aufwand der Programmentwicklung ist aber in der Regel höher, da sie zum Beispiel für die Speicherverwaltung selbst zuständig sind.Diese Szenarien der Programmentwicklung basieren auf C++ und einem direkten Aufruf der Windows-APIs. Anwendungen sind zum Beispiel Hardware-intensive Spiele. Mithilfe von Frameworks und Klassenbibliotheken kann man die Entwicklung gegen das Win32-API vereinfachen. Beispiele sind die Microsoft Foundation Class Library (MFC) oder FireMonkey von Embarcadero. Durch den Einsatz von Wrappern zur Kapselung des Windows-API ist es auch möglich, mit anderen Programmiersprachen zu arbeiten.Das Bild unter Windows wirkt im Moment recht uneinheitlich. Das liegt hauptsächlich an der aktuellen Zweiteilung der Windows-Plattform: die klassischen Windows-Applikationen für den Desktop (Windows Forms, WPF, Win32-API, Drittanbieter) und die UWP. Die jüngsten Entwicklungen lassen vermuten, dass Microsoft über kurz oder lang beide Stränge zu sogenannten Windows Apps zusammenführen will. Technologisch werden diese wohl sehr eng an die UWP angelehnt sein, sofern man dies im Vorfeld beurteilen kann.

Apps für macOS

Anwendungen für macOS werden auch als Apps bezeichnet. Der Store dient als zentraler Ort der Verteilung. Dennoch können Anwendungen auch ohne den Store auf ­macOS installiert werden. Viele typische macOS-Anwendungen stehen auch für andere Systeme bereit, das heißt, dass sie plattformübergreifend programmiert sind. Im Bereich Grafik und Design wird aufgrund der Leistung der Hardware (hochauflösende Bildschirme) traditionell mit Apple-Computern gearbeitet. Native macOS-Applikationen programmiert man in der Entwicklungsumgebung Xcode und als Programmiersprache wird Swift verwendet, der modernisierte Nachfolger von Objective-C.

Anwendungen für Linux

Bei Anwendungen für Linux liegen die Dinge ähnlich wie bei ­macOS. Es gibt eine Reihe von Applikationen und Software­suiten (zum Beispiel Libre Office), die unter allen Betriebssystemen zur Verfügung stehen. Ausgewählte Software unter Linux wird meist als Open Source lizenziert, deshalb lassen sich die Aufwendungen für die Entwicklung unter Linux schwerer refinanzieren als unter Windows und macOS. Hinzu kommt der Umstand, dass es „das Linux“ nicht gibt, sondern eine große Anzahl von Distributionen. Für die Darstellung der Oberfläche (das Fenstermanagement) gibt es für Linux unterschiedliche Desktops. Die bekanntesten Vertreter sind KDE, Gnome und Unity. Mit der Wahl des Desktops wird nicht nur die Art und Weise der Bedienung bestimmt, sondern auch, welche Tools und Applikationen zur Verfügung stehen.Ähnlich vielfältig und offen sind die Optionen zur Softwareentwicklung unter Linux. Die meisten Entwicklungsumgebungen sind Open Source. Der gewählte Desktop hat auch Einfluss auf die Vorgehensweise zum Er­stellen der Benutzeroberfläche. Eine Vielzahl von integrierten Entwicklungsumgebungen (IDEs) stehen damit auch für Linux zur Verfügung, zum Beispiel Eclipse. Ebenso gibt es Tools und IDEs, welche explizit nur auf Linux angeboten werden, wie etwa KDevelop.Zusammenfassend ist also festzustellen, dass Linux als exklusives System im Unternehmensbereich für Clientsoftware eher die Ausnahme darstellen dürfte. Typischer sind plattformübergreifende Applikationen, die dann auch auf Linux-Distributionen eingesetzt werden können.

Wenig Auswahl im mobilen Bereich

Im Bereich Mobile Computing ist die Auswahl noch weiter eingeschränkt als für den Desktop. Hier gibt es bekanntermaßen nur die Betriebssysteme Android und iOS. An dieser Verteilung wird sich auch künftig nicht allzu schnell etwas ändern, wenn man den Aussagen der Marktforschung glaubt (Bild 4). Drei Arten von Apps kann man für mobile Geräte unterscheiden:

• native Apps,
• Web-Apps,
• hybride Apps.

Der Vorteil nativer Apps liegt darin, dass diese für das jeweilige Betriebssystem optimiert sind. Die Benutzeroberfläche fügt sich vollständig in die Vorgaben der Plattform ein. Nutzer müssen sich also nicht erst länger orientieren, denn sie sind mit den üblichen Vorgängen wie der Auswahl oder dem Löschen von Elementen oder dem Wechsel von Screen zu Screen sofort vertraut. Ein weiterer wichtiger Vorteil besteht darin, dass native Apps keine Einschränkungen beim Zugriff auf spezifische Gerätehardware aufweisen. Alle Sensoren dieser Geräte können per API direkt angesprochen werden. Auch werden die Funktionen von neuen Geräten unterstützt und können damit in der App verwendet werden.Das Deployment nativer Apps erfolgt über die öffentlichen App Stores. Ausnahmen bestehen zum Beispiel bei der exklusiven Nutzung für unternehmerische Zwecke (Mobile Enterprise) und während der Entwicklung und des Testens. Ist eine native App auf dem mobilen Gerät installiert, kann diese gegebenenfalls offline ausgeführt werden. Eine notwendige Datensynchronisation kann beim Herstellen der nächsten Internetverbindung automatisch stattfinden.Dem gegenüber stehen Web-Apps. Das sind spezielle Webapplikationen, die für die Nutzung auf Mobilgeräten besonders angepasst werden – unter anderem hinsichtlich Nutzerführung und UI. Der Zugriff auf die Systemhardware ist jedoch beschränkt. Einige Funktionen, wie der Ortungsdienst, sind jedoch nutzbar. Die Darstellung erfolgt im Browser des Systems und kann die Besonderheiten der einzelnen Plattformen nur bedingt berücksichtigen. Web-Apps können nicht über den App Store bereitgestellt werden. Sie laufen auf dem Server und benötigen daher eine stetige Internetverbindung, damit man mit ihnen sinnvoll arbeiten kann. Web-Apps können aus Kundensicht immer dann eine Alternative zu einer nativen App sein, wenn dem Nutzer eine Installation über den Store nicht zuzumuten ist, etwa wenn die App typischerweise sehr selten oder nur einmal verwendet wird.Die fehlende Offline-Fähigkeit kann durch neuere technologische Ansätze (Progressive Web-Apps, PWA) teilweise aufgehoben werden.Gewissermaßen zwischen Web-App und nativer App agieren hybride Apps. Sie laufen in einem Web-View-Container, also in einer Art internem Browser. Damit wirken sie für das Betriebssystem wie eine native App. Das User Interface muss generisch sein, um mit allen Systemen zurechtzukommen. Ein Vorteil hybrider Apps ist, dass man sie über die App Stores verteilen kann.

Möglichkeiten der App-Entwicklung

Nun zu den Möglichkeiten der App-Entwicklung. Erfreulicherweise ist hier die Zahl der Ansätze inzwischen recht groß. Das hat zur Folge, dass man als Entwickler das passende Vorgehen wählen kann.Es ist sinnvoll, die Entwicklungsansätze grob nach den Arten der App einzuteilen (Bild 5). Zur nativen App gelangt man üblicherweise auf dem Weg, den das Betriebssystem dafür vorsieht. Plattformübergreifende Lösungen ermöglichen es, native Apps für mehrere Systeme simultan aus einer Code­basis zu erstellen. Hier liegt im Moment das Feld der größten Innovationen. Dazu später mehr. Native Apps für Android werden mit Java oder Kotlin erstellt. Das UI wird mithilfe einer XML-Datei deklariert. Als Entwicklungsumgebung empfiehlt Google Android Studio, das einen grafischen Designer anbietet. Ein wichtiger Aspekt bei der Programmentwicklung von Apps für Android ist die SDK-Version, für welche die App entwickelt wird. Neuere Features setzen eine aktuelle Ver­sion des SDK voraus. Nutzt man diese, so läuft die App eventuell aber nicht auf Geräten mit einer nicht aktuellen Version des Betriebssystems. Abhilfe kann eine Android Support Library schaffen. Deren Ziel ist es, neuere Features auch auf ältere Versionen von Android einsetzen zu können. Diese Vorgehensweise hat verständlicherweise Grenzen. In der Praxis macht dies es erforderlich, einen guten Kompromiss zwischen der minimal unterstützten Android-Version und der Aktualität der Plattform zu wählen.

Web-Apps sind, wie bereits beschrieben, eine besonders an die mobilen Devices angepasste Form einer Webapplikation. Sie werden über den Browser des jeweiligen Systems gestartet. Das UI basiert auf HTML und CSS, und die Geschäftslogik wird mittels JavaScript realisiert. Der Einsatz von Frameworks kann den Entwicklungsaufwand reduzieren. Mithilfe der Erweiterung zu einer Progressive Web App (PWA) kann ein teilweiser Offline-Betrieb auch bei Web-Apps erreicht werden. Eine PWA ist gewissermaßen eine Symbiose aus einer Webseite und einer App. In einer PWA wird ein sogenannter Service Worker genutzt, um über Caching einen Offline-Betrieb zu ermöglichen.Hybride Apps basieren in der Regel ebenfalls auf den Technologien HTML, CSS (UI) und JavaScript (Logik). Damit die Web-App sich für das System wie eine native App „anfühlt“, wird sie in eine Art Container gepackt. Für die Entwicklung stehen Frameworks wie zum Beispiel Cordova zur Verfügung. Die App öffnet beim Starten ein Browserfenster im Vollbildmodus, sodass der Browser als solcher nicht identifizierbar ist. Die Webadresse kann nicht geändert werden. In dieser Web-View wird die mit HTML, CSS und JavaScript erstellte App angezeigt. Über das Framework bekommt die App mithilfe von Plug-ins Zugriff auf Systemfunktionen, etwa auf die Kamera oder den GPS-Sensor.Zusammenfassung: Aus technischer Perspektive ergibt sich ein klarer Vorteil für native Apps. Sie können die gesamte Hardware des jeweiligen Systems nutzen, was bedeutet, dass sie uneingeschränkten Zugriff auf die Gerätefunktionen haben und die beste Performance aufweisen. Auch die Anpassung an die Systemumgebung in Sachen Design und Bedienung ist optimal.

Vielfalt bei Webapplikationen

Applikationen werden heute sehr oft als Webapplikationen erstellt. Sie sind das Gegenstück zu oft „schwerfälligen“ Desktop-Anwendungen und weisen die folgenden Vorzüge auf:

• Installation: Setzt man eine Webapplikation ein, dann ist nur ein Installationsvorgang erforderlich. Dieser findet üblicherweise auf dem Server statt. Der Client greift über das Netzwerk mithilfe eines Browsers auf die Anwendung zu. Lokal auf dem Client sind (gegebenenfalls mit Ausnahme von Plug-ins) keine Installationen notwendig. Oft genügt ein beliebiger Webbrowser, der auf jedem System ohnehin bereits vorhanden ist.
• Aktualität: Webanwendungen sind aus Sicht des Anwenders stets aktuell. Darum muss sich der Benutzer nicht kümmern. Man erhält meist im Rahmen einer vertraglichen Vereinbarung die aktuellen Updates. Diese werden direkt über den Server installiert und es bedarf keiner Eingriffe auf Seiten des Clients.
• Mehrbenutzerbetrieb: Ein Mehrbenutzerbetrieb ist für eine Webapplikation in der Regel Standard.
• Systemanforderungen: Man kann in der Regel von jedem System aus mit nahezu jedem beliebigen Browser arbeiten. Die Applikation läuft auf dem Server, was bedeutet, dass die Daten- oder Internetverbindung für eine performante Ausführung wichtiger ist als die lokale Software oder Hardware. Man kann Webanwendungen auch auf weniger leistungsfähiger Hardware ausführen.
• Kosten: Bei gelegentlicher oder einmaliger Nutzung sind Webanwendungen oft günstiger als Desktop-Anwendungen, denn Sie zahlen in der Regel nur für die Dauer der Nutzung oder den Ressourcenverbrauch.

Mit modernen Webapplikationen ist man heute jedoch nicht mehr auf den Browser beschränkt. Insbesondere innovative clientseitige Frameworks und Bibliotheken ermöglichen es, dass man mit Webtechnologien auch Applikationen für den Desktop oder mobile Devices (Smartphone, Tablet) erstellt.Zu unterscheiden sind client- und serverseitige Webapplikationen. Eine Webapplikation ist gewissermaßen eine besondere Ausprägung der Client-Server-Architektur (Bild 6). Die Präsentation erfolgt durch den Client, der in diesem Fall der Webbrowser ist. Der Browser selbst kann nur HTML (Struktur) und CSS (Layout) verarbeiten. Für die Logik im Browser ist JavaScript zuständig. Weitere Technologien können bei Bedarf über Plug-ins nachgerüstet werden. Dies ist jedoch nicht wünschenswert, damit die Applikation direkt und ohne Barrieren ausgeführt werden kann.

Auf Seiten des Servers kann die dafür notwendige Infrastruktur schon umfassender aussehen und wird üblicherweise auch in weitere Teilkomponenten gegliedert. Die Kommunikation wird auf Serverseite durch einen HTTP-Server abgewickelt. Dieser Teil der Serverstruktur stellt gewissermaßen die Präsentationschicht serverseitig dar. Er liefert im Ergebnis den HTML-Code für den Webbrowser. Komplexere Anwendungssysteme teilen die Verantwortung auf Serverseite neben dem HTTP-Server noch auf einen Anwendungs- und einen Datenbankserver auf. Sämtliche Kommunikation zwischen Client und Server erfolgt über das Web. Das Web basiert auf der Infrastruktur des Internets, das heißt:

• Protokoll: Die Datenübertragung erfolgt über das Transmission Control Protocol / Internet Protocol (TCP/IP).
• Adressierung: Die Adressen werden als Uniform Resource Locator (URL) angegeben.
• Darstellung: Die Darstellung der Inhalte erfolgt mittels ­HTML und CSS im Browser.

Es gibt unterschiedliche Technologien für die Umsetzung webbasierter Anwendungssysteme. Insbesondere kann danach unterschieden werden, welche Aufgaben vom Client (Browser) beziehungsweise vom Server wahrgenommen werden. Beispielsweise kann der Client vom Server die kompletten Inhalte zur Darstellung geliefert bekommen, sodass dieser tatsächlich nur für die Präsentation der Inhalte verantwortlich ist. Andererseits ist es denkbar, dass auf der Seite des Clients ein Großteil der Anwendungslogik implementiert wird. Dies geschieht dann mit JavaScript und entsprechenden Bibliotheken beziehungsweise Frameworks. Sehr viele serverseitige Webapplikationen basieren zum Beispiel auf der Skriptsprache PHP (Bild 7). Der Nutzer sendet eine Anfrage über den Browser an den Server. Diese Anfrage wird durch das PHP-Programm verarbeitet. Dazu kann es erforderlich sein, dass das PHP-Programm Daten aus einer Datenbank ­abruft. Die Datenbank ist ebenfalls auf dem Webserver installiert beziehungsweise von diesem erreichbar. Der PHP-­Interpreter erzeugt auf der Basis der Anfrage und seines spezifischen Algorithmus nunmehr die Antwort in Form einer HTML-­Datei. Diese HTML-Datei wird an den Client übermittelt. Der Browser selbst bekommt also stets eine HTML-Datei als Ergebnis geliefert und ist für deren Anzeige verantwortlich. Ein entscheidender, durchaus sicherheitsrelevanter, Vorteil besteht darin: Das PHP-Programm ist von Seiten des Clients nicht einsehbar beziehungsweise kann nicht geändert werden.

Bei clientseitigen Webapplikationen werden die Skripte allerdings nicht vom Server, sondern vom zugreifenden Client ausgeführt und verarbeitet. Zu diesem Zweck werden die Skripte entweder in das HTML-Dokument eingebettet oder in eigene Dateien ausgelagert. Ruft der Nutzer eine Webanwendung mit einem solchen clientseitigen Skript auf, sendet der Webserver das HTML-Dokument sowie das Skript an den Browser. Der Browser führt das Skript aus und präsentiert wiederum das Ergebnis.Oftmals werden Webanwendungen als sogenannte Single-Page-Applikationen (SPA) erstellt. Hier kommt lediglich ein einziges HTML-Dokument zum Einsatz. Innerhalb des Dokuments werden neue oder veränderte Daten dynamisch geladen. Die Aktualisierung der Darstellung erfolgt dann zum Beispiel auf der Basis einer DOM-Manipulation. Zur Vereinfachung der clientseitigen Programmierung stehen eine Reihe von Klassenbibliotheken und Frameworks zur Verfügung. Sie dienen der Wiederverwendung und der Lösung bekannter Programmieraufgaben. Klassenbibliotheken bieten dabei Methoden und Funktionen zur universellen Nutzung in der eigenen Applikation an. Frameworks stellen dem Entwickler ein Gerüst für eine Anwendungsarchitektur bereit, das von der eigenen Anwendung genutzt wird. Nicht immer ist eine trennscharfe Abgrenzung möglich.

Vorgehen: Klassisch – RAD – Low Code

Die für die Entwicklung der Anwendungen eingesetzten Werkzeuge sollen dabei helfen, das ursprüngliche Ziel leichter zu erreichen. Gerade in der Softwareentwicklung kann es aber dazu kommen, dass man sich durch den Einsatz von zu vielen Tools von der eigentlichen Aufgabe eher ablenken lässt, als dass man sie leichter erledigt. Dieses „Overtooling“ ist genauso wenig hilfreich wie ein nur sehr minimalistischer Werkzeugeinsatz. Nicht für jede Aufgabe benötigt man ein spezielles Programm. Eine integrierte Entwicklungsumgebung (IDE) vereint unter einer gemeinsamen Oberfläche typischerweise die folgenden Bestandteile:

• Editor mit Quelltextformatierung und Syntaxhervorhebung,
• Compiler/ Interpreter/ Linker,
• Debugger,
• Werkzeuge zum Erstellen grafischer Benutzeroberflächen (UI-Builder),
• Versionsverwaltung.
• Je nach Entwicklungsumgebung werden weitere Funktionen bereitgestellt. Wir alle kennen beispielsweise die kaum zu überblickende Funktionsvielfalt von Visual Studio.

Neben diesem „klassischen“ Vorgehen sehen wir zwei weitere gegenläufige Trends. Aus dem Umfeld der Webtech­nologien zeichnet es sich ab, dass man zunehmend auf die „großen“ integrierten Entwicklungsumgebungen verzichtet. Stattdessen setzt man schlanke Editoren wie etwa Visual Studio Code ein. Diese können meist plattformunabhängig (Windows, Linux, macOS) genutzt werden. Durch zahlreiche Plug-ins kann man sie an die individuellen Bedürfnisse und Systemumgebung anpassen. Meist decken sie nur einen Teilbereich der Entwicklungsaufgaben ab, und man verwendet mehrere spezielle Tools anstelle einer „Eier legenden Wollmilchsau“. Viele Aufgaben werden auch wieder auf der Kommandozeile (Command Line Interface, CLI) oder über Skripte erledigt. Zusammenfassend betrachtet wird die Komfort­zone der IDEs ein Stück weit verlassen. Typisch ist zum Beispiel, dass ein umfassender Designer/Editor für das Erstellen des User Interfaces meist nicht vorhanden ist.

Low Code, No Code

In eine vollständig andere Richtung geht der Trend, dass man die Entwicklung von Business-Anwendungen ein Stück in die Richtung der Fachabteilungen verschieben möchte. Die Gründe sind vielfältig. Zum einem sind Entwicklungskapazitäten knapp, das heißt, der Arbeitsmarkt der Softwareentwickler ist teilweise leergefegt, und zum anderen steigt der Bedarf an individuellen Softwarelösungen in Unternehmen. Technikbegeisterte und versierte Anwender (sogenannte Citizen Developer) in den Fachabteilungen sind durchaus in der Lage, einen Teil der Entwicklungsaufgaben zu übernehmen. Dazu werden ihnen hochintegrierte Tools an die Hand gegeben, die das weitgehende Erstellen von Softwarelösungen erlauben. Diese Tools werden als Low-Code- beziehungsweise im Sonderfall auch als No-Code-Plattformen bezeichnet. Low Code – so sagt es bereits der Name – steht für möglichst wenig Code beim Erstellen von Software. Typische Einsatzgebiete sind Anwendungen aus den Bereichen Vertrieb, Marketing oder Produktionsplanung. Low-Code-Plattformen haben also das Ziel, wiederkehrende Aufgaben der Softwareentwicklung zu standardisieren. Dabei setzen diese nicht auf technischer Ebene an, es geht also nicht um die Wiederverwendung von Programmcode, sondern ihr Fokus ist die Ebene der Funktionen einer Software (Use Cases). Hier gibt es ein großes Potenzial zur Standardisierung. Typische sich wiederholende Aufgaben sind zum Beispiel: formularbasierte Datenerfassung, Validierung der Daten, Bereitstellen der Benutzeroberfläche, lokale Datenhaltung, Umsetzung eines spezifischen Workflows und die Anbindung der neuen Software an die bestehende Unternehmens-IT. Meist bieten Low-Code-Plattformen folgende Möglichkeiten:

• Quellcodearmes oder quellcodefreies Realisieren der Benutzeroberfläche.
• Umsetzen der Geschäftslogik zum Beispiel auf Basis einer grafischen Modellierung der Geschäftsprozesse.
• Anbinden der Datenhaltung.

Viele dieser Aufgaben können durch Verwenden vorgefertigter Komponenten, eine umfassende grafische Interaktion und mittels Konfiguration erledigt werden. Die extreme Ausprägung sind No-Code-Systeme. Diese versprechen eine Softwarebereitstellung ohne Codierung. Das kann nach dem heutigen Stand der Technik jedoch nur für sehr begrenzte Aufgabenbereiche funktionieren.Gewissermaßen zwischen der „händischen“ Entwicklung mit IDEs und Low-Code-Plattformen liegen Ansätze der Entwicklung mit RAD Tools. Rapid Application Development (RAD) steht für schnelle Anwendungsentwicklung. Der Begriff wurde von Barry Boehm in den 1980er Jahren als Konzept der Softwareentwicklung nach dem prototypischen Vorgehensmodell erdacht. Es dient dazu, Softwareentwicklung im Vergleich zu klassischen Vorgehensmodellen flexibler zu gestalten und sich an schnell ändernde Anforderungen anpassen zu können. Ursprüngliche Grundlage ist das Spiral­modell, das ein prototypisches Vorgehen vorsieht. Natürlich ist dieses Konzept auch auf agile Vorgehensmodelle übertragbar. RAD-Werkzeuge weisen üblicherweise die Gemeinsamkeit auf, dass man mit ihnen die Benutzeroberfläche mithilfe eines Designers per Drag-and-drop und über das Anpassen von Eigenschaften erstellen kann. Zudem stehen nicht­visuelle Komponenten zur Verfügung, etwa um mit einer Datenbank aus der Applikation zu interagieren oder einen Dateidialog aufzurufen. Über Extensions, Plug-ins oder externe Bibliotheken kann das Angebot der Komponenten meist vielfältig erweitert werden. Ziel der RAD-Tools ist es, den Entwickler von Routineaufgaben zu entlasten und damit die Effizienz des Entwicklungsprozesses zu steigern. Beim Einsatz von RAD-Tools behält der Entwickler jedoch jederzeit die vollständige Kontrolle über den Quellcode.Mit dieser Beschreibung ist auch klar, dass man die Wirtschaftlichkeit der Entwicklung immer stärker berücksichtigen muss. Der „schönste“ technische Ansatz nützt nichts, wenn niemand dessen Umsetzung bezahlen möchte. Vorgehensweisen wie RAD und Low Code vereinfachen das Erstellen von Applikationen über weite Strecken.

Cross-Plattform auf dem Vormarsch

Plattformübergreifende Ansätze (Cross-Plattform) verfolgen das Ziel, eine Applikation aus einem Quellcode für alle Zielsysteme gleichzeitig zu erstellen. Java ist das bekannteste technische Konzept dafür. Dabei laufen die Anwendungen in einer virtuellen Maschine. Der Entwickler muss sich nicht um die Besonderheiten der jeweiligen Zielplattform kümmern. Andere Ansätze gehen einen anderen Weg. Zum Beispiel kann man mit RAD Studio von Embarcadero native Anwendungen für Desktop- und mobile Systeme erstellen. Das Problem des User Interface wird mithilfe des Frameworks FireMonkey gelöst. Der Compiler erzeugt den lauffähigen Code für das jeweilige Zielsystem.Plattformübergreifende Programmierung ist auch im Bereich der Apps für Mobilgeräte interessant. Ziel ist es hier, aus einem Quellcode Apps sowohl für Android als auch für iOS zu erstellen. Interessant sind zum Beispiel die Technologien Xamarin, NativeScript, React Native und Flutter. Xamarin bietet zwei Optionen, native Apps zu erstellen: Im ersten Ansatz wird die Fachlogik der Anwendung übergreifend in C# erstellt. Das UI basiert dagegen auf dem jeweiligen System. Damit benötigt man für die Programmierung weiterhin umfassende Kenntnisse über alle Zielsysteme. Der zweite Ansatz basiert auf Xamarin.Forms, welches eine generische Entwicklung des UI für alle Systeme mithilfe eines XAML-Dialekts erlaubt. Dazu generiert Xamarin aus dem XAML-Code das native Interface für jedes der Zielsysteme. Die Grenze liegt dort, wo die gewünschte Hardware-Interaktion zu tief ist und durch den generischen Ansatz nicht abgedeckt wird. Beispielsweise dann, wenn eine Funktion nur auf iOS zur Verfügung steht.Eine weitere Vorgehensweise basiert auf NativeScript, einem Open-Source-Framework von Progress Telerik. Die Entwicklung erfolgt in JavaScript, alternativ in TypeScript, wenn man ergänzend das Framework Angular einbindet. Die Benutzeroberfläche wird wie bei Web-Apps oder hybriden Apps mit HTML und CCS gestaltet. Der Unterschied besteht jedoch darin, dass kein Browser beziehungsweise keine Web-View für die Ausführung der App benötigt wird. NativeScript führt zwar auch JavaScript aus, es werden jedoch zur Laufzeit die Widgets der nativen Plattform (von Android oder iOS) erzeugt. Das User Interface wird auf der Basis der JavaScript Syntax Extension (JSX) beschrieben. Spezifische Funktionen von Android und iOS können über JavaScript angesprochen werden. Während des Builds der App wird der nicht plattformspezifische Code in die jeweilige Zielplattform übersetzt.Flutter verwendet zum Zeichnen der Komponenten nicht die nativen UI-Komponenten der Plattformen, sondern eine eigene Rendering-Engine namens Skia. Flutter basiert auf Googles Programmiersprache Dart. Deren Sprachsyntax ähnelt der von C. Dart ist streng typisiert und objektorientiert. Für die Entwicklung benötigt man das Flutter SDK. Als Entwicklungsumgebung kann man zum Beispiel Android Studio oder Visual Studio Code einsetzen.Aus den vorgestellten Darstellungen ergibt sich, dass plattformübergreifende Ansätze aus technischer Sichtweise und aus der Perspektive eines guten Kosten-Nutzen-Verhältnisses viele Vorteile bieten. Je nach Ansatz entstehen dabei Applikationen für eine Geräteklasse, zum Beispiel für die mobilen Devices oder den Desktop. Ebenso können aus dem Quellcode Applikationen für unterschiedliche Geräteklassen generiert werden, zum Beispiel sowohl für den Desktop als auch für Mobilgeräte. Je breiter die Palette der unterstützten Geräte und Systeme ist, desto generischer muss der Ansatz sein und man muss auf Plattformbesonderheiten verzichten beziehungsweise diese individuell umsetzen.Die plattformübergreifende Entwicklung hat Gemeinsamkeiten mit der Entwicklung von Webapplikationen, denn beide Anwendungstypen können auf einer Vielzahl von Geräten ausgeführt werden. Während Webapplikationen jedoch im Browser laufen und damit auf dessen Funktionalität beschränkt sind, ist es das Ziel der plattformübergreifenden Entwicklung in der Regel, spezifische Anwendungen für das Zielsystem zu generieren, die den nativen Entsprechungen möglichst nahe kommen. Ansätze wie Electron vermischen diese beiden Varianten. Hier entsteht aus einer ursprünglichen Webapplikationen eine Anwendung für den Desktop nach Wahl für Windows, macOS oder Linux.Zusammenfassend lässt sich also sagen, dass die plattformübergreifende Entwicklung immer dann eine gute Wahl sein kann, wenn mehrere Systeme zu unterstützen sind und eine Webapplikation die Anforderungen nicht vollständig erfüllt.

Was denn nun?

Aus Sicht der Softwareentwicklung ergibt sich gewissermaßen eine mehrdimensionale Komplexität aus drei Größen: Gerät, Betriebssystem und Entwicklung.Blickt man zum Nutzer, dann stellt sich als Erstes die Frage, auf welchen Geräten die Anwender arbeiten. Anhand der Statistiken ist zu sehen, dass es hier eine zunehmende Vielfalt der Devices gibt. Dabei nimmt eindeutig die Nutzung mobiler Technik zu. Das gilt auch für Unternehmensanwendungen (Stichwort: Mobile Enterprise Computing). Im zweiten Schritt ist die Frage des Betriebssystems wichtig. Für klassische Unternehmensanwendungen ist nach wie vor Windows dominierend, für ausgewählte Anwendungen auch macOS. Linux spielt im Desktop-Bereich nach wie vor eine untergeordnete Rolle, deshalb dürfte sich eine ausschließliche Entwicklung für Linux in den meisten Fällen nicht lohnen. Apps für mobile Geräte arbeiten heute und wohl auch in der näheren Zukunft unter Android und iOS. Für die meisten Einsatzszenarien sind deshalb beide Systeme zu unterstützen.Auf Basis dieser beiden Vorentscheidungen geht es dann in „unseren Bereich“. Wir müssen Entscheidungen bezüglich der Technologie und des Entwicklungsansatzes treffen. Je nachdem, ob es Geräte unterschiedlichen Typs zu unterstützen gilt oder der Auftrag auf eine Geräteklasse beschränkt ist, ergeben sich weitere Vorgaben für die Entwicklung. Gleiches gilt für die zu unterstützenden Betriebssysteme. Die meiste Flexibilität bieten hier ohne Zweifel Webapplikationen. Sie laufen im Browser und können – wenn responsiv gestaltet – auf vielen Arten von Geräten und Systemen direkt ausgeführt werden. Natürlich gibt es auch Einschränkungen, zum Beispiel in Fragen der Performance oder der Hardwareunterstützung.Müssen Sie „näher“ zum Gerät, dann kommen Sie um eine native Entwicklung beziehungsweise Entwicklung speziell für das Zielsystem nicht umhin. Hier gibt es für jedes System eine oder mehrere etablierte Vorgehensweisen. Diese wurden oben dargestellt. Ein Ausweg sind Ansätze zur simultanen Entwicklung für mehrere Systeme. Traditionell wird dieses Feld durch Java besetzt – eine nach wie vor etablierte Vorgehensweise, um Applikationen zu erstellen, die auf mehreren Betriebssystemen laufen.Geräteübergreifende Entwicklung und Cross-Plattform-Ansätze gehen dabei noch einen Schritt weiter. Aus einer Quellcodebasis sollen dabei möglichst Anwendungen generiert werden können, die bezüglich ihrer Features sehr nahe an den nativen Entsprechungen sind. Aus dieser Gemengelage gilt es, den passenden Ansatz mit Blick auf die Technik auswählen.Zur Frage der Entwicklung gehört auch der Einsatz der Werkzeuge. Hier reicht das Spektrum von einer klassischen IDE über RAD-Tools zur Beschleunigung des Vorgangs bis hin zu Low-Code- oder sogar No-Code-Plattformen, um gegebenenfalls Aufgaben an versierte Anwender abgeben zu können.

Fazit und Ausblick

Vielfalt ist gut. Auch wenn diese uns als Entwickler die Entscheidung oft erschwert und die Frage „Was raten wir dem Kunden?“ nicht unbedingt einfacher macht. Im konkreten Fall kann man zum Beispiel nach dem Ausschlussprinzip vorgehen. Welche Randbedingungen sind unbedingt zu erfüllen? Genügt zum Beispiel Windows 10 als System, oder sind auch macOS oder ältere Windows-Versionen zu unterstützen? Gibt es mobile Szenarien, und in welchem Umfang?Beteiligen Sie den Kunden an der Auswahlentscheidung. Gemeinsam geht es darum, die richtige Plattform und den effizienten Weg der Entwicklung zu finden. Die Angst, dass man auf ein „Auslaufmodell“ setzt, ist meist nicht begründet. Noch heute gibt es unzählige Applikationen auf Basis von Windows Forms, man kann diese auch noch problemlos erweitern, warten oder auf dieser Basis ein neues Projekt starten, wenn einem WPF oder die UWP aus grafischer Sicht überdimensioniert erscheinen.