Das Wichtigste in 60 Sekunden / tl;dr
- Eine funktionierende installierte App ist nicht automatisch bereit für ein neues Store-Update.
- Apple und Google verlangen aktuelle Entwicklungsgrundlagen. Flutter allein nimmt dir diese Plattformpflege nicht ab.
- Prüfe Store-Hinweise, reproduzierbaren Build, Abhängigkeiten und die wichtigsten Nutzerabläufe.
- Plane Verantwortliche, Wartungsbudget und Testzeit ein. Eine Versionsnummer hochzusetzen reicht nicht.
01
Was 2026 konkret zu prüfen ist
Für neue Android-Handy-Apps und Updates verlangt Google Play seit 31. August 2026 grundsätzlich Ziel-API 36. Für Bestands-Apps gilt eine eigene Verfügbarkeitsregel mit Ziel-API 35. Sondergeräte haben andere Grenzen. Eine beantragbare Verlängerung reicht bis 1. November 2026; prüfe den tatsächlich gewährten Status in der Play Console.
Apple verlangt seit 28. April 2026 für iOS-/iPadOS-Uploads das SDK 26 oder neuer. SDK bezeichnet das Entwicklungspaket, mit dem die App gebaut wird.
Nicht mit Abschaltung verwechseln
Diese Anforderungen bedeuten nicht, dass jede bereits installierte App an einem Stichtag aufhört zu funktionieren. Ebenso ist Androids Ziel-API nicht die niedrigste unterstützte Android-Version. Deshalb zuerst die konkrete Store-Meldung lesen, dann Maßnahmen planen.
02
Was bei einer Flutter-App gepflegt werden muss
Flutter bildet einen gemeinsamen Entwicklungsrahmen für mehrere Plattformen. Ein Release hängt trotzdem auch an Android- und Apple-Werkzeugen sowie den verwendeten Erweiterungen, den Plugins. Kamera, Push-Nachrichten oder Zahlungen sind typische Berührungspunkte mit der Plattform.
Flutter selbst und die eingebundenen Pakete werden getrennt aktualisiert. Die offizielle Anleitung beschreibt dafür unter anderem flutter upgrade und flutter pub outdated. Das sind Werkzeuge zur Bestandsaufnahme und Aktualisierung, kein Beleg dafür, dass anschließend alle Funktionen stimmen.
Quellen (1)
03
Meine empfohlene Wartungscheckliste
Eine kleine Liste mit einem klaren Ergebnis pro Punkt ist hilfreicher als ein pauschales „alles aktualisieren“.
Zugänge und Fristen sichern
Eine verantwortliche Person kennt die Store-Konten, Hinweise und nötigen Freigaben. Ablaufdaten von Signierung und Zertifikaten erfassen; Zugang nicht an eine einzelne Privatperson binden.
Einen frischen Build erstellen
Lässt sich die aktuelle Version aus dem Quellcode auf einer sauberen Umgebung bauen? Werkzeugversionen, Abhängigkeiten und Signierungsablauf dokumentieren. Ein altes Installationspaket genügt nicht.
Updates begrenzen und prüfen
Release-Hinweise lesen, nicht mehr gepflegte Plugins erkennen und Änderungen in nachvollziehbaren Schritten durchführen. Funktionserweiterungen möglichst nicht gleichzeitig einschieben.
Echte Abläufe testen
Auf repräsentativen Geräten Login, Berechtigungen, Push, Kamera, Bezahlung und Offline-Verhalten prüfen, soweit die App diese Funktionen nutzt. Auch das Update einer bereits installierten Version testen.
Veröffentlichung begleiten
Testversion freigeben lassen, Store-Prüfung zeitlich einplanen und nach dem Rollout Abstürze sowie Supportmeldungen beobachten. Vorher festlegen, wer bei Problemen reagiert.
04
Beispiel: Die Kamera öffnet sich, aber der Upload scheitert
Fiktives Beispiel: Eine Service-App startet nach einem Update und zeigt alle Aufträge an. Erst beim Fotografieren eines Schadens fällt auf, dass ein geänderter Berechtigungsablauf nicht sauber behandelt wird. Der Startbildschirm war also kein ausreichender Test.
Ein sinnvoller Abnahmetest lautet: Bestehende App aktualisieren, Anmeldung beibehalten, Kamerazugriff zunächst ablehnen, danach erlauben und ein Foto hochladen. Das Ergebnis muss anschließend auch im Backend beim richtigen Auftrag erscheinen. Solche fachlichen Tests verbinden technische Wartung mit dem tatsächlichen Nutzen der App.
05
Wie viel Wartung ist sinnvoll?
Mein Vorschlag: Store-Hinweise und sicherheitsrelevante Meldungen laufend an eine zuständige Person leiten, monatlich kurz sichten und vor jedem Release die Checkliste durchgehen. Größere Versionswechsel bekommen einen eigenen Testtermin. Kritische Probleme warten nicht auf den nächsten Routinetermin.
Der Aufwand hängt von Plugins, unterstützten Geräten, Backend-Anbindung und Testabdeckung ab. Vereinbare konkret, ob nur Updates auf Abruf oder auch Beobachtung, regelmäßige Builds und Reaktionszeiten enthalten sind. „Wartung inklusive“ ohne Umfang hilft im Ernstfall niemandem.
06
Kurze Antworten
Muss ich die App jedes Jahr neu entwickeln?
Nein. Wartung erhält die bestehende Anwendung. Größere Umbauten können bei veralteten oder aufgegebenen Abhängigkeiten nötig werden, sind aber keine automatische Jahrespflicht.
Reicht es, nur das Ziel-API-Level zu erhöhen?
Nein. Das ändert eine technische Deklaration, ersetzt aber weder Anpassungen an geändertes Plattformverhalten noch Tests.
Kann ich eine fehlerhafte Store-Version sofort zurückrollen?
Verlass dich nicht darauf. Bereits installierte Versionen lassen sich nicht wie ein Server-Deployment einfach austauschen. Plane einen korrigierten Build, den jeweiligen Store-Prozess und gegebenenfalls serverseitig abschaltbare Funktionen ein.