Ein Hinweis von Apple oder Google mit der Aufforderung zum Update kann Code, ein Store-Formular oder beides betreffen. Prüfe zuerst, welche App und welcher Build gemeint sind, welche Frist gilt und welchen Status die Konsole zeigt. Leite daraus die kleinste sichere Änderung ab und prüfe den tatsächlich signierten Release-Kandidaten. Die Frist beeinflusst die Planung; sie beweist nicht, dass jede App neu gebaut werden muss.
Lies den genauen Hinweis in der Konsole
Öffne den Hinweis im Entwicklerkonto, dem die App gehört. Halte fest:
- App, Plattform, betroffener Track und genaue Version oder Build-Nummer.
- Geforderte Aktion, Frist, aktueller Status und Folgen bei Fristablauf.
- Ob es um eine neue Einreichung, die Sichtbarkeit einer bestehenden App, ein Store-Formular oder das Binärpaket geht.
Verwechsle die SDK-Angaben nicht
Unter Android legt die Ziel-API fest, für welches Plattformverhalten die App ausgelegt ist. Das Compile- oder Build-SDK bezeichnet Toolchain und APIs, mit denen sie gebaut wird; min SDK bestimmt die älteste installierbare Android-Version. Bei Apple sind das für den Upload erforderliche Xcode und iOS-SDK vom Deployment Target getrennt, also der niedrigsten unterstützten iOS-Version. Eine höhere Ziel- oder Upload-SDK-Version hebt das Mindestbetriebssystem nicht automatisch an. Eine geänderte Zahl macht auch keine inkompatible Abhängigkeit, Berechtigung, Manifest-Angabe oder SDK-Verhaltensänderung sicher.
Finde die tatsächliche Änderung
Nehmen wir eine fiktive Android-App, deren Play-Console-Hinweis Ziel-API 36 verlangt. Vor jeder Änderung prüft der Kontoinhaber in der Konsole die App, den betroffenen Release, die Frist und den Status. Das Team prüft, ob alle Plugins und eingebetteten SDKs mit diesem Ziel gebaut werden und funktionieren. Danach prüft es Plattformänderungen, Berechtigungen und Manifest-Angaben. Eine höhere Versionsnummer kann zwar den Build ermöglichen, während eine Bibliothek die Anmeldung oder Push-Nachrichten weiterhin stört.
- Prüfe Abhängigkeiten und datenschutzrelevante SDKs; aktualisiere oder ersetze inkompatible Komponenten.
- Prüfe Manifest-Einträge, Laufzeitberechtigungen und dazugehörige Store-Angaben.
- Prüfe Hinweise zur Kontolöschung und Altersfreigaben, falls sie zutreffen; diese Beispiele gelten nicht für jede App.
- Kläre, ob der Hinweis eine Korrektur von Metadaten oder Formularen zulässt oder ein neues Binärpaket verlangt.
Behalte den Release unter Kontrolle
Arbeite auf einem gepflegten Release-Branch, bewahre Quellcode und Build der letzten Freigabe auf und dokumentiere geänderte Versionen. Wenn der Hinweis es erlaubt, kann eine reine Metadatenkorrektur in der Konsole erfolgen. Änderungen an Code, SDK oder Manifest erfordern ein neues signiertes Binärpaket.
- Erstelle den Release-Kandidaten mit der benötigten Toolchain und Signierung. Ordne ihn dem gepflegten Release-Branch zu.
- Installiere den signierten Build auf unterstützten echten Geräten. Ein Entwicklungs-Build allein prüft den Release-Kandidaten nicht.
- Prüfe die echten Nutzerabläufe erneut. Teste Anmeldung, Kauf und Wiederherstellung, Push-Nachrichten und Deeplinks, sofern die App sie verwendet.
- Lade ihn in einen internen oder geschlossenen Test-Track hoch. Prüfe App, Version, Berechtigungen und Startverhalten im installierten Build.
Test, Review und Freigabe sind getrennte Schritte
Ein Test-Upload erlaubt keine öffentliche Veröffentlichung. Externe TestFlight-Tests können eine Beta-Prüfung erfordern. Vereinbare Tests, Prüfung und Veröffentlichung jeweils mit dem Kontoinhaber. Der Kunde behält Store-Konten, Quellcode und Signierungszugang. Vereinbare Wartung, ASO und App-Betreuung oder Modernisierung separat. Unser Leitfaden zu Prüfzeiten hilft bei der Planung.
- Hinweis einordnen
- Begrenzte Änderung umsetzen
- Signierten Build prüfen
- Kontoinhaber gibt nächsten Schritt frei
Test, Review-Einreichung und öffentliche Veröffentlichung sind getrennte Entscheidungen.
Geprüft am 4. November 2026: Google Play verlangt API 36 für gewöhnliche Smartphone-App-Einreichungen; für die Sichtbarkeit bestehender Apps gelten andere Regeln. Apples aktuelle Upload-Vorgaben umfassen Xcode 26 und das iOS-26-SDK. Angekündigte Vorgaben für 2027 gelten erst künftig. Prüfe Frist und Umfang im Hinweis für deine eigene App.