ITMS-90683: fixa “Missing purpose string” i Expo

ITMS-90683 är ett automatiskt avslag från Apple: det kommer via mejl strax efter att du skickat in ditt build, innan någon människa har granskat något. Det betyder att din Info.plist saknar meningen som förklarar varför appen använder känslig data. Lösningen består av två steg: lägg till nyckeln som nämns i meddelandet under ios.infoPlist och gör sedan ett nytt build.

Jag råkade ut för det med Solys, min väckarklocka med minispel, för data som appen inte ens använder. Här går jag igenom vad meddelandet betyder, varför det dyker upp och hur du undviker det.

Vad betyder felet ITMS-90683?

Hela meddelandet har rubriken "ITMS-90683: Missing purpose string in Info.plist". Det säger att koden i din app refererar till ett API som rör känslig data (bilder, kamera, mikrofon, plats, kontakter) och att din Info.plist saknar motsvarande beskrivningsnyckel. Meddelandet anger nyckeln, till exempel NSPhotoLibraryUsageDescription.

Den här beskrivande meningen kallas "purpose string". Det är texten som iOS visar i rutan där användaren ombeds ge behörighet. Apple skriver det i sin dokumentation om åtkomst till skyddade resurser: App Review avvisar appar vars kod använder de här resurserna utan purpose string.

Det är inte en granskare som har avvisat dig. Kontrollen är automatisk och sker när buildet levereras, innan granskningen, precis som ITMS-91053 för integritetsmanifestet. Buildet kasseras och du måste skicka ett nytt.

Varför Apple avvisar trots att din app inte använder datan

Det är det som överraskar. Apple analyserar koden i ditt build, inte vad appen faktiskt gör. Om ett bibliotek du har med i appen innehåller en referens till bildbiblioteket krävs nyckeln, även om ingen skärm någonsin ber om åtkomst till bilder. Apples meddelande säger det själv: ett externt bibliotek eller SDK kan referera till de här API:erna, och purpose string är ändå obligatorisk.

Mitt fall, den 26 september 2026. När jag städade i Solys konfiguration tog jag bort nyckeln NSPhotoLibraryUsageDescription, eftersom appen inte rör några bilder. Nästa build avvisades med ITMS-90683. Orsaken: två Expo-bibliotek som appen använder, expo-image och expo-file-system, innehåller kod som refererar till bildbiblioteket. Det förra buildet gick igenom eftersom nyckeln fortfarande fanns kvar.

Lärdomen: en beskrivningsnyckel tar du inte bort "för att den inte används". Du tar bara bort den när inget bibliotek i buildet längre refererar till API:et.

De vanligaste nycklarna

• NSPhotoLibraryUsageDescription: läsa eller skriva bilder.
• NSPhotoLibraryAddUsageDescription: lägga till bilder, utan att läsa.
• NSCameraUsageDescription: kamera.
• NSMicrophoneUsageDescription: mikrofon.
• NSLocationWhenInUseUsageDescription: plats medan appen används.
• NSContactsUsageDescription: kontakter.
• NSUserTrackingUsageDescription: annonsspårning (App Tracking Transparency).

Apple beskriver varje nyckel i sin dokumentation, till exempel den för NSPhotoLibraryUsageDescription: den krävs så fort appen använder ett API som läser eller skriver i bildbiblioteket.

Fixa ITMS-90683 i en Expo-app

1. Notera nyckeln som nämns i mejlet från Apple. Meddelandet anger det exakta namnet.
2. Lägg till den i din konfiguration, under ios.infoPlist, som Expos dokumentation om behörigheter beskriver:

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSPhotoLibraryUsageDescription": "Solys använder inte dina bilder. Den här behörigheten efterfrågas aldrig."
      }
    }
  }
}

3. Gör ett nytt build. Expo påpekar att en ändring i Info.plist inte kan skickas som en fjärruppdatering, den kräver en ny binär.
4. Skicka buildet till Apple igen och välj det sedan i din version.

En fälla om din app är översatt: språkfilerna översätter en nyckel, de deklarerar den inte. Nyckeln måste först finnas i ios.infoPlist (eller i konfigurationen för det aktuella pluginet). Annars kan appen krascha vid första anropet.

Vilken mening ska du skriva om appen inte använder datan?

Apple kräver en beskrivning som är korrekt, användbar och precis. Om appen verkligen använder datan, säg vad den används till i en mening: "Appen använder kameran för att skanna streckkoden på din biljett."

Om nyckeln bara finns där på grund av ett bibliotek ger Apple två lösningar: skriv meningen eller ta bort koden som använder datan. När koden kommer från ett bibliotek kan du inte bara ta bort den. I Solys skrev jag därför sanningen: "Solys använder inte dina bilder. Den här behörigheten efterfrågas aldrig." Det är ett pragmatiskt val: nästa build gick igenom vid leveransen, men jag kan inte lova att Apple alltid kommer att godta den meningen.

Hitta saknade nycklar innan du skickar

Från projektets rot listar det här kommandot de biblioteksfiler vars iOS-kod refererar till de mest bevakade API:erna:

grep -rlE "PHPhotoLibrary|AVCaptureDevice|CLLocationManager|CNContactStore|EKEventStore|ATTrackingManager" \
  node_modules/*/ios node_modules/@*/*/ios

Varje namn motsvarar en typ av data: PHPhotoLibrary för bilder, AVCaptureDevice för kamera och mikrofon, CLLocationManager för plats, CNContactStore för kontakter, EKEventStore för kalender, ATTrackingManager för spårning. Kontrollera för varje träff att motsvarande beskrivningsnyckel finns i din konfiguration.

Det här skyddsnätet fångar de fall jag själv har stött på. Det ersätter inte att läsa mejlet från Apple, som är den enda säkra listan, precis som för de icke-publika API:erna i ITMS-90338. Sedan det avslaget kör jag den här kontrollen före varje build: den tar några sekunder, medan ett ITMS-90683-avslag kostar ett build och tiden det tar att göra om det.

Skicka ditt build utan obehagliga överraskningar

ITMS-90683 är snabbt fixat när du vet hur du ska läsa det, precis som ITMS-90725, som gäller Xcode-versionen. Avslagen som kommer sedan, de från en granskare, kräver mer eftertanke: arbetsgången finns på sidan app avvisad av Apple, och de vanligaste orsakerna finns i varför Apple avvisar en app.

För att kontrollera allt innan du skickar samlar Apple Review Kit min checklista och Claude Code-skills som går igenom ditt projekt. Om din inskickning fastnar och du vill ha en människas blick, boka en timme med mig: vi går igenom ditt projekt i ett videosamtal, på din skärm. Och om du förbereder din första lansering, gör din gratis diagnostik: den sätter stegen i rätt ordning och skickar dig min checklista mot avslag från Apple.

Vanliga frågor

Är ITMS-90683 ett avslag från App Review?

Inte i betydelsen en mänsklig granskare. Det är en automatisk kontroll av buildet vid leveransen, innan granskningen, precis som ITMS-90717 för ikonen. Ingen har öppnat din app. Buildet kasseras: du måste rätta Info.plist och skicka ett nytt.

Varför kräver Apple en nyckel för data som min app inte använder?

För att Apple analyserar koden i buildet, inte hur appen beter sig. Om ett inkluderat bibliotek refererar till bildbiblioteket eller kameran krävs beskrivningsnyckeln, även om ingen skärm någonsin ber om den åtkomsten.

Kan man fixa ITMS-90683 med en fjärruppdatering?

Nej. Den saknade nyckeln ligger i Info.plist, som är en del av binären. En fjärruppdatering ändrar inte den filen: du måste göra ett nytt build och skicka det till Apple igen.

Var lägger man till NSPhotoLibraryUsageDescription i ett Expo-projekt?

I din appkonfiguration, under ios.infoPlist, med en mening som beskriver användningen. Vissa bibliotek har också en egen inställning i sitt plugin, som kan lägga till andra nycklar, till exempel ett bakgrundsläge. I båda fallen måste nyckeln finnas i baskonfigurationen, inte bara i översättningsfilerna.

Ska man ta bort oanvända beskrivningsnycklar?

Bara om inget bibliotek i buildet längre refererar till det aktuella API:et. Annars avvisas nästa inskickning med ITMS-90683. Innan du tar bort en nyckel, sök efter API:ets namn i iOS-koden för dina beroenden.