LaunchLint Academy
Die kurze Antwort
Store-Anforderungen richten sich nach dem SDK, mit dem ein Build erstellt beziehungsweise auf das er ausgerichtet wurde, nicht nur nach der Betriebssystemversion auf deinem Testgerät.
- Prüfe die aktuellen Fristen direkt bei Apple und Google, ordne sie deinem Framework zu und teste alle Verhaltensänderungen, die durch ein höheres Target SDK aktiviert werden.
Nachweise für die Release-Freigabe
Prüfe target sdk, build sdk und store-mindestanforderungen nicht als isolierten Schalter, sondern im Zusammenhang mit Target SDK, Build SDK und Store-Mindestanforderungen, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.
Trenne bei Target SDK, Build SDK und Store-Mindestanforderungen drei Nachweise: statisch erkennbare Projektkonfiguration, Verhalten auf einem sauberen Gerät und externe Einstellungen in Apple Developer, App Store Connect oder Play Console. Erst wenn diese Ebenen denselben Release-Kandidaten beschreiben, ist die Prüfung belastbar. Dokumentiere Abweichungen mit Owner und Stop-Kriterium, statt sie als vermeintlichen Standardwert zu akzeptieren.
Nachweise für die Release-Freigabe
- Produktionswert für vier versionsbegriffe trennen eindeutig benannt
- Verantwortliche Projektdatei oder Store-Einstellung verlinkt
- Aufgelöste native Konfiguration kontrolliert
- Signiertes Artefakt auf sauberem Gerät geprüft
- iOS- und Android-Unterschiede dokumentiert
- Offene Abweichung mit Owner und Stop-Kriterium versehen
1. Vier Versionsbegriffe trennen
Unterscheide Betriebssystemversion, minSdk beziehungsweise Deployment Target, compile oder Build SDK und Target SDK.
Prüfe vier versionsbegriffe trennen nicht als isolierten Schalter, sondern im Zusammenhang mit Target SDK, Build SDK und Store-Mindestanforderungen, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.
Nachweise für die Release-Freigabe
- Produktionswert für vier versionsbegriffe trennen eindeutig benannt
- Verantwortliche Projektdatei oder Store-Einstellung verlinkt
- Aufgelöste native Konfiguration kontrolliert
- Signiertes Artefakt auf sauberem Gerät geprüft
- iOS- und Android-Unterschiede dokumentiert
- Offene Abweichung mit Owner und Stop-Kriterium versehen
2. Google-Frist bestimmen
Ermittle die aktuell geltende Target-API-Anforderung für neue Apps, Updates und bereits veröffentlichte Apps. Beachte Ausnahmen für besondere Geräteklassen.
Prüfe google-frist bestimmen nicht als isolierten Schalter, sondern im Zusammenhang mit Target SDK, Build SDK und Store-Mindestanforderungen, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.
Nachweise für die Release-Freigabe
- Produktionswert für google-frist bestimmen eindeutig benannt
- Verantwortliche Projektdatei oder Store-Einstellung verlinkt
- Aufgelöste native Konfiguration kontrolliert
- Signiertes Artefakt auf sauberem Gerät geprüft
- iOS- und Android-Unterschiede dokumentiert
- Offene Abweichung mit Owner und Stop-Kriterium versehen
3. Apple-Buildanforderung bestimmen
Prüfe die aktuell verlangte Xcode- und SDK-Generation. Deployment Target und Build SDK beantworten unterschiedliche Fragen.
Prüfe apple-buildanforderung bestimmen nicht als isolierten Schalter, sondern im Zusammenhang mit Target SDK, Build SDK und Store-Mindestanforderungen, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.
Nachweise für die Release-Freigabe
- Produktionswert für apple-buildanforderung bestimmen eindeutig benannt
- Verantwortliche Projektdatei oder Store-Einstellung verlinkt
- Aufgelöste native Konfiguration kontrolliert
- Signiertes Artefakt auf sauberem Gerät geprüft
- iOS- und Android-Unterschiede dokumentiert
- Offene Abweichung mit Owner und Stop-Kriterium versehen
4. Framework-Unterstützung prüfen
Ordne Expo SDK, React-Native-Version, Flutter Stable und Capacitor-Plattformpakete den benötigten nativen Toolchains zu.
Prüfe framework-unterstützung prüfen nicht als isolierten Schalter, sondern im Zusammenhang mit Target SDK, Build SDK und Store-Mindestanforderungen, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.
Nachweise für die Release-Freigabe
- Produktionswert für framework-unterstützung prüfen eindeutig benannt
- Verantwortliche Projektdatei oder Store-Einstellung verlinkt
- Aufgelöste native Konfiguration kontrolliert
- Signiertes Artefakt auf sauberem Gerät geprüft
- iOS- und Android-Unterschiede dokumentiert
- Offene Abweichung mit Owner und Stop-Kriterium versehen
5. Abhängigkeiten vor dem Upgrade prüfen
Native Module können eine neuere Toolchain, Manifeständerungen oder aktualisierte Datenschutzdateien benötigen.
Prüfe abhängigkeiten vor dem upgrade prüfen nicht als isolierten Schalter, sondern im Zusammenhang mit Target SDK, Build SDK und Store-Mindestanforderungen, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.
Nachweise für die Release-Freigabe
- Produktionswert für abhängigkeiten vor dem upgrade prüfen eindeutig benannt
- Verantwortliche Projektdatei oder Store-Einstellung verlinkt
- Aufgelöste native Konfiguration kontrolliert
- Signiertes Artefakt auf sauberem Gerät geprüft
- iOS- und Android-Unterschiede dokumentiert
- Offene Abweichung mit Owner und Stop-Kriterium versehen
6. Verhaltensänderungen testen
Ein höheres Android Target oder neues Apple SDK kann Berechtigungen, Hintergrundarbeit, Benachrichtigungen und Layoutverhalten ändern.
Prüfe verhaltensänderungen testen nicht als isolierten Schalter, sondern im Zusammenhang mit Target SDK, Build SDK und Store-Mindestanforderungen, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.
Nachweise für die Release-Freigabe
- Produktionswert für verhaltensänderungen testen eindeutig benannt
- Verantwortliche Projektdatei oder Store-Einstellung verlinkt
- Aufgelöste native Konfiguration kontrolliert
- Signiertes Artefakt auf sauberem Gerät geprüft
- iOS- und Android-Unterschiede dokumentiert
- Offene Abweichung mit Owner und Stop-Kriterium versehen
7. CI und lokale Builds angleichen
Dokumentiere Java, Gradle, Android Gradle Plugin, Xcode, CocoaPods und Build-Image. CI darf keinen anderen Kandidaten erzeugen.
Prüfe ci und lokale builds angleichen nicht als isolierten Schalter, sondern im Zusammenhang mit Target SDK, Build SDK und Store-Mindestanforderungen, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.
Nachweise für die Release-Freigabe
- Produktionswert für ci und lokale builds angleichen eindeutig benannt
- Verantwortliche Projektdatei oder Store-Einstellung verlinkt
- Aufgelöste native Konfiguration kontrolliert
- Signiertes Artefakt auf sauberem Gerät geprüft
- iOS- und Android-Unterschiede dokumentiert
- Offene Abweichung mit Owner und Stop-Kriterium versehen
8. Fristen als Wartungsprozess führen
Hinterlege Verantwortliche und regelmäßige Prüfung. Ein datierter Academy-Artikel ersetzt nie die aktuelle Store-Mitteilung.
Prüfe fristen als wartungsprozess führen nicht als isolierten Schalter, sondern im Zusammenhang mit Target SDK, Build SDK und Store-Mindestanforderungen, dem tatsächlich signierten Produktionsartefakt und den Angaben in der Store-Konsole. Halte fest, welche Datei die Einstellung erzeugt, ob ein Framework oder Plugin sie beim Build verändert und wie du den aufgelösten Wert kontrolliert hast. Ein plausibler Eintrag im Quellprojekt beweist noch nicht, dass derselbe Wert im hochgeladenen Binary angekommen ist.
Nachweise für die Release-Freigabe
- Produktionswert für fristen als wartungsprozess führen eindeutig benannt
- Verantwortliche Projektdatei oder Store-Einstellung verlinkt
- Aufgelöste native Konfiguration kontrolliert
- Signiertes Artefakt auf sauberem Gerät geprüft
- iOS- und Android-Unterschiede dokumentiert
- Offene Abweichung mit Owner und Stop-Kriterium versehen
Häufige Fragen
Ist minSdk dasselbe wie targetSdk?
Nein. minSdk bestimmt unterstützte ältere Geräte; targetSdk aktiviert Plattformverhalten und ist für Google-Play-Fristen entscheidend.
Muss ich immer das neueste Expo SDK nutzen?
Nicht automatisch, aber deine Expo-Version muss die erforderlichen nativen SDKs und Zielwerte zuverlässig unterstützen.
Reicht ein erfolgreicher lokaler Build?
Nein. Store-Uploadregeln, CI-Toolchain und Laufzeitverhalten müssen ebenfalls passen.
Warum wird dieser Artikel regelmäßig aktualisiert?
Apple und Google ändern SDK- und Uploadanforderungen regelmäßig. Deshalb benötigt die Seite eine echte fachliche Prüfung und ein korrektes lastmod.