Die wichtigsten Erkenntnisse
- Berücksichtige bei der Migration auf FlutterFire 5.0, welche Lernenden das Angebot nach dem Release noch erreichen können.
- Firebase Flutter minSdk 24 ist eine Vorgabe für Abhängigkeiten. Ob ein Gerät unterstützt wird, lässt sich daraus allein nicht ableiten.
- Teste die Integration in die Host-App und kritische Lernabläufe auf echten Gerätegruppen.
- Rolle Releases schrittweise aus, halte Ausweichkanäle bereit und miss, ob Lernende ihre Aufgaben erfolgreich erledigen.
- Werte Reichweite und Abschlüsse nach Gerätegruppe aus, zusätzlich zu absturzfreien Sitzungen.
Ein ungeplanter Ausschluss von Geräten
Am 15. Oktober 2026 erschien Flutter BoM 5.0.0 mit großen Plugin-Releases, darunter `firebase_auth` 7.0.0, `firebase_ai` 5.0.0, `cloud_firestore` 7.0.0 und `firebase_messaging` 17.0.0. In den Release Notes steht außerdem, dass viele Android-Komponenten auf Firebase BoM 35 basieren und minSdk 24 erfordern. Das verändert die Diskussion über ein Release. Ein Lernmodul kann technisch besser werden, während ein Teil der Lernenden es nicht mehr erreichen kann. (firebase.google.com)
API-Level 24 entspricht Android 7.0, wie die Plattformreferenz von Android zeigt. Daraus lässt sich nicht ablesen, wie viele Lernende ein Fintech verliert. Für Produkt- und Entwicklungsteams ist es aber ein Signal, die Mindestanforderungen an Geräte über den Build hinaus zu betrachten. Ob ein mobiles Lernangebot die vorhandenen Geräte unterstützt, beeinflusst auch die Aktivierung und Bindung: in Netzwerken von Finanzvermittlern, bei Einsätzen in ländlichen Regionen und in Fintech-Produkten für Endkunden, die ihre Geräte lange nutzen. (developer.android.com)
Ein Release wird zur Reichweitenentscheidung
FlutterFire 5.0 ist kein kleines Bibliotheksupdate. Das Release nennt inkompatible Änderungen bei Auth, Firestore, AI, Core, App Check, Analytics, Crashlytics, Remote Config, Messaging und weiteren Komponenten. Die Angabe Firebase Flutter minSdk 24 sollte deshalb eine Prüfung des aufgelösten Builds auslösen – nicht die pauschale Annahme, dass jede bestehende Host-App gleich betroffen ist. Wo die Kompatibilitätsgrenze der Android-Lern-App tatsächlich liegt, bestimmen der Abhängigkeitsgraph der Host-App, der Manifest-Merge, die Flutter-Version, nativer Code und die tatsächlich eingebundenen Firebase-Plugins. (firebase.google.com)
Prüfe vor einem Release der Client- oder Host-App anhand folgender Nachweise, welche Lernenden du weiterhin erreichst:
- Untersuche den Abhängigkeitsgraphen der Produktionsversion und das generierte Manifest des Release-Kandidaten.
- Baue und installiere den Kandidaten auf repräsentativen Gerätegruppen mit unterschiedlichen API-Levels, ABIs, Speichergrößen und Netzbedingungen.
- Teste Login, App Check, Start einer Lektion, Fortschrittssynchronisierung und Benachrichtigungen vollständig durch.
- Gleiche die unterstützten Geräte mit dem aktuellen Gerätebestand der Lernenden und Interessierten ab.
- Lege für jeden Reichweitenrückgang eine klare geschäftliche Schwelle fest und benenne die verantwortliche Person fürs Release.
Erst die Gerätegruppen prüfen, dann das Feature freischalten
Globale Zahlen zur Android-Verbreitung ersetzen keine Daten aus dem eigenen Mandanten. Gruppiere aktive und zuletzt aktive Lernende nach Android-API-Level, App-Version, Gerätemodell, Markt, Verbindungsmuster und kritischen Nutzungsschritten. Ergänze, soweit vorhanden, Bestandslisten der von Partnern verwalteten Geräte. Auch historische Daten sind wichtig: Wer durch eine höhere Mindestversion ausgeschlossen wird, taucht bei den Neuinstallationen oft gar nicht mehr auf.
Entscheidend ist nicht nur, ob die neue App startet. Miss den Anteil der vorgesehenen Lernenden, die die Akademie erreichen, sich anmelden, ein Pflichtmodul beginnen, eine Lektion abschließen, ihren Fortschritt nach einer Unterbrechung behalten und eine hilfreiche Abschluss- oder Erinnerungsnachricht erhalten. So wird die Bereitstellung eines eingebetteten LMS mit Flutter anhand konkreter Abläufe messbar, statt nur einen technischen Integrationsstatus zu beschreiben.
Die Host-App ist die eigentliche Integrationsgrenze
Ein eingebettetes Flutter-Modul arbeitet nicht isoliert. Flutter unterstützt Add-to-App-Module in bestehenden nativen Anwendungen. Die Dokumentation macht jedoch klar, dass Plugins Android-Abhängigkeiten in die übergeordnete App einbringen können und einige erforderliche Anpassungen am nativen Projekt dort erfolgen müssen. Ein erfolgreicher Build auf Modulebene ist kein ausreichender Beleg dafür, dass das Release der Host-App sicher ist. (docs.flutter.dev)
Für eine App-Learning-Integration solltest du die Übergabe der Identität von der Host-App an die Akademie, die Token-Aktualisierung nach dem Hintergrundmodus, Deep Links zu zugewiesenen Inhalten, die Weiterleitung von Benachrichtigungen, die Offline-Erfassung von Fortschritten und den Abgleich mit dem Server prüfen. Nimm Ein- und Austrittspunkte in den Testplan auf. Wer ein Quiz abschließt, aber nicht zum Finanzprodukt zurückkehren kann, hat den Weg durch das Produkt nicht abgeschlossen.
Good to know
Schließt FlutterFire 5.0 automatisch jedes Gerät unter Android 7.0 aus?
Nein. Die relevanten FlutterFire-Plugins verlangen Android minSdk 24, doch das Ergebnis in der Praxis hängt davon ab, welche Plugins die Host-App auflöst und wie ihr finaler Android-Build konfiguriert ist. Prüfe die FlutterFire Release Notes und verifiziere das Produktionsartefakt, statt die Unterstützung aus einer einzelnen Abhängigkeitsangabe abzuleiten.
Welche Nutzergruppen sollten bei der Reichweite berücksichtigt werden?
Relevant sind Lernende, die die Akademie brauchen, nicht nur kürzlich installierte Apps. Ausgangspunkt sind aktive und zuletzt aktive Nutzer, segmentiert nach OS-Version, Version der Host-App, Markt, Gerätefamilie und – sofern verfügbar – partnerverwaltetem Gerätebestand. Beziehe auch potenzielle oder inaktive Gruppen ein, wenn eine verpflichtende Bildungskampagne sie ansprechen wird.
Was muss ein Ausweichweg gewährleisten?
Mindestens erhalten bleiben müssen authentifizierter Zugriff, der zugewiesene Lernpfad, Nachweise über Abschlüsse und ein Weg zurück ins Host-Produkt. Ein Ausweichweg, der Lernende zur Wiederholung zwingt oder einen nicht überprüfbaren Abschluss erzeugt, erhöht den Supportaufwand, statt das Release-Risiko zu senken.
Ein Rollback muss Lernende schützen
Rolle die Migration schrittweise für einzelne Nutzergruppen aus. Halte das vorherige Modul-Artefakt und die festgeschriebenen Abhängigkeitsversionen bereit. Nutze Remote Config oder einen Kill Switch in der Host-App, um den Einstieg ins Lernangebot auszublenden, wenn ein kritischer Ablauf scheitert. Biete Geräten, die nach dem Update nicht mehr unterstützt werden, einen klaren Ausweichweg: etwa das mobile Web, einen schlanken bisherigen Ablauf oder einen begleiteten Kanal für Pflichtschulungen. Dabei müssen Identität und Abschlussdaten erhalten bleiben, sofern das erforderlich ist.
Prüfe die Geräteabdeckung deiner Lernenden vor dem nächsten SDK-Release.
Jetzt prüfenReichweite ist die Release-Kennzahl
Ergänze die Zahl absturzfreier Sitzungen um eine kompakte Übersicht: unterstützte Geräte der Lernenden, erfolgreiche Aufrufe der Akademie, Logins, Lektionsstarts, Lektionsabschlüsse, erfolgreiche Fortschrittssynchronisierungen und zugestellte Benachrichtigungen. Werte jede Kennzahl nach Android-Version, Version der Host-App, Markt und Partnermandant aus. Stabile Gesamtwerte können Probleme einzelner Außendienstgruppen verdecken.
Die Prüfung der Lernendenabdeckung spricht nicht gegen FlutterFire 5.0. Sie macht den Zielkonflikt sichtbar. Sicherheit, Plattformunterstützung und neue Funktionen sind wichtig. Genauso wichtig ist, dass ein Außendienstmitarbeiter oder Neukunde das Produkt genau dann kennenlernen kann, wenn es darauf ankommt. Bei eingebetteten Lernangeboten ist ein Release erst abgeschlossen, wenn die vorgesehenen Lernenden es weiterhin erreichen, ihm vertrauen und es abschließen können.
