App-Entwicklung für iOS und Android nach Ihrem Bedarf

Flutter und plattformspezifisches Geräteverhalten

Bei der App-Entwicklung werden gemeinsame Gestaltung und plattformspezifisches Verhalten getrennt betrachtet. Flutter ermöglicht eine gemeinsame Codebasis für iOS und Android; Benachrichtigungsberechtigungen, Zurück-Gesten, Tastatur, Dateiauswahl und Hintergrundausführung werden dennoch gesondert geprüft. Die tatsächlichen Nutzungsaufgaben bestimmen die Technologiewahl. Das Einlesen von Dokumenten mit der Kamera und eine dauerhafte Bluetooth-Verbindung sind nicht dieselbe Anforderung. Dass ein Plugin verfügbar ist, bedeutet noch nicht, dass das benötigte Verhalten auf den Zielgeräten bestätigt wurde.

Plattformspezifische Entwicklung

Eine getrennte Entwicklung mit Swift und Kotlin kann bei Projekten mit intensivem Hardwarezugriff in Betracht kommen. Auch innerhalb von Flutter lässt sich der erforderliche Teil in plattformspezifischem Code schreiben. Diese Entscheidung wird unter Berücksichtigung des Wartungsaufwands, der Betriebssystemänderungen und der Plugin-Abhängigkeiten erläutert. Ein Prototyp, der auf einem einzelnen Smartphone funktioniert, steht nicht für das gesamte Gerätespektrum. Unterstützte Versionen, der Umfang für Smartphones und Tablets, die Bildschirmausrichtung und Anforderungen an die Barrierefreiheit werden zu Beginn schriftlich festgehalten.

Abnahme auf dem Gerät

Zur Abnahme gehört, dass Schaltflächen bei großer Schrift nicht verschwinden, Screenreader die Felder in der richtigen Reihenfolge vorlesen und Vorgänge auch bei geöffneter Tastatur abgeschlossen werden können. Bei schwacher Verbindung werden statt eines leeren Bildschirms Lade-, Fehler- und Wiederholungszustände angezeigt. Wechselt der Nutzer während der Zahlung zu einer anderen App oder beendet das Betriebssystem den Prozess, kann die Aufgabe unvollständig bleiben. Der erneut geöffnete Bildschirm darf nicht versehentlich einen zweiten Vorgang auslösen.

Die Sitzungsdauer und die Sichtbarkeit sensibler Ansichten werden entsprechend dem Nutzungskontext festgelegt. Wichtig sind der Widerruf des Zugriffs auf einem verlorenen Gerät, das Löschen lokaler Informationen des vorherigen Nutzers beim Kontowechsel und die Berechtigungsprüfung beim erneuten Öffnen der App. Bei der Abnahme werden nicht nur erfolgreiche Anmeldungen, sondern auch abgelaufene Sitzungen und geänderte Nutzerberechtigungen getestet. Die Unterscheidung zwischen den Informationen auf dem Bildschirm und dem vom Server akzeptierten Vorgang ist eine Grundlage der Konzeption.

App aus dem Store oder PWA?

Der Bedarf an einem mobilen Kanal bedeutet nicht, dass jeder Besucher eine App installieren muss. Erfolgt der erste Kontakt über die Suche, ist die Nutzung selten und geht es hauptsächlich um Informationen, kann eine mobiloptimierte Website geeignet sein. Regelmäßige Sitzungen, Gerätefunktionen und tägliche Außendienstaufgaben verleihen einer Store-App einen anderen Nutzen. Die Entscheidung richtet sich danach, ob der zusätzliche Installationsaufwand für die Nutzer gerechtfertigt ist.

Eine PWA ist eine Webanwendung, die über den Browser bereitgestellt wird und unter geeigneten Bedingungen zum Startbildschirm hinzugefügt werden kann. Offline-Start, Benachrichtigungen und Hintergrundaufgaben hängen vom Browser und Betriebssystem ab. Es wird nicht vorausgesetzt, dass sie auf jedem Gerät sämtliche Funktionen einer Store-App bietet. Die benötigte Aufgabe wird auf den Zielgeräten erprobt; die einfache Verteilung über eine Webadresse und die Einschränkungen des Browsers werden gemeinsam abgewogen.

Offline-Fähigkeit ist kein bloßes Etikett, sondern der definierte Umfang bestimmter Aufgaben. Das Lesen eines Katalogs birgt andere Risiken als das Erfassen einer Lieferung. Der Zeitpunkt der letzten Aktualisierung sollte angezeigt werden; es muss erkennbar sein, dass ein lokal erstellter Datensatz noch nicht vom Server akzeptiert wurde. Wie werden nach Wiederherstellung der Verbindung gelöschte Produkte, geänderte Berechtigungen oder inzwischen einem anderen Mitarbeiter zugewiesene Aufgaben behandelt? Solange diese Entscheidungen nicht schriftlich festgehalten sind, gilt die Offline-Funktion nicht als abgeschlossen.

Auch die Nutzungshäufigkeit der App wird bewertet. Für einen Vorgang, den der Nutzer nur einmal ausführt, können ein Store-Konto und der Aufwand für laufende Updates unnötig sein. Bei wiederkehrenden Aufgaben wie Lagerinventuren oder Servicebesuchen können dagegen Kamera und lokaler Gerätespeicher wichtig sein. Die Wahl richtet sich nach der Aufgabe des Nutzers und nicht nach einer gerade angesagten Technologie.

Unterschiedliche Regeln für Bestell-, Termin- und Außendienst-Apps

Shopping-Apps

Beim mobilen Einkauf muss der Warenkorb nicht nur sichtbar sein, sondern auch anhand aktueller Preise geprüft werden. Öffnet der Nutzer den Warenkorb einer früheren Sitzung, können sich Bestand und Lieferbedingungen geändert haben. Der Betrag wird auf dem Server berechnet; Änderungen werden erläutert. Bei der Rückkehr vom Zahlungsvorgang wird nicht vorausgesetzt, dass die App geöffnet bleibt. Das Ergebnis wird mit der Bestätigung des Zahlungsanbieters verknüpft. Über die E-Commerce-Infrastruktur lässt sich dieselbe Bestellung verwalten; das Aktualisierungs- und Fehlerverhalten der Ansichten muss jedoch festgelegt werden.

Termin-Apps

Bei Kliniken und Autovermietungen ist eine Verfügbarkeitsliste noch keine verbindliche Reservierung. Das vorläufige Blockieren einer Ressource, der Fristablauf und das Zahlungsergebnis werden als getrennte Zustände erläutert. Eine nicht zugestellte Erinnerungsbenachrichtigung macht die Buchung nicht ungültig. Stornierungen und Verschiebungen richten sich nach den Regeln des Unternehmens; die App zeigt diese Regeln an, bevor der Nutzer seine Entscheidung trifft.

Außendienst und interne Aufgaben

Bei Service- oder Lageraufgaben werden Fotos, Unterschriften, Barcodes und Standortdaten dem Arbeitsdatensatz zugeordnet. Ist bei verweigerter Standortberechtigung ein alternatives Vorgehen möglich oder muss die Aufgabe angehalten werden? Eine dauerhafte Überwachung der Mitarbeiter wird nicht vorausgesetzt. Bei schwacher Verbindung sind Fotogröße und Upload-Reihenfolge wichtig. Eine unvollständige Dateiübertragung darf nicht dazu führen, dass die Aufgabe fälschlich als abgeschlossen angezeigt wird.

Offline-Arbeitsaufträge können in einer lokalen Warteschlange gespeichert werden. Hat der Server die Aufgabe storniert oder einer anderen Person zugewiesen, entsteht ein Konflikt mit dem Datensatz auf dem Gerät. Es wird festgelegt, welches Feld maßgeblich ist und wann eine manuelle Prüfung erforderlich wird. Dieselbe erneut gesendete Aufgabe darf keinen zweiten Lieferdatensatz erzeugen. Nutzer müssen zwischen ausstehenden und abgelehnten Datensätzen unterscheiden können.

Die unternehmensinterne Verteilung ist nicht mit einer öffentlichen Store-Veröffentlichung gleichzusetzen. Die aktuellen Bedingungen der Optionen von Apple und Google, der Kontotyp und die Zielnutzer werden geprüft. Auch die Schulung findet auf dem Gerät statt: Mitarbeiter lernen nicht nur die Namen der Ansichten, sondern auch das Vorgehen bei Verbindungsabbrüchen, geänderten Berechtigungen und erneut geöffneten Aufgaben. So wertet das operative Team ausstehende Vorgänge nicht fälschlich als abgeschlossen.

Lebenszyklus von API, Benachrichtigungen und Client-Versionen

Der mobile Client verbindet sich nicht direkt mit der Datenbank, sondern führt Geschäftsvorgänge über eine API mit Zugriffskontrolle aus. Die Serverseite auf Basis von Laravel und MySQL verwaltet den Zugriff auf Datensätze und die Geschäftsregeln. Gültigkeitsdauer, Erneuerung und Widerruf der auf dem Smartphone gespeicherten Zugangsdaten bei Geräteverlust werden konzipiert. Der Anmeldebildschirm ist nicht die einzige Sicherheitsgrenze; jede Anfrage muss für den jeweiligen Vorgang autorisiert sein.

Nach der Veröffentlichung eines neuen Pakets aktualisieren nicht alle Nutzer gleichzeitig. API-Änderungen müssen deshalb auch ältere Clients berücksichtigen. Das Entfernen von Feldern, das Umbenennen von Zuständen oder das Hinzufügen von Pflichtangaben kann installierte Versionen beeinträchtigen. Unterstützte Versionen, Bedingungen für verpflichtende Updates und die angezeigte Meldung werden festgelegt. Inhaltsänderungen und Änderungen am App-Paket werden getrennt betrachtet.

Im Benachrichtigungsdienst kann sich das Geräte-Token ändern, der Nutzer kann sich abmelden oder Berechtigungen deaktivieren. Die Ansicht, die beim Antippen einer Benachrichtigung geöffnet wird, prüft die Berechtigung erneut. Statt sensibler Informationen auf dem Sperrbildschirm kann eine geeignete allgemeine Nachricht verwendet werden. Transaktionsbenachrichtigungen werden getrennt von Marketingnachrichten bewertet. Eine versendete Benachrichtigung ist nicht automatisch gelesen oder zugestellt.

Besondere Regeln werden im Rahmen der individuellen Softwareentwicklung, externe Dienste im Rahmen unserer Integrationslösungen geprüft. Die Webprojekte auf der Referenzseite können Anregungen zu Einsatzbereichen geben; sie werden nicht als Nachweis für in App-Stores veröffentlichte mobile Apps dargestellt. Für die mobile Abnahme sind Aufgaben auf realen Geräten, Berechtigungsszenarien und die Ergebnisse von Versionswechseln maßgeblich.

In Fehlerberichten dürfen Nutzerdaten nicht unnötig erhoben werden. Absturzprotokolle, Vorgangskennungen und Versionsinformationen dienen dazu, die Fehlerstelle zu untersuchen; geheime Sitzungswerte werden nicht protokolliert. Die Datenverarbeitung der Monitoring-Werkzeuge muss mit den Datenschutzangaben im Store übereinstimmen. Server- und App-Fehler werden getrennt diagnostiziert; das Warten auf eine Netzwerkantwort darf nicht mit dem Aufwand für die Darstellung der Benutzeroberfläche verwechselt werden.