Mobile App übergeben: Checkliste für Quellcode, Zugänge und Updates

Zuständigkeiten, Zugänge und Nachweise festhalten

Eine APK, eine IPA oder ein Store-Link zeigt ein Ergebnis. Daraus geht noch nicht hervor, wer den Quellcode ändern, einen Dienst verlängern oder ein Update einreichen kann. Nutzen Sie die folgende Tabelle während der gemeinsamen Übergabe, nicht nur als Wunschliste für Dateien.

Unterscheiden Sie zwischen der Person oder Organisation, die für einen Bestandteil verantwortlich ist, und den Berechtigungen, die eine betreuende Person für ihre vereinbarten Aufgaben benötigt. Halten Sie die vertraglichen Rechte an Quellcode und lizenzierten Materialien gesondert fest: Der Zugriff auf ein Repository allein belegt diese Rechte nicht.

Bei einem neuen Projekt gehören diese Übergabeanforderungen bereits in das MVP-Briefing für eine mobile App (Englisch). Bei einer bestehenden App ist die tatsächlich veröffentlichte Version der Ausgangspunkt. Nehmen Sie nicht an, dass die neueste Datei in einem geteilten Ordner auch den Quellcode des Releases enthält.

Den Build unabhängig vom bisherigen Laptop prüfen

Legen Sie den genauen Commit oder Release-Tag fest, der übergeben wird. In einem frischen Arbeitsverzeichnis sollte eine berechtigte betreuende Person die dokumentierte Einrichtung mit einer Testumgebung und fiktiven Daten durchführen. Erfassen Sie die erforderlichen Flutter- und Plattformwerkzeug-Versionen, die Lockdatei für Abhängigkeiten, die Namen der Umgebungskonfigurationen, die Build-Variante und gegebenenfalls die Schritte zur Erzeugung von Assets.

Die Flutter-Referenz für die Kommandozeile (Englisch) beschreibt unter anderem flutter --version, flutter doctor, flutter pub get, flutter analyze und flutter test. Diese Prüfungen sind hilfreich. Die README muss aber zusätzlich den projektspezifischen Build-Befehl und die dazugehörige Konfiguration nennen. Projekte mit Flavors, generierten Dateien oder nativen Abhängigkeiten können weitere Schritte erfordern.

Kopieren Sie bei einer fehlenden Konfiguration nicht einfach den gesamten Benutzerordner des bisherigen Entwicklers. Dokumentieren Sie jeden benötigten Bestandteil, seinen Zweck und den geschützten Weg, über den er bereitgestellt wird. Relevante Quelldateien für Grafiken und Anleitungen zur Dateierzeugung gehören zur Übergabe; private Zugangsdaten gehören nicht ins Repository.

Lassen Sie Quellcode-Revision, Werkzeuge, Umgebung und erzeugte App-Version protokollieren. Damit wird geprüft, ob der dokumentierte Ablauf nutzbar ist. Es wird nicht behauptet, dass jede neu gebaute Binärdatei Byte für Byte identisch ausfallen muss. Falls der Build scheitert, bleiben Ursache und notwendige Korrektur auf der Liste offener Punkte. Die Übergabe ist damit noch nicht abgeschlossen.

Berechtigungen für Signierung und das nächste Update prüfen

Eine Debug-App zu bauen, einen signierten Release zu erstellen und diesen Release einreichen zu dürfen, sind drei unterschiedliche Prüfungen. Lassen Sie den vereinbarten Veröffentlichungsweg nachvollziehen, ohne eine nicht genehmigte Änderung am Produktivsystem vorzunehmen.

Googles Dokumentation zu Play App Signing (Englisch) unterscheidet zwischen dem Schlüssel zur Authentifizierung von Uploads und dem Schlüssel, mit dem die an Nutzer ausgelieferten Apps signiert werden. Klären Sie, welches Verfahren diese App verwendet. Ein von Google verwalteter App-Signierschlüssel ist nicht einfach eine Datei, die Sie vom Auftragnehmer verlangen können. Regeln Sie den geschützten Zugriff auf die Upload-Signierung und dokumentieren Sie, wer für eine Wiederherstellung zuständig ist.

Der Flutter-Leitfaden für Android-Releases (Englisch) warnt ausdrücklich davor, den Keystore und die Signierungseinstellungen in die Versionsverwaltung aufzunehmen. Das Übergabedokument sollte beschreiben, wo berechtigter Zugriff verwaltet wird. Es sollte keine geheimen Werte enthalten.

Für iOS beschreibt der Flutter-Release-Leitfaden (Englisch) die Nutzung von Xcode unter macOS und der richtigen Apple-App-Kennung. Prüfen Sie das tatsächlich im Projekt verwendete Signierungsverfahren. Apples Dokumentation zur Benutzerverwaltung (Englisch) unterscheidet zwischen Einzel- und Organisationsmitgliedschaften und weist darauf hin, dass der Zugriff auf Zertifikate die Sichtbarkeit von Apps erweitern kann. Wählen Sie passende Berechtigungen. Nicht jede mitarbeitende Person benötigt eine Admin-Rolle oder das geteilte Passwort eines Apple Accounts.

Dienste, Materialien und Betriebsabläufe erfassen

Listen Sie auch externe Dienste auf, die auf keinem App-Bildschirm sichtbar sind: Anmeldung, Datenspeicherung, Benachrichtigungen, Käufe, Absturzberichte, Werbung, E-Mail, Domains und zeitgesteuerte Aufgaben. Kennzeichnen Sie ausdrücklich, was nicht verwendet wird. Für jeden aktiven Dienst halten Sie Umgebung, Kontoinhaber, Abrechnungs- oder Verlängerungsverantwortung, Zugangsmethode und die Folgen eines Ausfalls fest.

Fordern Sie Konfigurationsanleitungen an, keine E-Mail voller produktiver Zugangsdaten. Nutzen Sie Einladungen und auf die Aufgabe begrenzte Berechtigungen, soweit der Dienst dies unterstützt. Die Repository-Rollen für GitHub-Organisationen (Englisch) ermöglichen beispielsweise Zugriffsrechte entsprechend den Aufgaben einer mitarbeitenden Person. Andere Kontotypen und Dienste haben eigene Berechtigungsmodelle.

Zur Übergabe gehören bearbeitbare Store-Grafiken, Produkttexte, Lizenznachweise für Materialien Dritter und die Datenschutzerklärungs-URLs, die die veröffentlichte App verwendet. Klären Sie, wer die Angaben in den Stores aktuell hält, wenn ein SDK oder eine Funktion geändert wird. Wenn Käufe zum Projektumfang gehören, dokumentieren Sie deren Produkt-IDs und Konfiguration, aber keine Zugangsdaten zu Zahlungskonten.

Für lokale Daten oder ein Backend dokumentieren Sie die Wiederherstellungs- und Migrationsabläufe, die tatsächlich unterstützt werden. Nutzen Sie bei unklaren Zusagen das Arbeitsblatt zu lokalem Speicher, Backups und Cloud-Synchronisierung (Englisch). Ein exportierter Bericht, ein Server-Zugang oder eine Sicherung des Repositorys belegt für sich allein noch nicht, dass Nutzerdaten wiederhergestellt werden können.

Eine kleine, konkrete Übergabeprobe durchführen

Als Beispiel dient eine fiktive Lesetagebuch-App. In der vereinbarten Version lassen sich Titel und Datum speichern, ein Eintrag bearbeiten und die Daten nach erneutem Öffnen der App weiter abrufen. Die folgende Probe prüft die Übergabe und den Betrieb, nicht die Frage, welche neuen Funktionen noch entwickelt werden sollen.

Flutter unterscheidet Unit-, Widget- und Integrationstests (Englisch). Fragen Sie, was die Testsuite tatsächlich prüft. Ein erfolgreicher Unit-Test ersetzt weder die Prüfung des vollständigen Nutzungsablaufs in einer installierten App noch die Prüfung plattformspezifischer Berechtigungen.

Nutzen Sie für Käufe, Benachrichtigungen und Schreibzugriffe auf Server eine Sandbox oder einen genehmigten Testweg. Führen Sie keine Löschungen, Abrechnungsänderungen oder Releases im Produktivsystem aus, nur um Zugriff zu demonstrieren. Halten Sie den vereinbarten Lieferstatus klar fest: Quellcode-Übergabe, Beta-Verfügbarkeit, Einreichung und öffentliche Veröffentlichung sind unterschiedliche Meilensteine.

Abnahme dokumentieren und Zugänge sicher umstellen

Übernehmen Sie die folgenden Felder in ein privates Übergabeprotokoll. Jeder Punkt erhält den Status „geprüft“, „nicht zutreffend“ oder „offen“, jeweils mit Nachweis oder Begründung. Fügen Sie keine Tokens, Passwörter, Signierschlüssel oder echten Nutzerdatensätze aus dem Produktivsystem ein.

• App und Release: Produktname, Plattformkennungen, übergebene Revision und Version.
• Übernehmende Person und Verantwortliche: Neue betreuende Person und zuständiger Inhaber jedes aktiven Kontos.
• Build-Ergebnis: Umgebung, verwendete Anleitung, erzeugtes Artefakt und fehlende Schritte.
• Ergebnis der Nutzungsprüfung: Vereinbarte Testfälle, tatsächliches Verhalten und verbleibende Fehler.
• Release-Ergebnis: Geschützter Signierungszugang, berechtigte Rolle für die Einreichung und vereinbarter Lieferstatus.
• Betriebsunterlagen: Dienstübersicht, bearbeitbare Designs, Lizenzen, Wiederherstellungsanleitung und Support-Hinweise.
• Offene Punkte: Problem, Folgen, zuständige Person und vereinbartes weiteres Vorgehen. Blockierende Punkte dürfen nicht stillschweigend entfallen.
• Zugangsübergang: Künftige Betreuungsrollen, genehmigte Schritte zur Entfernung von Zugängen und der Zeitpunkt ihrer Prüfung.

Prüfen Sie zuerst, ob der neue Zugang funktioniert, bevor Sie einen für den vereinbarten Übergang noch benötigten Zugang entfernen. Überprüfen Sie unnötige Einladungen und Tokens in den jeweils zuständigen Diensten. Wurde ein Geheimnis geteilt oder offengelegt, vereinbaren Sie einen geeigneten Austausch der Zugangsdaten und prüfen Sie abhängige Systeme. Kontoübertragungen, Release-Änderungen und die Entfernung von Zugängen benötigen jeweils eigene, autorisierte Schritte.

Moocsoft bietet die Entwicklung mobiler Apps mit Flutter an. Dieses Arbeitsblatt macht das Übergabeziel im Projektgespräch konkret: eine wartbare App mit bekannten Zuständigkeiten und geprüftem Ablauf statt eines unerklärten Dateipakets. Weitere Informationen finden Sie auf der Seite zur Flutter-App-Entwicklung (Englisch).