Wie Betriebe eine Android-App entwickeln und pflegen
6 Minuten Lesedauer
Eine Anwendung für Android zu entwickeln bedeutet, für eine offene Gerätelandschaft zu bauen. Auf der iOS-Seite steht eine überschaubare Zahl von Modellen eines einzigen Herstellers, bei Android verteilen sich die Geräte über Dutzende Marken, Bildschirmformate und Systemversionen. Für Betriebe, die eine eigene Anwendung planen, verschiebt sich dadurch vor allem der Aufwand für Prüfung und Pflege, weniger der für die Programmierung selbst.
Was unterscheidet die Android-Entwicklung von der Entwicklung für iOS?
Der Unterschied liegt in der Umgebung, nicht in der Programmierkunst. Android läuft auf Geräten vieler Hersteller, iOS auf Geräten eines einzigen. Daraus folgen abweichende Prüfaufwände, abweichende Regeln für die Veröffentlichung und eine abweichende Erwartung an die Lebensdauer einer einmal ausgelieferten Version.
Auf technischer Ebene arbeitet die Android-Entwicklung überwiegend mit Kotlin, in älteren Beständen weiterhin mit Java, und mit einer eigenen Entwicklungsumgebung samt Gerätesimulation. Die iOS-Seite nutzt Swift und eine andere Werkzeugkette. Wer beide Systeme bedienen will, entscheidet früh, ob zwei getrennte Entwicklungen entstehen oder ein plattformübergreifender Rahmen gewählt wird.
In der betrieblichen Praxis fällt diese Entscheidung meist über den Gerätebestand. Betriebe, die Diensthandys selbst beschaffen, vereinheitlichen den Bestand und halten den Prüfumfang klein. Betriebe, die private Geräte zulassen, müssen die gesamte Bandbreite bedienen, weil sonst ein Teil der Belegschaft von der Nutzung ausgeschlossen bleibt. Nach Auswertungen des Statistikdienstes StatCounter liegt der Anteil von Android an den genutzten mobilen Betriebssystemen in Deutschland zwischen 60 und 70 Prozent (2024), der verbleibende Anteil entfällt nahezu vollständig auf iOS.
Wie breit dieser Bestand tatsächlich ist, zeigt sich erst beim Test.
Warum erhöht die Gerätevielfalt den Testaufwand bei Android-Apps?
Die Vielfalt erhöht den Testaufwand, weil jede Kombination aus Systemversion, Bildschirmgröße und Herstelleraufsatz eigene Abweichungen erzeugt. Geprüft wird deshalb nicht ein Gerät, sondern eine Matrix aus Versionen und Geräteklassen, die vor Projektbeginn festgelegt und begrenzt werden muss.
Welche Dimensionen diese Matrix aufspannen, lässt sich an vier Merkmalen festmachen:
| Prüfdimension | Was variiert | Folge für den Test |
|---|---|---|
| Systemversion | Berechtigungen, Hintergrundprozesse, Dateizugriff | eigener Durchlauf je unterstützter Version |
| Bildschirm | Auflösung, Seitenverhältnis, faltbare Geräte | Oberfläche muss mitwachsen statt fest zu sitzen |
| Herstelleraufsatz | Energieverwaltung, Benachrichtigungen | Hintergrunddienste werden unterschiedlich beendet |
| Hardware | Kamera, Standort, NFC, Barcodeleser | Funktionen müssen abschaltbar bleiben |
Begrenzt wird der Aufwand über eine festgeschriebene Mindestversion und eine benannte Liste von Geräteklassen. Alles darunter wird nicht unterstützt, und diese Festlegung gehört in das Lastenheft, nicht in die Abnahme. Für den Durchlauf selbst kommen Simulatoren und mietbare Gerätefarmen in Betracht, wobei reale Geräte vor allem für Kamera, Standort und Energieverhalten unverzichtbar bleiben.
Welche Werkzeuge dabei greifen, hängt an der gewählten technischen Richtung.
Welche betrieblichen Abläufe bildet eine Android-App typischerweise ab?
Abgebildet werden meist Abläufe, die außerhalb des Büros stattfinden: Auftragserfassung beim Kunden, Zeit- und Materialbuchung, Fotodokumentation und Unterschrift auf dem Gerät. Gemeinsames Merkmal ist, dass Daten dort entstehen, wo bisher Papier im Einsatz war.
Der Nutzen entsteht erst, wenn diese Daten ohne zweite Erfassung in die Auftragsabwicklung laufen. Eine Anwendung, die Stunden sammelt und sie danach per Ausdruck an die Buchhaltung weitergibt, verlagert Arbeit statt sie zu sparen. Wie weit sich Abläufe über Anwendungen tatsächlich verändern, beschreibt der Beitrag zur Abbildung betrieblicher Abläufe in eigenen Anwendungen.
Hinzu kommt die Pflicht zur Datenminimierung. Standortdaten, Fotos und Kontakte unterliegen der Datenschutz-Grundverordnung, und eine Anwendung, die mehr erfasst als der Ablauf benötigt, erzeugt Dokumentationspflichten ohne Gegenwert.
Steht fest, was die Anwendung leisten soll, rückt der Weg in den Vertrieb in den Blick.
Wie läuft die Veröffentlichung einer Android-App im Play Store?
Die Veröffentlichung läuft über ein Entwicklerkonto im Play Store, eine einmalige Registrierungsgebühr und eine Prüfung durch den Plattformbetreiber. Zwischen Einreichung und Freigabe liegen in der Regel wenige Tage, bei Rückfragen länger.
Verlangt werden dabei nicht nur die Anwendung selbst, sondern auch eine Datenschutzerklärung unter eigener Adresse, ein Formular zur Datensicherheit mit Angabe aller erhobenen Datenarten und eine Alterseinstufung. Werden diese Angaben nachträglich falsch, droht die Entfernung aus dem Verzeichnis, unabhängig davon, ob die Anwendung technisch läuft.
Für betriebsinterne Anwendungen bestehen zwei Wege neben der offenen Veröffentlichung. Eine Anwendung kann als geschlossene Version an benannte Konten ausgeliefert werden, oder sie wird über ein verwaltetes Verzeichnis nur an Geräte des Betriebs verteilt. Die Gebühren für Konto und Verteilung sind für den Betrieb eine Betriebsausgabe und gehören in die Kalkulation der Laufzeit, nicht in die Erstellungskosten.
Mit der Freigabe beginnt die Aufgabe, die über Jahre bleibt.
Welche Update-Zyklen gelten für die Android-Betriebssystemversionen?
Eine neue Hauptversion von Android erscheint im jährlichen Takt, begleitet von monatlichen Sicherheitsaktualisierungen der Gerätehersteller. Für eine veröffentlichte Anwendung bedeutet das wiederkehrende Anpassung, auch wenn fachlich nichts geändert wird.
Der Plattformbetreiber verlangt, dass eingereichte Aktualisierungen eine aktuelle Programmierschnittstelle des Systems ansprechen. Wer diese Grenze reißt, kann keine neue Version mehr einstellen, und bestehende Installationen bleiben auf dem Stand des letzten Uploads stehen. Für Betriebe ist das der eigentliche Grund, Pflege vertraglich zu regeln.
Geregelt werden sollten drei Punkte: welche Systemversionen dauerhaft unterstützt werden, in welcher Frist auf eine neue Hauptversion reagiert wird und wer die Kosten dieser Anpassung trägt. Ohne diese Festlegung entsteht nach etwa zwei Jahren eine Anwendung, die im Betrieb läuft, aber nicht mehr aktualisierbar ist.
Wer diese Pflege übernimmt, ist damit die nächste Frage.
Woran erkennen Betriebe einen geeigneten Partner für die Android-Entwicklung?
Erkennbar ist Eignung an der Arbeitsweise, nicht am Portfolio. Ein geeigneter Partner fragt nach Abläufen, bevor er über Oberflächen spricht, benennt die unterstützten Systemversionen schriftlich und legt offen, wo die Daten verarbeitet werden.
Prüfbar ist das an wenigen Punkten: ob das Entwicklungsteam im eigenen Haus arbeitet oder die Umsetzung weitergegeben wird, ob der Quellcode nach Abschluss beim Betrieb liegt und ob eine Schnittstelle zum vorhandenen System vor Angebotsabgabe geklärt wurde. Welche Dienstleistertypen am Markt auftreten und wie sich ihre Verantwortung unterscheidet, ordnet der Beitrag über die Auswahl eines Entwicklungspartners im Mittelstand ein.
Das Angebot selbst lässt sich daran ablesen, ob es Pflege und Betrieb als eigene Posten führt. Fehlen sie, ist nicht die Anwendung günstiger, sondern die Rechnung unvollständig.
Damit bleibt die Frage nach dem Einstiegszeitpunkt.
Wann lohnt sich für einen Betrieb eine eigene Android-App?
Eine eigene Android-Anwendung lohnt sich, wenn ein wiederkehrender Ablauf heute mobil stattfindet, auf Papier erfasst und später im Büro nachgetragen wird. Dann steht die Entwicklung nicht gegen ein anderes Produkt, sondern gegen die Kosten der doppelten Erfassung.
Vorausgesetzt ist dabei ein Gerätebestand, der sich beschreiben lässt. Wo jedes Gerät privat beschafft wurde und kein Mindeststand festgelegt werden kann, wächst der Prüfaufwand schneller als der Nutzen, und eine Anwendung im Browser ist die ruhigere Wahl. Ebenso scheidet die Eigenentwicklung aus, wo ein Standardprodukt den Ablauf bereits abdeckt und nur die Gewohnheit dagegen spricht.
Nicht lohnend ist die Android-Entwicklung dort, wo die Anwendung ausschließlich Daten anzeigt und ohnehin eine Verbindung voraussetzt. Der Zugriff auf Kamera, Standort oder Hintergrundprozesse ist das Merkmal, an dem sich der Bedarf für eine installierte Anwendung ablesen lässt, und fehlt er, bleibt die aufwendigere Variante ohne fachlichen Gegenwert.
