En meddelelse fra Apple eller Google om, at en opdatering kræves, kan handle om kode, en butiksformular eller begge dele. Kontrollér først, hvilken app og version den gælder, fristen og den aktuelle status. Oversæt derefter meddelelsen til den mindst omfattende sikre ændring, og kontrollér den faktisk signerede releasekandidat. Fristen påvirker planlægningen; den viser ikke, at alle apps skal bygges igen.
Læs den præcise meddelelse i konsollen
Åbn meddelelsen i den udviklerkonto, der ejer appen. Notér:
- App, platform, berørt spor og præcist versions- eller buildnummer.
- Den krævede handling, frist, aktuelle status og hvad der ændres, når fristen udløber.
- Om det gælder en ny indsendelse, synlighed for en eksisterende app, en butiksformular eller selve binæren.
Forveksl ikke SDK-numrene
På Android angiver mål-API det platformadfærdstrin, appen er tilpasset til. Compile- eller build-SDK er værktøjskæden og API-fladen, der bruges til at bygge appen; min SDK fastlægger den ældste Android-version, den kan installeres på. På Apple-platforme er den Xcode- og iOS-SDK, der kræves til upload, adskilt fra deployment target, appens laveste understøttede iOS-version. Et højere mål eller upload-SDK hæver ikke automatisk minimumsversionen af operativsystemet. Et ændret tal gør heller ikke en inkompatibel afhængighed, tilladelsesproces, manifestangivelse eller SDK-adfærd sikker.
Find den reelle ændring
Forestil dig en fiktiv Android-app, hvor Play Console beder om mål-API 36. Før redigering bekræfter ejeren den angivne app, berørte release, frist og status i konsollen. Teamet undersøger, om hvert plugin og indlejret SDK kan bygges og fungerer med målet, og gennemgår derefter platformændringer, tilladelser og manifestangivelser. Et versionsløft kan få appen til at bygge, mens et bibliotek stadig ødelægger login eller pushbeskeder.
- Kontrollér afhængigheder og privatlivsrelaterede SDK’er; opdatér eller udskift inkompatible komponenter.
- Gennemgå manifestposter, køretidstilladelser og tilhørende butiksoplysninger.
- Kontrollér instruktioner om kontosletning og aldersklassificering, når det er relevant; eksemplerne gælder ikke alle apps.
- Afklar, om meddelelsen tillader en rettelse af metadata eller formularer, eller kræver en ny binær.
Hold styr på releasen
Arbejd på en vedligeholdt releasegren, gem den senest godkendte kildekode og build, og registrér versionsændringerne. Hvis meddelelsen tillader det, kan en rettelse af metadata alene klares i konsollen; ændringer af kode, SDK eller manifest kræver en ny signeret binær.
- Byg releasekandidaten med den krævede værktøjskæde og signering. Knyt kandidaten til den vedligeholdte releasegren.
- Installér den signerede build på understøttede fysiske enheder. En udviklingsbuild alene verificerer ikke releasekandidaten.
- Test appens faktiske brugerforløb igen. Kontrollér login, køb og gendannelse, pushbeskeder og dybe links, hvor appen bruger dem.
- Upload til et internt eller lukket testspor. Kontrollér app, version, tilladelser og opstart i den installerede build.
Test, review og udgivelse er separate beslutninger
Upload af en testversion giver ikke tilladelse til offentlig udgivelse. Eksterne TestFlight-tests kan kræve betagennemgang. Aftal hvert trin for test, gennemgang og udgivelse med kontoejeren. Kunden beholder butikskonti, kildekode og adgang til signering. Aftal vedligeholdelse, ASO og appsupport eller modernisering separat. Vores guide til gennemgangstider hjælper med planlægningen.
- Vurdér meddelelsen
- Foretag den afgrænsede ændring
- Kontrollér den signerede build
- Ejeren godkender næste skridt
Test, indsendelse til review og offentlig udgivelse er separate beslutninger.
Kontrolleret 4. november 2026: Google Play kræver API 36 for indsendelser af almindelige telefonapps; eksisterende apps har separate synlighedsregler. Apples aktuelle uploadkrav omfatter Xcode 26 og iOS 26 SDK. Annoncerede krav for 2027 er fremtidige ændringer. Kontrollér frist og omfang i beskeden for din egen app.