Et varsel fra Apple eller Google om at en oppdatering kreves, kan gjelde kode, et butikkjema eller begge deler. Kontroller først hvilken app og versjon det gjelder, fristen og gjeldende status. Gjør deretter varselet om til den minste trygge endringen, og kontroller den faktisk signerte utgivelseskandidaten. Fristen påvirker planleggingen; den betyr ikke at alle apper må bygges på nytt.
Les det nøyaktige varselet i konsollen
Åpne varselet i utviklerkontoen som eier appen. Noter:
- App, plattform, berørt spor og nøyaktig versjon eller build.
- Påkrevd handling, frist, gjeldende status og hva som endres når fristen går ut.
- Om det gjelder en ny innsending, synlighet for en eksisterende app, et butikkskjema eller selve binærfilen.
Ikke bland sammen SDK-tallene
På Android angir mål-API hvilket plattformatferdsnivå appen er tilpasset. Compile- eller build-SDK er verktøykjeden og API-flaten som brukes til å bygge den; min SDK angir den eldste Android-versjonen appen kan installeres på. På Apple-plattformer er Xcode og iOS-SDK-en som kreves for opplasting, atskilt fra deployment target, appens laveste støttede iOS-versjon. Et høyere mål eller opplastings-SDK øker ikke automatisk minimumsversjonen av operativsystemet. Å endre ett tall gjør heller ikke en inkompatibel avhengighet, tillatelsesflyt, manifestoppføring eller SDK-atferd trygg.
Finn den faktiske endringen
Tenk på en fiktiv Android-app der Play Console ber om mål-API 36. Før de redigerer, bekrefter eieren appen, den berørte utgivelsen, fristen og statusen i konsollen. Teamet sjekker om hver plugin og innebygd SDK bygges og fungerer med målet, og går deretter gjennom plattformendringer, tillatelser og manifestoppføringer. En versjonsøkning kan få appen til å bygge mens et bibliotek fortsatt ødelegger innlogging eller pushvarsler.
- Kontroller avhengigheter og personvernrelaterte SDK-er; oppdater eller erstatt inkompatible komponenter.
- Gå gjennom manifestoppføringer, kjøretidstillatelser og tilhørende butikkopplysninger.
- Sjekk veiledning om kontosletting og aldersgradering når det er relevant; eksemplene gjelder ikke alle apper.
- Avklar om varselet tillater en retting av metadata eller skjema, eller krever en ny binærfil.
Hold kontroll på utgivelsen
Gjør endringene på en vedlikeholdt utgivelsesgren, ta vare på den sist godkjente kildekoden og builden, og noter versjonene som endres. En retting av bare metadata kan gjøres i konsollen hvis varselet tillater det; endringer i kode, SDK eller manifest krever en ny signert binærfil.
- Bygg utgivelseskandidaten med nødvendig verktøykjede og signering. Knytt kandidaten til den vedlikeholdte utgivelsesgrenen.
- Installer den signerte builden på støttede fysiske enheter. En utviklingsbuild alene verifiserer ikke utgivelseskandidaten.
- Test appens faktiske brukerflyter på nytt. Kontroller innlogging, kjøp og gjenoppretting, pushvarsler og dyplenker der appen bruker dem.
- Last opp til et internt eller lukket testspor. Kontroller appen, versjonen, tillatelsene og oppstarten i den installerte builden.
Testing, gjennomgang og utgivelse er separate beslutninger
Opplasting av en testversjon gir ikke tillatelse til offentlig publisering. Eksterne TestFlight-tester kan kreve betagjennomgang. Avtal hvert trinn for testing, gjennomgang og publisering med kontoeieren. Kunden beholder butikkontoer, kildekode og tilgang til signering. Avtal vedlikehold, ASO og appstøtte eller modernisering separat. Vår veiledning om gjennomgangstider hjelper med planleggingen.
- Vurder varselet
- Gjør den avgrensede endringen
- Kontroller den signerte builden
- Eieren godkjenner neste steg
Testing, innsending til gjennomgang og offentlig utgivelse er separate beslutninger.
Kontrollert 4. november 2026: Google Play krever API 36 ved innsending av vanlige telefonapper; eksisterende appers synlighet har egne regler. Apples gjeldende opplastingskrav omfatter Xcode 26 og iOS 26 SDK. Varslede krav for 2027 er fremtidige endringer. Kontroller frist og omfang i varselet for din egen app.