Ett meddelande från Apple eller Google om att en uppdatering krävs kan gälla kod, ett butiksformulär eller båda. Kontrollera först vilken app och version det gäller, tidsfristen och aktuell status. Översätt sedan meddelandet till den minsta säkra ändringen och verifiera den faktiskt signerade releasekandidaten. Tidsfristen påverkar planeringen; den visar inte att alla appar måste byggas om.
Läs det exakta meddelandet i konsolen
Öppna meddelandet i utvecklarkontot som äger appen. Anteckna:
- App, plattform, berörd kanal och exakt version eller build.
- Åtgärden som krävs, tidsfrist, aktuell status och vad som händer när datumet passerar.
- Om det gäller en ny inskickning, synlighet för en befintlig app, ett butiksformulär eller själva binären.
Blanda inte ihop SDK-versionerna
På Android anger mål-API vilken plattformsbeteendenivå appen anpassas till. Compile- eller build-SDK är verktygskedjan och API-ytan som används för att bygga appen; min SDK anger den äldsta Android-version där den kan installeras. På Apple-plattformar är Xcode och iOS-SDK som krävs för uppladdning separata från deployment target, appens lägsta stödda iOS-version. Ett högre mål eller uppladdnings-SDK höjer inte automatiskt lägsta OS-version. Att ändra en siffra gör inte heller ett inkompatibelt beroende, behörighetsflöde, manifest eller SDK-beteende säkert.
Ta reda på vad som faktiskt måste ändras
Tänk på en fiktiv Android-app vars meddelande i Play Console kräver mål-API 36. Innan någon ändring görs bekräftar ägaren appen, berörd release, tidsfrist och status i konsolen. Teamet kontrollerar att varje plugin och inbäddat SDK kan byggas och fungerar med målet och granskar sedan plattformsändringar, behörigheter och manifestuppgifter. Ett versionslyft kan räcka för att bygga appen medan ett bibliotek fortfarande slår ut inloggning eller pushnotiser.
- Kontrollera beroenden och integritetsrelaterade SDK:er; uppdatera eller byt ut inkompatibla delar.
- Granska manifestposter, behörigheter vid körning och motsvarande butiksuppgifter.
- Kontrollera uppgifter om kontoradering och åldersklassificering när de är relevanta; exemplen gäller inte alla appar.
- Ta reda på om meddelandet tillåter en metadata- eller formulärkorrigering eller kräver en ny binär.
Håll releasen under kontroll
Gör ändringarna på en underhållen releasegren, spara den senast godkända källkoden och bygget och dokumentera versionsändringarna. En korrigering av enbart metadata kan göras i konsolen om meddelandet tillåter det; kod-, SDK- eller manifeständringar kräver en ny signerad binär.
- Bygg releasekandidaten med rätt verktygskedja och signering. Knyt kandidaten till den underhållna releasegrenen.
- Installera den signerade versionen på fysiska enheter som stöds. Ett utvecklingsbygge verifierar inte releasekandidaten.
- Testa appens faktiska användarflöden igen. Kontrollera inloggning, köp och återställning, pushnotiser och djuplänkar där appen använder dem.
- Ladda upp till en intern eller sluten testkanal. Kontrollera app, version, behörigheter och start i den installerade versionen.
Test, granskning och publicering är skilda beslut
En uppladdad testversion ger inte tillstånd till offentlig publicering. Externa TestFlight-tester kan kräva betagranskning. Kom överens med kontoägaren om varje steg för testning, granskning och publicering. Kunden behåller butikskonton, källkod och tillgång till signering. Avtala separat om underhåll, ASO och appstöd eller modernisering. Vår guide om granskningstider hjälper med planeringen.
- Bedöm meddelandet
- Gör den avgränsade ändringen
- Verifiera den signerade versionen
- Ägaren godkänner nästa steg
Test, inskickning för granskning och offentlig release är skilda beslut.
Kontrollerat 4 november 2026: Google Play kräver API 36 för vanliga telefonappar som skickas in; befintliga appars synlighet har separata regler. Apples aktuella uppladdningskrav omfattar Xcode 26 och iOS 26 SDK. Aviserade krav för 2027 är framtida ändringar. Kontrollera tidsfrist och omfattning i meddelandet för din egen app.